New Registered Claim: Token Generation?

[paragonie-security]

One of the hard problems with stateless tokens is stateless revocation. (This is why PASETO never tried to be a stateless token.)

There are a couple of ways to force the invalidation of unexpired tokens:

1. Block-list the known-bad tokens. This requires pushing state to the application.
2. Rotate the keys. This creates a lot of false positives in the logs and may provide cover traffic for other hypothetical attacks.

One alternative that we haven't seen explored in the JWT world is the concept of Generations.

• All tokens are minted with the current generation (e.g. 1).
• When an incident occurs that requires block-listing unexpired tokens, instead of pushing a lot of state to the application, just increment the current generation and ensure your parser has a rule enabled that blocks tokens from previous generations.

Thus, our proposal is to add a registered claim called gen that contains a hex-encoded big-endian 64-bit integer, as well as parser rules for handling token generations.

[panva]

This does not help with invalidation of existing tokens any more than rotating keys already does. If anything it is yet another value a recipient needs to learn out of band to properly validate a token. And in v3/v4 this can be achieved with the implicit assertion already.

The issue at hand is not usually blanket revocation, it is revocation of individual tokens after security events such as logout, password change, etc.

[paragonie-security]

This does not help with invalidation of existing tokens any more than rotating keys already does.

If your key is compromised, you have to rotate keys anyway.

But if your key wasn't compromised but you have another reason to want to invalidate tokens, this makes it a parser rule validation error rather than a cryptographic validation error.

The difference may matter to some people. Thus, the proposal.

And in v3/v4 this can be achieved with the implicit assertion already.

Excellent point.

The issue at hand is not usually blanket revocation, it is revocation of individual tokens after security events such as logout, password change, etc.

Excellent point.

---

I think we're going to say 'No" to this idea, but felt it was worth pondering.