Split a JWT between payload and signature

Question

Context: I'm looking at storage solutions for JWT tokens on a single page application.

1. Storing the JWT in the local storage is unsafe and prone to XSS attacks.
2. Storing the JWT in a secure / HTTP only cookie is safer, but prone to CSRF attacks.

I'm studying the following scenario:

Upon authentication, a refresh token is stored in an http only secure cookie. It can only be used to get an access token.

Upon authorisation, the backend responds with a JWT access token. The header and payload part of the JWT are inside the response body. The token signature is not sent and is set in an http only secure cookie (same-site strict if possible, but let's assume it's not the case). The header + payload is stored in memory.

The JWT contains the following claims

• iat, nbf, exp (guessable IMO)
• claims relative to the user identity and permissions (guessable if the user identity is known)
• jti, containing a cryptographically secure random number (in my case generated with python secrets)

When making requests, the header + payload is sent via XHR/fetch by the SPA in an Authorisation header. The signature is sent along with the cookies. The backend concatenates both and verify the signature.

1. Is this mechanism safe against CSRF attacks ? Does the jti claims makes the Authorisation token + signature cookie a valid CSRF mitigation technique ?
2. Is this mechanism indeed safer against XSS attacks than storing the JWT inside the local storage ? (Could an attack using XSS also easily steal the signature, like with a TRACE exploit).

Note: I've read this question which is similar, but overly broad so I'm posting this to get a more precise answer.

Answer 1

Is this mechanism safe against CSRF attacks?

This method of splitting a JWT and storing the signature in the cookie and the rest of the token in Browser Storage does not provide any additional protection against CSRF attacks than if the entire JWT was stored in Local or Session Storage. Yes, it will mitigate CSRF attacks, but you don't need to add the unnecessary overhead of splitting and concatenating JWTs on the server. Storing JWTs in Local Storage and accepting them only in Authorization headers is enough to protect your application from CSRF attacks.

Is this mechanism indeed safer against XSS attacks than storing the JWT inside the local storage? (Could an attack using XSS also easily steal the signature, like with a TRACE exploit)

If your focus is solely on an attacker being able to steal JWTs, this approach is safe unless, as you rightly mentioned, TRACE is enabled on the server.

However, this does not make your application safer from XSS attacks. For example, if I am able to execute arbitrary Javascript on your application, I can fetch the JWT header+payload from Local Storage and just send an XHR to a sensitive endpoint keeping withCredentials set to True. This endpoint might be designed changed the account email address, for example. That straightaway leads to an account takeover. No need to steal cookies or JWTs.

Summing up: This approach does provide some protection against session tokens by separating the signature from rest of the token. However, when it comes to XSS, stealing session tokens is not the only risk that you should be looking at.