5 ms·

This page doesn’t have any discussion of strategies for expiring JWT, one of the biggest security issues with this auth mechanism. Even the code sample doesn’t

by sjroot 8y ago

This page doesn’t have any discussion of strategies for expiring JWT, one of the biggest security issues with this auth mechanism. Even the code sample doesn’t include an expiration.

redbeard0x0a 8y ago
The JWT has a built-in field called exp, which is the time the token is expired. This is built in. However if you need to 'expire' a JWT token early, there isn't a good way to do it. If your token has a JTI, then you could add a blacklist for that JTI (say in redis, with a TTL until the token's exp time). But that is left to the implementor.
- sjroot 8y ago
  The page mentions the ‘exp’ field, but doesn’t use it in its example. I was suggesting the author point out the fact that, if someone gets a hold of a JWT without an expiration, then your system is in quite a bit of trouble.
  - shkkmo 8y ago
    It is up to your implementation if you consider JWTs without an exp field to be valid. Our implementation requires a number of fields that are optional in the spec.
- crescentfresh 8y ago
  So that's what JTIs are for!! I disabled [generating] them in our app, I couldn't figure out what purpose a unique-identifier-per-jwt would have, when you could just use the jwt itself to uniquely identify itself.
- incadenza 8y ago
  My issue here is that expiring JWTs involve adding state! The whole point of JWTs is stateless authentication, so I’ve never understood the advantage over sessions unless revoking tokens is never an option.
  - evan_ 8y ago
    One way to look at it is, presumably you will have far fewer revocations than active sessions, so why optimize for that case? Instead of an "active sessions" table you could just maintain a list of revoked sessions and check each incoming request against that list. You can make revocations expire shortly after the JWT was set to expire.
  - hinkley 8y ago
    When are you expiring tokens ahead of their natural expiration date? When someone logs out? Isn’t that state? If you add state to something stateless you are generally on your own. [edit: also I disagree with the notion that something with an expiration date is stateless. It has two states. It’s just that the look like idenpotence]
    - incadenza 8y ago
      Perhaps revoking is the better term here. At least that's the use case I had in mind. If you want the ability to revoke a token, you have to have some list of black listed tokens somewhere.
    - iamwil 8y ago
      When someone's account is compromised, is another situation.
      - geezerjay 8y ago
        > When someone's account is compromised, is another situation. Why is that scenario relevant if tokens are supposed to be used once per request and short-lived? Once a token is used, it's supposed to be expired and no longer in use. Both the expiry timestamp and the nonce fields already handle those use cases.
        iamwil 8y ago
        Suppose to be once per request and short-lived. But that's not specified in the thread above. Previous person mentioned logout, so I assumed we were talking about session tokens--which I understand its a misuse of JWTs--and is why he/she's mentioning it. But if we're talking about just one time auth tokens, then yeah, you don't need expiry ahead of the expiry time, and it's plain it's a non-issue.
dec0dedab0de 8y ago
I recently started using JWT and had the same problem, I ended up keep the expiration very low and having the client constantly refresh when they need it, and just forget it when they don't
- andrewstuart2 8y ago
  This is a very popular conclusion when considering AuthN and invalidation. Keep the state at the provider and just prevent issuance of new tokens (whether signed certs, JWTs, etc) if/when the user requests access be revoked. What you're really doing is externalizing your state to one already universally shared, and which we already have a lot of tools to manage: the current time.
  - abraae 8y ago
    It's a reasonable conclusion too, when revoking tokens because of a hack/leakage. In these situations human reaction times are involved, which will be at least minutes and maybe hours or days. Having tokens with an expiry of e.g 10 minutes, but with no ability to revoke, is a totally reasonable trade-off in these circumstances.
jillesvangurp 8y ago
You can set a ttl in the JWT and you should. But I think you are talking about using jwts as session cookies, which is indeed not something you should be doing without having a reliable way to invalidate them if you care about reliable signout and token invalidation. For that ttls are not a great solution. We don't currently use them for sessions, but I've been planning to. When we do, we'll have a mechanism for invalidating tokens, just like we currently do for our oauth tokens. One way would be to simply embed that in the jwt as a field and check that on each request, just like we do already with oauth. The biggest risk with either oauth or jwt tokens is somebody intercepting them and using them. This risk is about the same for both but it does need consideration. We are using jwts internally for authorizing messages on our queues and internal API calls. Those jwts have very short ttls and don't leave our infrastructure. They typically include assertions on scope, userids, etc. I've been considering to make JWTs the native format on our queues; i.e. embed the message in the JWT rather than a jwt in the message. This would make message tampering harder for any man in the middle attacks. We already uses nonces in some of our messages so we'd be able to prevent replay attacks this way as well. The main benefit of using jwts is that verifying them is trivial and can be done without network interaction. Very nice in a microservice type architecture. Jwts are issued on our API server are after verifying the oauth token (not jwt currently). We don't leak these tokens outside our infrastructure currently and we don't have public endpoints that would accept them in any case. None of this is new but not that common in modern REST/graphql type setups nevertheless. JWTs are probably easy enough to retrofit in most APIs that it might be worthwhile exploring this for many. If you are interested, we open sourced our Java code for creating/verifying JWTs. Check here for an example and more code: https://github.com/Inbot/inbot-utils/blob/master/src/test/java/io/inbot/utils/JwtTest.java https://github.com/Inbot/inbot-utils/blob/master/src/test/ja...

by sjroot 8y ago

This page doesn’t have any discussion of strategies for expiring JWT, one of the biggest security issues with this auth mechanism. Even the code sample doesn’t include an expiration.

redbeard0x0a 8y ago

The JWT has a built-in field called exp, which is the time the token is expired. This is built in. However if you need to 'expire' a JWT token early, there isn't a good way to do it. If your token has a JTI, then you could add a blacklist for that JTI (say in redis, with a TTL until the token's exp time). But that is left to the implementor.

sjroot 8y ago
The page mentions the ‘exp’ field, but doesn’t use it in its example. I was suggesting the author point out the fact that, if someone gets a hold of a JWT without an expiration, then your system is in quite a bit of trouble.
- shkkmo 8y ago
  It is up to your implementation if you consider JWTs without an exp field to be valid. Our implementation requires a number of fields that are optional in the spec.
crescentfresh 8y ago
So that's what JTIs are for!! I disabled [generating] them in our app, I couldn't figure out what purpose a unique-identifier-per-jwt would have, when you could just use the jwt itself to uniquely identify itself.
incadenza 8y ago
My issue here is that expiring JWTs involve adding state! The whole point of JWTs is stateless authentication, so I’ve never understood the advantage over sessions unless revoking tokens is never an option.
- evan_ 8y ago
  One way to look at it is, presumably you will have far fewer revocations than active sessions, so why optimize for that case? Instead of an "active sessions" table you could just maintain a list of revoked sessions and check each incoming request against that list. You can make revocations expire shortly after the JWT was set to expire.
- hinkley 8y ago
  When are you expiring tokens ahead of their natural expiration date? When someone logs out? Isn’t that state? If you add state to something stateless you are generally on your own. [edit: also I disagree with the notion that something with an expiration date is stateless. It has two states. It’s just that the look like idenpotence]
  - incadenza 8y ago
    Perhaps revoking is the better term here. At least that's the use case I had in mind. If you want the ability to revoke a token, you have to have some list of black listed tokens somewhere.
  - iamwil 8y ago
    When someone's account is compromised, is another situation.
    - geezerjay 8y ago
      > When someone's account is compromised, is another situation. Why is that scenario relevant if tokens are supposed to be used once per request and short-lived? Once a token is used, it's supposed to be expired and no longer in use. Both the expiry timestamp and the nonce fields already handle those use cases.
      - iamwil 8y ago
        Suppose to be once per request and short-lived. But that's not specified in the thread above. Previous person mentioned logout, so I assumed we were talking about session tokens--which I understand its a misuse of JWTs--and is why he/she's mentioning it. But if we're talking about just one time auth tokens, then yeah, you don't need expiry ahead of the expiry time, and it's plain it's a non-issue.

dec0dedab0de 8y ago

I recently started using JWT and had the same problem, I ended up keep the expiration very low and having the client constantly refresh when they need it, and just forget it when they don't

andrewstuart2 8y ago
This is a very popular conclusion when considering AuthN and invalidation. Keep the state at the provider and just prevent issuance of new tokens (whether signed certs, JWTs, etc) if/when the user requests access be revoked. What you're really doing is externalizing your state to one already universally shared, and which we already have a lot of tools to manage: the current time.
- abraae 8y ago
  It's a reasonable conclusion too, when revoking tokens because of a hack/leakage. In these situations human reaction times are involved, which will be at least minutes and maybe hours or days. Having tokens with an expiry of e.g 10 minutes, but with no ability to revoke, is a totally reasonable trade-off in these circumstances.

jillesvangurp 8y ago

You can set a ttl in the JWT and you should. But I think you are talking about using jwts as session cookies, which is indeed not something you should be doing without having a reliable way to invalidate them if you care about reliable signout and token invalidation. For that ttls are not a great solution. We don't currently use them for sessions, but I've been planning to. When we do, we'll have a mechanism for invalidating tokens, just like we currently do for our oauth tokens. One way would be to simply embed that in the jwt as a field and check that on each request, just like we do already with oauth. The biggest risk with either oauth or jwt tokens is somebody intercepting them and using them. This risk is about the same for both but it does need consideration. We are using jwts internally for authorizing messages on our queues and internal API calls. Those jwts have very short ttls and don't leave our infrastructure. They typically include assertions on scope, userids, etc. I've been considering to make JWTs the native format on our queues; i.e. embed the message in the JWT rather than a jwt in the message. This would make message tampering harder for any man in the middle attacks. We already uses nonces in some of our messages so we'd be able to prevent replay attacks this way as well. The main benefit of using jwts is that verifying them is trivial and can be done without network interaction. Very nice in a microservice type architecture. Jwts are issued on our API server are after verifying the oauth token (not jwt currently). We don't leak these tokens outside our infrastructure currently and we don't have public endpoints that would accept them in any case. None of this is new but not that common in modern REST/graphql type setups nevertheless. JWTs are probably easy enough to retrofit in most APIs that it might be worthwhile exploring this for many. If you are interested, we open sourced our Java code for creating/verifying JWTs. Check here for an example and more code: https://github.com/Inbot/inbot-utils/blob/master/src/test/java/io/inbot/utils/JwtTest.java https://github.com/Inbot/inbot-utils/blob/master/src/test/ja...