Is there an easy way (I know I could always write my own shim layer in front of Auth0 to do it) to make JWTs in SPAs act as a limited sort of refresh token? I know that having a separate long-lived refresh token is a big security issue in an SPA, but I figured a short-lived token that respects inactivity restrictions would be more secure.
More concretely, we may have users who have third-party cookies disabled (preventing silent auth from working). We want users to be logged out after an inactive time of 1hr and force a re-login after 16 hrs regardless of activity. I’m imagining a scenario in which our JWTs have a 1hr expiration, and there’s an Auth0 endpoint that the app can hit and provide an active JWT to get a new JWT back and extend the length of the session by another hour, but not beyond the max length of 16 hrs. This would be more secure than just making JWTs last 16 hours, since it would take inactivity into account.
Hi @ncknuna.
There’s no way to do that (nothing of the sort is part of a standard OAuth2 or OIDC grant type). I would also stay clear of trying to implement some kind of alternative token renewal protocol, as you wouldn’t have the security assessment from experts that the standard specifications get.
In this particular case, by letting a JWT token (you don’t specify whether it would be the access token or ID token) get new tokens you are essentially turning it into a refresh token of sorts, which would give an attacker that gets the token the possibility of non-expiring access to the protected resource.
If users have third-party cookies disabled you can fall back to a regular /authorize with a full redirection (and thus page refresh). It will be definitely more inconvenient, but you can always explain to users that they can improve the experience by allowing third-party cookies.
You could also try using popup authentication as well for the cases where third-party cookies are disabled, to avoid disrupting the current application state.
If the OAuth2 Working Group issues new recommendations for refresh tokens or other token renewal mechanisms for SPAs in the future, Auth0 will likely follow suit but, as of now, there’s no alternative approach.
Thanks for the quick reply! Yea, I don’t intend to implement anything complex and custom on my own; it’s definitely not worth the risk. In the hypothetical case I described though, the session would expire after 16 hrs, so an attacker shouldn’t ever be able to get non-expiring access.
Yup, what you described as the fallback was going to be the plan; I was hoping there was a better option. Thanks for the feedback!