Hacker News Reader

Comment by altmind | Hacker News Reader

JWT were aiming to be stateless, yet they cannot be stateless if you need them to be revocable. If you keep using plain sessions you got a SPOF, but you are immune, for a whole lot of consistency and cred management problems.

http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...

View on HN

To be clear though you generally set the validity to be relatively short and refresh often, so that way you don’t have to worry too much; you can then “revoke” a token by refusing to refresh it.

The link seems to think this is impossible but I don't understand why.

Don’t see the word “refresh” in there. Guessing they are assuming you use JWT identically to how you might use a session cookie, which is not how I’ve ever seen it used, personally.

In the diagram in the bottom right they seem to think you cannot revoke the long term token. I agree that it doesn't align with my understanding of whats capable with oauth2 style tokens, for example.

That box should probably read: “You can't revoke the long-term tokens in a stateless manner, so supposing you truly manage ZERO state, then you're back to square one.”

That seems like the charitable interpretation. Note that the author’s point has not been that JWT is useless, but rather that trying to use stateless JWT for sessions is a bad idea.

If the point of using for JWT was to avoid all server side state in authn/authz flow — which is the case for many, many developers, and that is the intended audience of the author’s post — then one of two things: you either contradict yourself and implement server side revocation for refresh tokens, or you let the lifetime of your sessions be the same as the refresh token — and in the case of refresh tokens with no expiry, the user (or anyone with their refresh token) can stay logged in forever.

But then it isn't stateless, right? Because you need to know which current tokens are unrefreshable.

To me, JWT works great for things like physical people getting access to a physically isolated building, like a military research site that's disconnected from the internet. Some secure other place holds the private key and signs the JWT token then you can wave in anywhere you need to go until the validity period is up. Then you have to go back to the secure place to get a new key, verifying the same way you did the first time and the secure place can broadcast its public key to the sites you want access to. It's essentially a great mechanism where you don't have constant communication links.

But I just don't get it for servers. Also, everyone considering using a JWT token should know about the "algorithm none" setting and ensure that their stack isn't vulnerable to it.

But then it isn't stateless, right? Because you need to know which current tokens are unrefreshable.

You only have to involve state in 1 request every 10-15 minutes upon refresh. All other requests can be done without having to check for revocation. This is a pretty nice real-world tradeoff.

While I haven't taken the leap to using a JWT in any of these cases yet and am a little bearish on them, I do also feel like the baby goes out with the bath-water, here.

Nothing about adopting JWT says you can't still use a full auth check for state-changing endpoints, and use a stateless session to shave some evaluation time off of frequent read-only requests for data that isn't terribly sensitive.

You probably shouldn't do it lightly or prematurely since it makes it harder to reason about authentication, but I think it's worth considering whenever you're optimizing.

You always have to authenticate the JWT anyways to verify data hasn't been changed. The stateless part is the fact that the sensitive data is stored in the JWT itself instead of retrieved from a DB. As long as you can validate the HMAC / Signature then you can assume the contents of the JWT haven't been altered and can therefore trust the client's data.

Authenticating JWT isn't checking the JWT against an external server.

How can you validate that it was properly signed without comparing it to the entity's public key?

Why would you need to make a request to another server for this purpose?

Hint: you don’t — but I figure taking the Socratic approach may be more convincing.

You could pre share a public key, but a common way is to use the discovery mechanism in OIDC to automatically manage key distribution/rolling.

Because else how do you handle key revocation?

Which is the point of the post.

If you need to do revocation you need to call an external server.

If you need to call an external server why do JWT?

Because pinging another server for a few bytes of data and offloading that working memory to the client side is much more efficient than storing the session data in server memory in between requests. Furthermore a single coordinating key server can work in conjunction with many micro-services to simplify architecture, security, and hardware requirements.

Which still leaves a window for JWT to be re-played. If you store something valuable, like # of credits left on a users account, the user can spend some, and then re-use an old jwt to spend again.

Actually creating a JWT token is not stateless, but at least your architecture is not centralized. If your auth server goes down, that’s a problem no matter what.

A common validity period is around 1 hour, which is good enough that most users won’t need to refresh very many times per day.

Also: you don’t necessarily need to track tokens that aren’t refreshable. A typical architecture might have a timestamp stored per user that specifies the earliest token creation date that’s valid for refresh. That way you can invalidate all tokens without needing to ever store them; something you might need to do for password reset, for example.

> A typical architecture might have a timestamp stored per user that specifies the earliest token creation date that’s valid for refresh.

Never worked with JWTs but still, can't believe I didn't think of this. It seems like a fairly elegant way to revoke things where your only stored state is a timestamp.

> A typical architecture might have a timestamp stored per user that specifies the earliest token creation date that’s valid for refresh.

There's a race condition there, though. If you have a revocation event and set the timestamp, it's possible that an in-progress refresh might have a timestamp just slightly after your stored timestamp. Then you have a rogue JWT that can continue to be refreshed.

Clocks are sometimes not in sync with millisecond precision. Databases don't replicate instantly. Distributed systems just don't work that way.

You could instead store a "generation", and increment on revocation events

It’s stateful for the auth service, stateless for the relying party.

>algorithm none

I just read about it on Auth0 [0] and facepalmed. Then I went to node-jsonwebtoken to ensure they added an ‘algorithm’ argument to a ‘verify’ call and you guess what [1].

They added ‘algorithms’, but into ‘options’, so that naive user like me could just skip it and stay open to attacks. That’s auth0’s own module, btw.

Thanks for pointing that out!

[0] https://auth0.com/blog/amp/critical-vulnerabilities-in-json-...

[1] https://www.npmjs.com/package/jsonwebtoken#jwtverifytoken-se...

Use a proper JOSE module like https://www.npmjs.com/package/jose that uses native node's crypto key objects (ergo not leaving you vulnerable to HMAC based validation bypass) and doesn't even implement "none" algorithm.

The state necessary to revoke JWTs is easier to manage than session state.

1. It's small (id per revoked, nonexpired JWT)

2. It isn't sensitive, nobody learns anything by seeing the list of revoked JWT ids.

3. It's monotonic. You just maintain a set that you add to. You can clean up expired tokens if you want but that's not necessary for correctness.

These three items make bugs less likely and make it easier to manage consistency when you can't afford to use transactions everywhere.

The monotonicity alone makes the required state _very_ easy. Adding (timestamp, jwt_id) pairs to a monotonic set which you occasionally switch over to a second, fresh set (checking against both, adding to one) requires zero coordination in the critical path. The only coordination required is about when the sets are switched, where you need to ensure that you leave ample time for old JWTs to expire before clearing the corresponding revocation set entries.

Rather than blacklist JTIs would it not be simpler to keep a valid after date on the user? Any token issued before that date is not acceptable

Then you can't have users sign out of device A while remaining signed into device B.

Revoking per-JWT requires state per-JWT, but you can get away with globally-revokable tokens ('logout everywhere' functionality) with a single nonce-per-entity instead of a nonce-per-JWT, which is a bit nicer.

Right.

One point to keep an eye on is, if you are using (e.g.) AWS API Gateway with a custom authorizer, it caches the authentication response for a certain time.

This is not a problem of jwt, but makes the 'logout everywhere' and every black and whitelist need some more time.

You can revoke all JWTs by changing the signing key on your server. All previously issued JWTs will be invalid.

Sure, but that's the nuclear option. Imagine if Facebook did that every time one account was compromised or they fired a staffer?

Facebook as the largest userbase of any application in existence. Its needs may not equate to your needs. For example, an enterprise b2b app with a few hundred customers could probably "deal with" the nuclear option.

I'd be pretty upset if I got kicked out of a work app every time one of a few hundred companies fired someone (or even had to do a password reset for a security reason).

You don't use a tool for managing your passwords? That's built into most browsers these days.

The issue is not remembering the password.

The issue is I just logged in 90 seconds ago, typed up a few paragraphs, and when I go to submit I have to do it again, because someone in another company using the tool got phished and needs a new password.

It's frustrating enough when Gmail makes me put my password in after 30 days and I just clicked into an email I wanted to read. Having it happen all day long would make me want to kill someone.

I wasn't suggesting mutating the signing key multiple times per day or once per 90 seconds. At that point, you might as well just have a very early JWT expiration timestamp specified.

The comment thread started with "if you need them to be revocable". Any tool with "a few hundred [enterprise] customers" needs to be able to revoke access for terminated employees, compromised accounts, and the like, and those revocations will occur frequently and in many cases need to have immediate impact.

A multi-tenant system could use a different key-pair for each tenant and only revoke the one for the compromised entity

Man I'm not sure I agree with that. Blowing up a bunch of your clients that rely on your services randomly because one account was compromised is not acceptable for really any professional business regardless of the number of clients.

"Blowing them up" is a mischaracterization of the situation. You are not mutating their data. You're only asking them to login again.

Actually blowing them up is a completely appropriate description if you have any non-human's relying on JWTs.

Applications that use authenticated services need to handle being the authentication being revoked. That's fairly obvious regardless of how it happens. If your app doesn't then it's broken.

So now every user has to log back in again every time you upgrade your server, simply changing the signing key or when your backend gets compromised.

Additionally JWEs don't support forward-secrecy meaning that I can MITM and collect all JWEs passing through, find the key in your compromised backend and decrypt ALL these collected tokens.

No need to do this with JWTs since they're unencrypted by default.

Your server shouldn't be getting compromised on a regular basis. The occasional black swan event occurs, and sometimes you have no other choice.

Users get compromised though and will want to revoke sessions. But this is why you just set a time limit on your JWT, so that they can revoke and within N minutes the old sessions will die. Just keep N low.

It's not stateless, it just uses a blacklist instead of a whitelist.

An approach I have used in the past is including the optional `kid` header. The key id can be matched to the appropriate key needed to verify the signature. If you associate every user with a key, that means you can also delete any key and thus revoke the jwt of a particular user.

In this case obviously you have a persistence layer for the keys and can't claim to be absolutely stateless.

https://tools.ietf.org/html/rfc7515#section-4.1.4

> If you keep using plain sessions you got a SPOF

What single point of failure is inherent with plain server side sessions and a session cookie?

The server.

... ok so assuming you then don’t have a HA environment (Really!?) if the server is down the sessions and the tokens are irrelevant because there’s nothing being served and nothing to use/check them and provide back resources.

You don't have to store them purely in-process. The session data itself can live in Redis. You can scale sessions beyond a single web server.

So wait, why does the refresh token not work? Why wouldn't you verify user permissions when generating a new access token?

You need a really short refresh cycle for that to be useful to customers. If your customer FooCorp fired Bob, they want to be able to disable his access immediately, not in 3 days when his access token next needs a refresh.

15 minutes seems to satisfy most use cases.

Remember that the author’s intended audience is developers who want to use JWTs specifically to avoid server side state in the authentication/authorization logic. The point is that, if you want to revoke the refresh token, you have to maintain a blacklist somewhere, and now you’ve contradicted your original goal of avoiding all state, which means that choosing JWT for this particular purpose was illogical, and probably warrants further thought. (TBC, in logic, if your hypothesis leads to a contradiction, then your hypothesis must be false, which is exactly what we’re seeing here in this scenario.)

> revoke the refresh token, you have to maintain a blacklist somewhere

Store CreationDate in the refresh token. Store RefreshTokenInvalidBefore in the user record. When refresh is attempted, if Token.CreationDate <= User.RefreshTokenInvalidBefore, reject the refresh. The only drawback here is that it would sign the user out on all devices. However, assuming this is because of a password or token compromise, that's likely the least of their worries.

I disagree. If you make an API Gateway responsible for that concern then it's the only thing that needs to maintain state. The blacklist itself probably kept in something like Redis and the API Gateway just checks against it. Then all downstream services get the benefit of JWT in a "stateless" fashion as advertised. That is, none of the downstream services know or care about any state. They get a request with a JWT and if it has the right claims, it services the request.

I don't see this as rendering JWTs useless, though. If you have a 10-15 minute validity time, and you only check for revocation on refresh (and perhaps, optionally, on sensitive operations), then you don't have to check the the revoked-tokens table on every request, which means your database doesn't have to scale up nearly as much.

And since the IDs in the revoked-tokens table only matter for the duration of token validity, you can prune the table pretty often, meaning necessary space needed in the DB is relatively small.

It's certainly more complicated than just dealing with stateful session tokens, so you might decide that the trade off isn't worth it, though.

For more secure apps we use single use tokens and expire within a very short period of issuance, i.e. invalidated upon use, and exp (expiry) set a few seconds after iat (issued at). Not optimum for performance because you need to get a new token with every request, but means you never have to worry about having to revoke them. Not heard of anyone in the finance sector using JWT for session management, but that's not what they're for.

Of course you can. Put your auth behind a sane CDN with TTL of forever, the kind that allows tagging an arbitrary number of objects with a single tag and allow to purge objects matching a tag in a single call within a few milliseconds.

Tag them with sec-uid, sec-uid-dev-id, sec-devclass, sec-we-dont-like-user etc to group them together.

Want to kill sessions of just user uid? Hit a purge endpoint that purges all objects with sec-uid. Want to kill a session for a specific user for a specific device? Hit the purge endpoint that purges all objects with a tag sec-uid-sec-devid. Want to logout all users on an iPhone because "oops, security bug in a version we rolled out"? Hit an endpoint that purges all the docs tagged with sec-devclass of an iphone.

You don't even need to remember tokens you issued.

You are describing stateful authentication.

Nope. You don't even need to know you issued those tokens or their state. You don't ever assert a state or check it. You force its recompute via cache bust.

You don't need to know a token of jakelazaroff. You don't need to know its state. You don't even need to know if it exists.

You know that a token associated with jakelazaroff iphone if it exists will have a tag jakelazaroff-iphone because every token associated with <user> iphone will always have a tag <user>-iphone since you always tag a token of any <user> on an iphone with a tag <username>-iphone when you issue the token.

I don’t understand your explanation, but the words that you’re using (e.g. “purges”, “cache”) indicate that you’re describing a stateful system.

Imagine you’re writing your API on AWS Lambda, so memory and the file system are not shared between requests. A client presents your API with a token. Using no external resources (no database hits, no network requests, etc) how do you determine the veracity of that token?

Edit: I think I understand what you’re saying. Using a CDN that will let you “tag” resources and conditionally provide access based on whether HTTP headers match those tags, you issue tokens to clients and add or remove tags to give and revoke access. The CDN determines whether a given tag can access the resource, and your application doesn’t worry about authentication.

This is still stateful. The tags are the state!

Correct. I can assert a validity of the token without touching any database. Not only that, but the API does not even need to compute what it is. That's what makes it stateless.

It’s not stateless, you’re just trading a database for “tags”. This is exactly the same as if you just placed a stateful authentication service that checks a database in front of your API. How do you think the CDN works?

I guess the idea is that it's "stateless" in the sense that you don't have to maintain the state yourself, and the CDN will do it for you? I mean... okay, I guess the point of being stateless is that you don't want to deal with the scaling and reliability issues around storing state, so pushing that responsibility onto a third party (whose uptime is required to get to your site anyway) is "stateless" from your perspective.

I certainly wouldn't call that "stateless", but it does fulfill the main reason why you might want to be stateless, that you don't have to maintain any state yourself.

The reason why it is stateless is because there's no state associated with a token that I have to maintain.

Exactly — it's basically the same as writing your own separate authentication service, or using Auth0/Cognito/Firebase.

You do not maintain the tags. You compute the tags and you do not care what so ever if the tag ever matches anything.

It doesn’t matter who maintains them — the tags are still state. It may be stateless from your API’s perspective, but the system as a whole is still stateful.

> Using a CDN that will let you “tag” resources and conditionally provide access based on whether HTTP headers match those tags, you issue tokens to clients and add or remove tags to give and revoke access.

The tokens are the resource.

Your auth is what tags the tokens. Your auth is the only entity that is able to compute the tags that would match the criteria of the tokens to invalidate them.

Reply on news.ycombinator.com