4 ms·

No, you just have to always keep in mind that if you misconfigure your application to sign a token with no expiry, you will never be able to revoke it. Period.

losingthefight 7y ago
I mean, this isn't really true though. If you forgot, you can have your JWT middleware check and if the field is missing, revoke it. There are tons of workarounds here and I have implemented them in several consulting roles. I personally always put a created and expires timestamp, bit if they aren't there, there are ways to fix the situation easily.
kbenson 7y ago
Hmm, couldn't you also rotate encryption keys once a day/week, and keep the last one or two available, and if decrypting with the current one fails, try a prior one? Eventually, that token will no longer be readable. It should only ever matter in the weird case where your expire time is screwy, but you've put a bound on how long a token can survive no matter what.
alboy 7y ago
All such tokens would be effectively revoked anyway since you check the iat timestamp (or lack thereof) at the authorization point.
- jacobr1 7y ago
  Yep, and that is what we do. But we also check to ensure that a secure cipher was used, not none. Many of the "JWT is insecure" type articles (and real vulnerabilities found) were based on the fact that people just used dumb defaults and didn't secure things. So the argument is really that JWT is a footgun without some adult supervision.
ryanisnan 7y ago
No, not period. If you're using an API gateway (which you should be), you can check against blacklisted tokens. The `jti` is your unique token identifier. As long as you have a way of maintaining a blacklist of tokens, this is trivial.
- je42 7y ago
  yep. however, the token is then not "stateless" anymore since you have to take note of the blacklisted state. however, once you really care about the security perimeter, i think the requirement/wish "stateless" must be dropped.
- nothrabannosir 7y ago
  One of the major points for signed tokens is stateless operation. If you need to maintain a blacklist, you lose that, and the question arises: why not just have a whitelist of tokens/UUIDs/... to begin with? This is why people suggest "short tokens" as a work-around, accepting a 5min window of unrevokable tokens as trade-off. Or, one has to justify that a blacklist implementation is significantly cheaper than a whitelist one. But is it, really?
  - munchbunny 7y ago
    That depends on the size of your system. I've worked on systems with so many servers that it would be cripplingly difficult to quickly propagate all whitelist updates to all servers in all services that would need to verify against the whitelist, and the alternative of doing a lookup against the whitelist for every request would be extremely expensive. On the other hand, you generally expect that you rarely ever need to actually revoke tokens, so you can naturally expect that a blacklist will change infrequently and will remain tiny compared to the whitelist. As the size of the service grows, most people converge to a fast train/slow train design: the whitelist is big and is accessed infrequently, and the blacklist is tiny (goes obsolete within the TTL of the whitelist query) and can be pushed out quickly. If you're one of the tech giants, it's not slightly cheaper, it's a lot cheaper.
  - ryanisnan 7y ago
    If you have a sole identity provider, or token issuer, the blacklist can be quite simple to maintain. Plus, with short token life spans, you probably aren't revoking tokens very frequently. In my experience, usage of the black list occurred with two use cases: 1) Invalidating all of a user's tokens 2) Alteration of claims that a user's JWT should have As far as your applications go, you still have the benefit of not having to bother with checking the state (this is already done by the gateway).
gregmac 7y ago
You can add this type of thing to your validation code: exp has to be set, can't be in the past, and can be no more than x time in the future (where x is somewhere between what you're actually signing now and the largest value you could ever conseivably want to use without having to push an update to this app). One of the biggest challenges with using JWTs is really all these gotchas that you have to think about. This isn't dissimilar to the infamous `alg:none` fiasco. In this case, it's not really about protecting against an attack, but forcing the developer on the other end to think about it. Their quick initial code that doesn't bother setting exp or has it hard-coded to 1000 years in the future will never work, so it had less chance of being left in to cause a security issue later.
hoffs 7y ago
When verifying the token you could just check if exp is set and if the lifetime of the token does not exceed your limit.

losingthefight 7y ago

I mean, this isn't really true though. If you forgot, you can have your JWT middleware check and if the field is missing, revoke it. There are tons of workarounds here and I have implemented them in several consulting roles. I personally always put a created and expires timestamp, bit if they aren't there, there are ways to fix the situation easily.

kbenson 7y ago

Hmm, couldn't you also rotate encryption keys once a day/week, and keep the last one or two available, and if decrypting with the current one fails, try a prior one? Eventually, that token will no longer be readable. It should only ever matter in the weird case where your expire time is screwy, but you've put a bound on how long a token can survive no matter what.

alboy 7y ago

All such tokens would be effectively revoked anyway since you check the iat timestamp (or lack thereof) at the authorization point.

jacobr1 7y ago
Yep, and that is what we do. But we also check to ensure that a secure cipher was used, not none. Many of the "JWT is insecure" type articles (and real vulnerabilities found) were based on the fact that people just used dumb defaults and didn't secure things. So the argument is really that JWT is a footgun without some adult supervision.

ryanisnan 7y ago

No, not period. If you're using an API gateway (which you should be), you can check against blacklisted tokens. The `jti` is your unique token identifier. As long as you have a way of maintaining a blacklist of tokens, this is trivial.

je42 7y ago
yep. however, the token is then not "stateless" anymore since you have to take note of the blacklisted state. however, once you really care about the security perimeter, i think the requirement/wish "stateless" must be dropped.
nothrabannosir 7y ago
One of the major points for signed tokens is stateless operation. If you need to maintain a blacklist, you lose that, and the question arises: why not just have a whitelist of tokens/UUIDs/... to begin with? This is why people suggest "short tokens" as a work-around, accepting a 5min window of unrevokable tokens as trade-off. Or, one has to justify that a blacklist implementation is significantly cheaper than a whitelist one. But is it, really?
- munchbunny 7y ago
  That depends on the size of your system. I've worked on systems with so many servers that it would be cripplingly difficult to quickly propagate all whitelist updates to all servers in all services that would need to verify against the whitelist, and the alternative of doing a lookup against the whitelist for every request would be extremely expensive. On the other hand, you generally expect that you rarely ever need to actually revoke tokens, so you can naturally expect that a blacklist will change infrequently and will remain tiny compared to the whitelist. As the size of the service grows, most people converge to a fast train/slow train design: the whitelist is big and is accessed infrequently, and the blacklist is tiny (goes obsolete within the TTL of the whitelist query) and can be pushed out quickly. If you're one of the tech giants, it's not slightly cheaper, it's a lot cheaper.
- ryanisnan 7y ago
  If you have a sole identity provider, or token issuer, the blacklist can be quite simple to maintain. Plus, with short token life spans, you probably aren't revoking tokens very frequently. In my experience, usage of the black list occurred with two use cases: 1) Invalidating all of a user's tokens 2) Alteration of claims that a user's JWT should have As far as your applications go, you still have the benefit of not having to bother with checking the state (this is already done by the gateway).

gregmac 7y ago

You can add this type of thing to your validation code: exp has to be set, can't be in the past, and can be no more than x time in the future (where x is somewhere between what you're actually signing now and the largest value you could ever conseivably want to use without having to push an update to this app). One of the biggest challenges with using JWTs is really all these gotchas that you have to think about. This isn't dissimilar to the infamous `alg:none` fiasco. In this case, it's not really about protecting against an attack, but forcing the developer on the other end to think about it. Their quick initial code that doesn't bother setting exp or has it hard-coded to 1000 years in the future will never work, so it had less chance of being left in to cause a security issue later.

hoffs 7y ago

When verifying the token you could just check if exp is set and if the lifetime of the token does not exceed your limit.