[geezerjay]

Yes, that's patently false.

The exp payload field is even specified in JWT's RFC along with the token rejection workflow.

https://tools.ietf.org/html/rfc7519

The same document also specifies the jti field which is the JWT's nonce.

[throwawaymath]

Again, expiry is not revocation. This is an uncontroversial fact - if you disagree, please advise me as to how you'd revoke a token prior to its timestamp-mandated expiration without augmenting it further.

And the jti field is not intended for what you think it is. Anti-replay is not at all the same as revocation. Those are different things entirely.

I certainly believe (and have seen) the jti field used in the manner you describe. But no, that workflow is not intended for revocation. Which makes sense given the design intentions of JWT, because anti-replay can be accomplished as a stateless process, while revocation cannot.

[stetrain]

You replied to this:

"It's a common practice to add expiry timestamp for such tokens so each token will expire after certain interval."

With this:

"That's dandy, but it's a solution which is neither standardized nor native to JWT."

People are providing evidence that token expiration is native to JWT to refute that statement, while you are arguing in parallel that "expiry is not revocation" which is related but separate.

[geezerjay]

> Again, expiry is not revocation.

Issue and expiration timestamps are used along with nonces to enforce single use tokens. Once a token is used then the client is expected to discard and refresh the token.

Implementations are also free to keep track of issued tokens and that does not pose any problem in the real world.

> And the jti field is not intended for what you think it is. Anti-replay is not at all the same as revocation.

Why are you expecting to revoke a token in a scenario where the token is supposed to be used once?

Either the token is deemed valid and accepted or it's invalidated and rejected, which triggers clients to refresh the token and retry the request.

[kilburn]

> Why are you expecting to revoke a token in a scenario where the token is supposed to be used once?

An attacker was able to somehow issue a bunch of tokens for himself. Now you want to invalidate them even though they're not used yet.

> Either the token is deemed valid and accepted or it's invalidated and rejected, which triggers clients to refresh the token and retry the request.

The other point here is that you are probably (not always, not in every possible case, but in most common cases) better off using just a bearer token (refresh it on every use if need be). There's no performance benefit in using stateless tokens when they can be used only once, and handling bearer tokens is much easier from a gun-to-shoot-your-feet-with perspective.

[yebyen]

> An attacker was able to somehow issue a bunch of tokens for himself

I'm not expert in JWT and just jumping in here, but wouldn't that imply total compromise of the PKI if this ever happens?

I'm saying, if this scenario comes to pass, with basically any old authentication system, isn't it now time to roll the master keys and invalidate _every previously issued_ token/session the old-fashioned way, by disavowing the prior signing key, and then bouncing every user/ requiring to re-auth freshly and establish brand new sessions within the totally new PKI?

I assume this is always still possible even with JWT from what I've read so far, but I'm happy to be educated if either of you don't mind sharing.

[kilburn]

> I'm not expert in JWT and just jumping in here, but wouldn't that imply total compromise of the PKI if this ever happens?

Not necessarily. Let's say I steal your password and use it against the auth endpoint to get 10 one-time tokens for your account. Re-rolling the master key is a solution, but a very radical one if I can just invalidate all your tokens don't you think? ;)

[geezerjay]

> Not necessarily. Let's say I steal your password and use it against the auth endpoint to get 10 one-time tokens for your account.

The tokens are valid, thus there is no objective reason to reject them other than there was an unrelated security failure elsewhere in the system.

Additionally, tokens are generated per request and are short-lived, with an expiration timestamp that is just enough to send a request to the server.

When the token is passed to the server, the nonce is added to the server's scratchpad memory to revoke the token and thus avoid replay attacks. If anyone for some reason wants to revoke a token, they only need to add the token's nonce to the revoked list. If the nonce is present in the list then the server rejects the token and triggers a token refresh.