3 ms·

The one thing that I found scary when reading up on JWTs is that there is no way to revoke them. Of course you could check them against a list of revoked tokens

The one thing that I found scary when reading up on JWTs is that there is no way to revoke them. Of course you could check them against a list of revoked tokens on your server, but then your lose the stateless aspect. So the only remaining option to revoke a JWT is the nuclear option, invalidating all JWTs at once. This seemed like a rather large limitation to me. Related to this, the ability to encode further information in the token, e.g. access rights suffer from the same flaw. If I use the tokens themselves to grant different privileges on a site, I can't revoke those privileges. I've never used them in practice, this is all just from reading about JWTs. How do people deal with those aspects in practice?

CiPHPerCoder 10y ago
> How do people deal with those aspects in practice? In one word: Poorly. There is no elegant solution outside what you've outlined here. Or: they use stateful JWTs.
andrewstuart2 10y ago
What you've described is literally the same tradeoff you must decide on with caching TTL, but in the arena of credential validity for signed tokens. In both cases, you're deciding how long something should be valid before it's flushed and must be renewed, or whether you should always check the source.
vkjv 10y ago
The nice thing is that you get quite a bit of middle ground to play with performance. Examples: * Refresh TTLs that allow for some caching before hitting a DB (revoking). * Using a Bloom filter to revoke to limit the number of affected users, but also bound memory.
bjt 10y ago
JWTs can be revoked if you sign them with application_key + some_user_revocation_string. This is how password reset tokens work in Django, for example. They're signed with the app's secret key + the user's existing password hash. Once the user uses the token to change the password, the token is no longer valid.
- Normal_gaussian 10y ago
  However every service now needs access to the list of hashed passwords.
  - bjt 10y ago
    Or access to a service that has access to the hashes/revocation strings. Which puts you in a similar situation to non-JWT scenarios where every service has to phone home to check a token's validity. I'm not saying all tokens should be made revocable in this way. I'm saying that people claiming "you can't invalidate a JWT" are overstating their case. If you really need to do invalidation, this is one option.
- mwpmaybe 10y ago
  Hrrm, now you're in a situation where you're using part of the unverified payload to look up part of the secret before validating the signature and hence the payload. This is a neat idea but it introduces a whole class of potential vulnerabilities. (This is similar to the argument against the algorithm being selected from the unverified payload before being used to validate the signature per the JWT specification.)
Normal_gaussian 10y ago
Tokens are created with an identifier, creation time, and expiry time. They are signed. For web connections I use a renewal token with a long expiry (in the weeks) that is used to ensure we always have a fresh active token (in the hours). You can't get an active token with a refresh token that has a creation time less than a timestamp stored with the login details. This allows revoking within a few hours, which is good enough for the vast majority of cases. I also maintain a pushable blacklist for emergencies - good UX for this is have the revoke button lead to a "X has successfully been logged out, this may take a few hours to affect all of our services. If it is important that they are logged out immediately click here <Force Immediate Logout>". For mobile devices which need to limit requests to the server I allow passing a refresh token to most of the services, which will validate it via the server and return an active token with the response. This works well for the applications I use it in, because I can do instant revokes, but gradual revokes are business case acceptable. Having a token does not allow you to purchase or permanently delete anything. "Super Admin" actions are done with a different system (that only appears integrated to the end user, different DB logins and everything) that requires password validation anyway. It is not suitable for every application, but it does allow me to operate without inter-service communication for the vast majority of the time.

CiPHPerCoder 10y ago

> How do people deal with those aspects in practice? In one word: Poorly. There is no elegant solution outside what you've outlined here. Or: they use stateful JWTs.

andrewstuart2 10y ago

What you've described is literally the same tradeoff you must decide on with caching TTL, but in the arena of credential validity for signed tokens. In both cases, you're deciding how long something should be valid before it's flushed and must be renewed, or whether you should always check the source.

vkjv 10y ago

The nice thing is that you get quite a bit of middle ground to play with performance. Examples: * Refresh TTLs that allow for some caching before hitting a DB (revoking). * Using a Bloom filter to revoke to limit the number of affected users, but also bound memory.

bjt 10y ago

JWTs can be revoked if you sign them with application_key + some_user_revocation_string. This is how password reset tokens work in Django, for example. They're signed with the app's secret key + the user's existing password hash. Once the user uses the token to change the password, the token is no longer valid.

Normal_gaussian 10y ago
However every service now needs access to the list of hashed passwords.
- bjt 10y ago
  Or access to a service that has access to the hashes/revocation strings. Which puts you in a similar situation to non-JWT scenarios where every service has to phone home to check a token's validity. I'm not saying all tokens should be made revocable in this way. I'm saying that people claiming "you can't invalidate a JWT" are overstating their case. If you really need to do invalidation, this is one option.
mwpmaybe 10y ago
Hrrm, now you're in a situation where you're using part of the unverified payload to look up part of the secret before validating the signature and hence the payload. This is a neat idea but it introduces a whole class of potential vulnerabilities. (This is similar to the argument against the algorithm being selected from the unverified payload before being used to validate the signature per the JWT specification.)

Normal_gaussian 10y ago

Tokens are created with an identifier, creation time, and expiry time. They are signed. For web connections I use a renewal token with a long expiry (in the weeks) that is used to ensure we always have a fresh active token (in the hours). You can't get an active token with a refresh token that has a creation time less than a timestamp stored with the login details. This allows revoking within a few hours, which is good enough for the vast majority of cases. I also maintain a pushable blacklist for emergencies - good UX for this is have the revoke button lead to a "X has successfully been logged out, this may take a few hours to affect all of our services. If it is important that they are logged out immediately click here <Force Immediate Logout>". For mobile devices which need to limit requests to the server I allow passing a refresh token to most of the services, which will validate it via the server and return an active token with the response. This works well for the applications I use it in, because I can do instant revokes, but gradual revokes are business case acceptable. Having a token does not allow you to purchase or permanently delete anything. "Super Admin" actions are done with a different system (that only appears integrated to the end user, different DB logins and everything) that requires password validation anyway. It is not suitable for every application, but it does allow me to operate without inter-service communication for the vast majority of the time.