4 ms·

No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation. Thus instead of us

No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation. Thus instead of using a turnkey solution you need to add an additional layer of state logic to your authentication code if you want to be able to revoke tokens. It is also correct that JWT 1) supports far more cryptography than is necessary; and 2) supports weak cryptography. You can do better than JWT for session management security and performance merely by generating pseudorandom tokens, associating them to sessions and performing lookups. More generally speaking: signed, stateless tokens are attractive for a variety of technical reasons. They have legitimate uses. But it's typically a poor security decision to choose them in lieu of revocation, for reasons which are mostly uncontroversial among those who work in security.

geezerjay 8y ago
> No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation. That's technically false. JWT features multiple systems of revocation, including the use of nonces. Token revocation also features prominently in JWT's basic workflow. The key aspect is that there is no turnkey implementation, and thus projects need to roll their own implementation, which is frowned upon some developers.
- throwawaymath 8y ago
  By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. It naturally follows that no JWT implementation provides a turnkey solution for revocation, because it's not intended to. JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. Yes, you can retrofit your stateless authentication system with a stateful revocation system. But at that point you're back to square one and the architect working on this should consider why they're undoing the legitimate benefits JWT provides. Nonce based revocation is an active process. Timestamp expiry is not actually revocation, it's expiry. If your token is compromised prior to expiry, you're out of luck.
  - geezerjay 8y ago
    > By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. That's patently false. JWT's basic workflow features token refreshes, issue and expiration timestamps, and even nonces, and the backend workflow also supports arbitrary token rejections to trigger token refreshes. The only aspect of JWT's workflow that is left as an implementation detail is tracking revoked tokens. > JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. This sort of argument is ivory tower nitpicking stated disingenuously. JWT include issue and revocation timestamps, which already renders the workflow stateless. The only stateful aspect, which is silly nitpicking and technically irrelevant, is keeping track of nonces and arbitrarily revoked tokens, which require keeping a database to track revocations.
    - moltar 8y ago
      If you have to track revoked tokens you might as well track active sessions via a session ID.
      - weego 8y ago
        That's just an argument ignoring the realities of scale. In any reasonable system the number of tokens that need to be held in blacklist until seen will be tiny in comparison to active sessions.
        nindalf 8y ago
        How does it matter how many tokens are in the blacklist? You're looking them up in a DB where the lookup time in lg(n) anyway. To give you an idea of how little it matters, let's say a small blacklist would be 10k tokens while a list of all tokens would 10M. log(10k) = 13.28. log(10M) = 23.25. It's only marginally more, because the main latency of the DB request is the network round-trip time. The actual issue here is that a lookup needs to be performed at all. For every request, you need to pay the latency of one DB round-trip as well as maintaining code that does this lookup. And if you're going to do that anyway, why bother with this complexity of "stateless" tokens?

geezerjay 8y ago

> No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation. That's technically false. JWT features multiple systems of revocation, including the use of nonces. Token revocation also features prominently in JWT's basic workflow. The key aspect is that there is no turnkey implementation, and thus projects need to roll their own implementation, which is frowned upon some developers.

throwawaymath 8y ago
By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. It naturally follows that no JWT implementation provides a turnkey solution for revocation, because it's not intended to. JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. Yes, you can retrofit your stateless authentication system with a stateful revocation system. But at that point you're back to square one and the architect working on this should consider why they're undoing the legitimate benefits JWT provides. Nonce based revocation is an active process. Timestamp expiry is not actually revocation, it's expiry. If your token is compromised prior to expiry, you're out of luck.
- geezerjay 8y ago
  > By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. That's patently false. JWT's basic workflow features token refreshes, issue and expiration timestamps, and even nonces, and the backend workflow also supports arbitrary token rejections to trigger token refreshes. The only aspect of JWT's workflow that is left as an implementation detail is tracking revoked tokens. > JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. This sort of argument is ivory tower nitpicking stated disingenuously. JWT include issue and revocation timestamps, which already renders the workflow stateless. The only stateful aspect, which is silly nitpicking and technically irrelevant, is keeping track of nonces and arbitrarily revoked tokens, which require keeping a database to track revocations.
  - moltar 8y ago
    If you have to track revoked tokens you might as well track active sessions via a session ID.
    - weego 8y ago
      That's just an argument ignoring the realities of scale. In any reasonable system the number of tokens that need to be held in blacklist until seen will be tiny in comparison to active sessions.
      - nindalf 8y ago
        How does it matter how many tokens are in the blacklist? You're looking them up in a DB where the lookup time in lg(n) anyway. To give you an idea of how little it matters, let's say a small blacklist would be 10k tokens while a list of all tokens would 10M. log(10k) = 13.28. log(10M) = 23.25. It's only marginally more, because the main latency of the DB request is the network round-trip time. The actual issue here is that a lookup needs to be performed at all. For every request, you need to pay the latency of one DB round-trip as well as maintaining code that does this lookup. And if you're going to do that anyway, why bother with this complexity of "stateless" tokens?