[throwawaymath]

That's dandy, but it's a solution which is neither standardized nor native to JWT. It's also a weak, passive form of revocation instead of a robust, active form. How do do you revoke a token prior to timestamp expiry?

In 2018 it is fully possible to use authentication libraries which natively support granular control for things like revocation using strong, turnkey cryptography. I would argue most people who think they should be using stateless and signed sessions for e.g. performance are heavily discounting the revocation liability and neglecting to optimize their lookups sufficiently (such as by caching).

[kokokokoko]

Revoking a bearer token is trivial and in all likelihood, revoking tokens is a very infrequent event. In most cases it is such a rare event that you can usually commit your blacklist to source code.

If not a service to validate tokens against a blacklist is again trivial and will scale to all but the top 0.1% of organizations. And it only needs to be in the blacklist long enough for the period until the token expires.

Yes, jwt is not ideal. But this talk that you should never ever use them and your service will be immediately hacked etc is silly internet bandwagoning.

For a huge percentage of services jwts are just fine. Anyone reading this, please do not over think this advice and just ship with jwts if that is what you have.

[throwawaymath]

> Yes, jwt is not ideal. But this talk that you should never ever use them and your service will be immediately hacked etc is silly internet bandwagoning.

I never said you should never ever use JWT or that your service will be hacked if you do so. In fact, if you kindly reread what I wrote you'll see that I explicitly mentioned there are legitimate use cases for JWT. I am specifically refuting the use of JWT as an authenticated session management system.

> Anyone reading this, please do not over think this advice and just ship with jwts if that is what you have.

This is poor advice.

1) Authentication is sufficiently solved for most workflows and applications that you can use turnkey solutions for more secure and more performant authentication than JWT.

2) What exactly is the scenario you envision in which JWT is all someone has? Do you mean they're forced to use stateless session management, or that JWT is literally all they can do for authentication because nothing else is available?

[virtualwhys]

> What exactly is the scenario you envision in which JWT is all someone has? Do you mean they're forced to use stateless session management, or that JWT is literally all they can do for authentication because nothing else is available?

Good luck using session cookies with Cordova on iOS, for example [1]. In cases like these JWT is perhaps your only option.

[1] https://issues.apache.org/jira/browse/CB-12074

[geezerjay]

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

That statement is false.

JWT were specifically designed to store a payload JSON object which among the many standardized fields include the token's expiry time, and JWT were specifically designed with a workflow which includes not only client-side token refreshing but also server-side token rejection that triggers client-side token refreshes.

In fact, JWT token refreshes and token rejections feature in any basic intro tutorial to JWT, including the design principle that tokens should be discarded and refreshed by the client as soon as possible and also the use of nonces.

[throwawaymath]

No, it's not false. Tutorial "best practice" guidance does not constitute a standard. JWT does not provide native revocation. Neither refreshes nor expiry constitute revocation. Revocation is an active state change, not a dead man's switch.

[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.

[lmm]

I'd argue that people who think they should be using caching are heavily discounting the consistency issues they will encounter (no doubt at the least convenient time), and may well end up reintroducing the same problem they're trying to solve. If you have revocable tokens accessed via an authentication lookup cache with a 5-minute expiry then you've spent a lot of time and engineering effort to have exactly the same problem as if you had non-revocable JWTs with 5-minute expiry.

[gavinpc]

> In 2018 it is fully possible to use authentication libraries

So — getting back to the OP — which libraries?

[throwawaymath]

NaCL, Fernet or Paseto.