Does my web frontend JWT authentication process prevent security breaches?

Viewed 80

I have an authentication procedure and I'm wondering if I'm not mixing up some concepts here. Basically:

Login:

  1. returns a signed JWT stored in memory with an hashed fingerprint as claim
  2. store httpOnly and Secure refresh token (JWT) on client with longer expiration time
  3. store fingerprint in secure httpOnly cookie

Authentication:

  1. Send a bearer access token via header
  2. Send XSRF token via header
  3. Verify retrieved XSRF token is valid in server
  4. retrieve fingerprint in server
  5. check in DB if refreshToken is valid
  6. verify access token validity and compare retrieved hashed fingerprint value with JWT fingerprint claim

Access token expired:

  1. check for CSRF token validity
  2. request a new token on refresh token route
  3. Check Refresh Token Validity
  4. Send new signed JWT access token with fingerprint

Does it sound enough for preventing both XSS and CSRF attacks (removing harmful html tag apart for XSS)?

1 Answers

Important question! JWT is widely used, but since it provides a of lot flexibility, it's many times configured and used in a way that creates security vulnerabilities.

Based on recommendations seen here, your cookie with the user fingerprint could also:

  • use SameSite=strict so that the cookie is sent only ever to the same site as the one that originated it (helps to avoid CSRF)
  • has the __Host- prefix and meets the associated requirements, as explained here (further helps to avoid session hijacking)

As for access and refresh token storage on the web frontend, yes, storing in memory is safer according to the same source (Window.sessionStorage is suggested there). EDIT: see also links in the comments.

In addition to signing the token, depending on the scenario, the token payload could also be encrypted with AES and use nonce.

Anyone reading this who feels JWT is still not secure, I'd suggest taking a look at PASETO.

Related