I would like to hear your opinion about how to invalidate a token, the 2 options we have so far: 1 query the db on every request and 2 cache for some minutes the db data, seems both don't fit well in a modern web development
Ten years of JSON Web Token and preparing for the future
91–100 of 159 posts
Re: Ten years of JSON Web Token and preparing for the future
#92I would like to hear your opinion about how to invalidate a token, the 2 options we have so far: 1 query the db on every request and 2 cache for some minutes the db data, seems both don't fit well in a modern web development
Tradeoff: You can't implement individual token revocation, but you can easily implement a "Logout on all devices" system. You have a timestamp with a "minimum issued at" attached to each identity, and if that identity (user) choses to "logout from all devices", you set the timestamp to the current time. Upon validating a token you only make sure the issued-at (iat) is after your "minimum issued at".
I think it is a real good trade-off, as in case of a security breach you have an easy way to mitigate leaked tokens. The downside is, your user will have to re-login all devices. If you do not want to burden your users with the login on all devices, you should ask your self how often you do have security breaches and leaked tokens, might be you have others issues going on.
Re: Ten years of JSON Web Token and preparing for the future
#93The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…
If it’s a major compromise you can simply roll out a new key… invalidating all current JWTs forcing a new login… you could also group signing keys by user type to further minimise the refreshes.
Re: Ten years of JSON Web Token and preparing for the future
#94JWTs are just too fat, and JS users often forgets encoding is not encryption. I've seen some news site trackers send JWT in url/header to some 3rd party tracker. Content is no surprise, my full name, and email address, violates its own privacy policy. Otherwise it's very open and handy, from inspecting a jwt token I can learn a lot about the architectural design of many sites.
> Content is no surprise, my full name, and email address
Not sure if I’m remembering correctly but isn’t it recommended to not store any identifiable information in a JWT precisely because of this?
Re: Ten years of JSON Web Token and preparing for the future
#95The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…
I have a random idea regarding compromised tokens, which may not hold water. What if you put things like the client's IP address in the token? Then the server can reject (and mark for compromise) as soon as they receive any request from a different ip address? I realise this will also invalidate people who somehow roam between ip addressses, say DHCP/wireless in a larger building.
Client IP addresses change a lot more than you think, especially on mobile networks.
Re: Ten years of JSON Web Token and preparing for the future
#96I think the rule of thumb should be to ALWAYS start with Cookies for client/server authentication, with all the security features enabled by default. HttpOnly, Secure and SameSite.
Then, if that has some sort of limitation for your app's specific use case, you can see to migrate to JWT.
But the standards are standards for a reason.
Re: Ten years of JSON Web Token and preparing for the future
#97Every time I want to use a JWT, it seems like it's the suboptimal choice, so I've never found a genuine use case for them. Most recently, I wanted to implement 2FA w/ TOTP. I figure I'll use 1 cookie for the session, and another cookie as a TOTP bypass. If the user doesn't have a 2FA bypass cookie, then they have to complete the 2FA challenge. Great, so user submits username & password like normal, if they pass but d…
In your scenario you could still apply additional protections to a user id after detecting X attempts of sending a forged JWT. At least you could alert on JWTs that arrive with invalid signatures. Or you could put a 2FA challenge key inside the JWT, just use the JWT as a container to hold the information you would have shared with the client anyway. I agree that JWTs don't really do anything more than a cookie couldn…
> we end up having to support JWT in the web browser too, manually putting it into localstorage or the application state, instead of just leveraging the cookie jar that was already there.
> We just recently had to implement an SSO solution using JWT because the platform only gave out JWTs, so we ended up putting the JWT inside an encrypted HttpOnly cookie. Seemed a bit like a hat-on-a-hat, but eh.
Why would you think that? Cookies are a perfectly normal place to store JWTs for web applications. If your frontend is server-side-generated, the browser needs to authenticate the very first request it sends to the server and can't rely on anything apart from cookies anyway.
Re: Ten years of JSON Web Token and preparing for the future
#98JWTs are just too fat, and JS users often forgets encoding is not encryption. I've seen some news site trackers send JWT in url/header to some 3rd party tracker. Content is no surprise, my full name, and email address, violates its own privacy policy. Otherwise it's very open and handy, from inspecting a jwt token I can learn a lot about the architectural design of many sites.
Well JWTs are signed - signing is not encryption per se. But there are also JWE which are mentioned in the linked article. They are fully encrypted.
Re: Ten years of JSON Web Token and preparing for the future
#99[dead]
Re: Ten years of JSON Web Token and preparing for the future
#100Earlier quoted context omitted.
Is there a proposed rfc for revocation lists?
You may have a look at this (still a Draft): https://datatracker.ietf.org/doc/draft-ietf-oauth-status-lis...
I don't think status lists solve the requirement for near-realtime revocations.
The statuslist itself has a TTL and does not get re-loaded until that TTL expires. This is practically similar to the common practice of having a stateful refresh token and a stateless access token. The statuslist "ttl" claim is equivalent to the "exp" claim of the access token in that regard, and it comes with the same tradeoffs. You can have a lower TTL for statuslist, but that comes at the cost of higher frequency of high-latency network calls due to cache misses.
The classic solution to avoid this (in the common case where you can fit the entire revocation list in memory) is to have a push-based or pub/sub-based mechanism for propagating revocations to token verifiers.