How do you handle JWT expiration and refresh in a SPA?

The same balance in terms of expiration is required for the refresh token though. Implementing a long expiration time for the refresh token can make the user stay logged in for extended periods of time, leaving a potentially exploitable refresh token in the client's computer. Too short of an expiration time and your refresh token becomes useless.

JWT is simply a token encoding format. It is not prescriptive token flow like OIDC. However, best practices are client to keep tokens in memory as much possible and not use cookies or browser storage which can be vulnerable. Clients should be aware of the expiration of their token and should proactively refresh based on a time buffer relative to the expiration window of the token. These expiration windows should typically short relative to human user sessions for example 5 minutes.

You simply cannot leave users authenticated forever, so you need to set an expiry for the token. It should neither be too short to annoy users nor too long, so that users forget their password.

Handling JWT refresh in a SPA When a JWT expires, the user needs to log in again to obtain a new JWT. However, this can be a disruptive experience for the user, especially if they are in the middle of performing a task. To avoid this, you can implement a mechanism that automatically refreshes the JWT without requiring the user to log in again. To handle JWT refresh in a SPA, you need to implement a mechanism that sends a refresh token to the server to obtain a new JWT. The refresh token is a long-lived token that is used to obtain a new JWT when the old one expires. The server verifies the refresh token and sends a new JWT to the client.

For this mechanism we can have two jwt tokens. One is known as an access token and the other is known as a refresh token. The refresh token will have a longer expiry (a month/a week/or 6 months) depending on how soon you want a user to re-login. The access token will have a shorter expiry probably something around 10-15 minutes. Whenever an access token expires, using the automatic mechanism we can trigger a function that will fetch a new access token using the refresh token.

To handle JWT expiration and refresh in a SPA, set a short expiration time for the JWT, refresh it before expiration, and replace the old JWT with the new one. The SPA can store the new JWT in local/session storage for subsequent requests. Refreshing should occur when the user is active, and anti-CSRF measures should be in place. Use additional security measures like anti-CSRF tokens or SameSite cookies to mitigate security risks such as CSRF attacks.

Does the endpoint that accepts the refresh token (which eventually generates a fresh access token) require authentication or is a public endpoint on the server? I've heard this question answered both ways and am a bit confused. If the endpoint requires authentication via client id/secret (not to be confused with end user creds), how does the client obtain the id and secret securely? If the endpoint doesn't require authentication, how do you prevent an attaker from abusing the endpoint?

The duration is an important element to keep in mind. A short-term token would seem worthless because it would need to be updated frequently, whereas a long-term token might have security problems. One thing of note is the best practice for your preferred way of producing SPAs. Refresh tokens, specialised RPCs, redirection, queries, and even locally stored files can all be used to request a new JWT.

Here are the steps to handle JWT expiration and refreshing in a SPA: Before making an API call, check the expiration time of the JWT. If the JWT has expired, prompt the user to log in again and remove the JWT from storage. If the JWT has not expired, make the API call as normal. If the API call returns a 401 Unauthorized response, it means the JWT has expired or is invalid. Prompt the user to log in again and remove the JWT from storage and retrieve a new JWT and store it in storage. Use a setInterval function to periodically check the expiration time of the JWT and refresh it before it expires. When refreshing the JWT, send a refresh token along with it to the server. The server can then verify the refresh token and issue a new JWT.

You can mix these proactive and reactive approaches. The ideal flow is as follows: - Before making a request, check the expiry time of the token - If close to expire (~3m threshold), initiate refresh, but do original request - If expired or too close to expiry (30s threshold), suspend original request, initiate a refresh, then do original request - If the refresh token is expired as well, redirect user to login - Ensure all requests to a single origin/federation are suspended by refresh logic We removed any code that refreshes the token on a schedule. We found that interactions between the scheduler and idle states in browsers made this approach largely ineffectual and redundant w/ respect to the code meant to address those edge cases.

JWTs are not revokable, and changing the signing key on the server to revoke a JWT revokes everyone's session. However, there are ways to make JWTs revokable. One approach is to couple JWTs with highly available and scalable session mechanisms on the server side, such as redis. Another approach is to use short-lived JWTs with refresh tokens that can be stored in a system like redis and revoked if necessary. A third approach is to store revocations in redis and build an interceptor at the API level that refreshes and caches revocations every few seconds. Using a highly scalable backend session technology in combination with JWT is always recommended. Thank you chatgpt for condensing my explanation into 750 characters, lol

Local storage is not the right place to store the JWT tokens as it may be subject to XSS attacks. Cookies are more secure than local storage but still may be subject to CSRF The most secure way to store JWT is always in memory. But since memory cannot be accessed across tabs, etc we can use refresh tokens in cookies(as its more secure than local storage) Storing refresh tokens in cookies is secure and acceptable but not JWT.