JWT authentication expiry
IF you use JWT as apart of your authentication, how long do you set the token expiry for? What is your application and why did you choose this?
IF you use JWT as apart of your authentication, how long do you set the token expiry for? What is your application and why did you choose this?
Interesting discussion.
In most projects I’ve worked with the common pattern was:
• short-lived access tokens (15–60 minutes)
• refresh tokens for longer sessions.
One thing I noticed while debugging auth flows is that developers often struggle to quickly see when a token actually expires or whether it's already invalid.
I ended up building a small Chrome extension that automatically captures JWT tokens from network requests and shows expiration, payload and signature instantly.
It made debugging auth flows much faster for me.
Curious how others usually inspect tokens during development?
I'm of the opinion that JWT is almost always a bad idea unless you are authenticating via a 3rd party like in Oauth.
For your own app authentication, sessions are easier and better. If you use JWTs you should maintain a blacklist of users that have revoked access or logged out. Hitting your blacklist usually involves a roundtrip to redis or your db of choice and at that point you should just use sessions.
If you inisist on using cryptographically verified tokens, use paseto. You're less likely to get screwed by bad JWT libraries.
I wrote the JWT plugin for the Caddy server and hearing many many JWT use cases, I've decided people almost always are doing it wrong.
Agree people should be using a 3rd party auth, but disagree about sessions. I'd just leave it at people should use JWT for API calls and they should use a 3rd party auth server, even if it's something you run yourself like Keycloak.
Agreed you shouldn't be using JWT unless it's OIDC or OAuth2.
JWT can be used for authentication as well as authorization. And, JWT allows a service to perform those checks in a disconnected way, until the token expires.
So, when choosing your expiration time, you should determine how long you can deal with that disconnected token. Consider the case where you need to revoke access, for example. Depending on the use case, it may be OK to let a user continue for say an hour assuming they stopped paying for services. But, an hour is probably not OK if the application granted access to a hostile employee who has just been terminated.
Similarly, depending on how you design your token content, you might want to adjust as well. Consider the case where you embed authorization data in the token. If you allow the user to dynamically adjust their authorizations (ie. upsell services), the user would need to either a) wait for the token to expire or b) go get a new token. Both are not great, but how you scope the token in terms of expiration time, may make the UX a bit better.
So, long story short, it depends on your specific application needs.
You can set short token expirations if you're using a flow that gives refresh tokens.
Correct. However, there are a lot of use cases that will not adequately (read: securely) support those flows.
Such as? Most places are suggesting the auth code flow with PKCE for single page apps now, and that comes with refresh tokens.
As refresh tokens are long-lived tokens that may be exchanged for obtain new scoped tokens, you need to be sure that they may be stored securely. If there is any potential for the token to become leaked, refresh tokens would not be adequate.
Don't get me wrong, refresh tokens are definitely the easiest path, you just need to be very mindful of who and what will have access.
Eh... The advantage is that you can revoke them so they can't be used anymore. From your original post, I agree that tokens shouldn't be used as session state, rather just an identifier letting the application know who the user is. I just disagree that there's that much of an "it depends". In the vast majority of use cases short lived access tokens with refresh tokens to re-up is the best solution.
usually an hour - but it's pretty irritating if you haven't implemented a refresh token as well - which usually has a longer expiry (like 7 days)
This way your own apps can automatically request fresh tokens without forcing the user to log in too often.
Use a short expiration time (under a day).
The primary reason for this is that because JWT is stateless, if you ever want to invalidate a token, you would need to keep a server-side blacklist which makes the whole point of JWT a bit pointless.
I still prefer JWT personally as it's quite straight forward to handle authentication across platforms.
It doesn't depend on if it's a JWT or not but on your particular setup. Having said that it's usually an hour.