JWT is a token, often stored as a cookie. I don't see how it's impossible to invalidate a JWT but easy to invalidate a cookie or token.

If you treat the JWT as a random token and check whether it is valid in your central database every time, then yes, it behave like a random token and you can invalidate it very easily (just remove it from the list of valid tokens). But then, why use a JWT instead of a random token?

If you treat like it is supposed to be treated and check the cryptographic signature instead of going to a central database, then you can't invalidate it (at least before it expires). You can ask the client to remove it, but what if they don't? (eg. they are an attacker)

JWT is a token that is hard to forge with a payload.

Meaning, if someone gives you a valid JWT that says "I'm user 123" you can trust that this is user 123.

That's all it is. When reading in intent on how it should be used or what you should do with it, that's something beyond what the thing actually is.

So any pattern you can imagine with a session ID, you could implement with a JWT. Just throw the session ID in as part of the payload. Just because you are using JWTs doesn't mean that you don't have to work with any sort of external resource while you are processing it.

What purpose does it serve then? You can still avoid lookups when a JWT makes a claim. You know the JWT is valid so you know that all claims made within it are true. If it claims "I'm user 123" then they are user 123. If it claims "My account number is 435" then that's the account number. You don't have to make a lookup to see those facts are true. If it says "My session is 433" then you can validate that session 433 is still active and act accordingly.

JWT isn't a panacea but it also isn't anything more than a bag of claims. It doesn't claim to be anything else either.

> If it claims "My account number is 435" then that's the account number.

What if the account number changed since the token was created?

This works only for immutable claims. If the truth behind those claims changes in the mean time, you have to be able to invalidate the token, or accept the fact that it serves stale information.

> If the truth behind those claims changes in the mean time, you have to be able to invalidate the token, or accept the fact that it serves stale information.

Isn't that obvious? I mean, if we were talking about sessions and you put in the session set information that can change outside the session, wouldn't the same problem exist?

I just don't see this as a fundamentally unique problem for JWTs.

> Just throw the session ID in as part of the payload

An authenticated session id is just a very very long session id.

    JWT is a token, often stored as a cookie.

This is both true and also misses the point. Session Cookies are ususally stateful. In other words, the server validates the session by querying a service or database. JWTs however are stateless. You don't query a service or database to validate the service. As a consequence if the JWT is not expired and is still using a valid key there is no out of the box way to invalidate the JWT. You can build custom invalidation measures on top of JWT but it's not a natural consequence of the design in the same way that a session cookie is.

If you are using a cookie and managing the session expiration on the server, you can kill it anytime.

Throw a session ID in the JWT and do the same thing.

JWT has a freeform payload that can literally be anything you want. Nothing about it prevents you from using a pattern like this.

If you do this you get 0 value from using a JWT over a regular session id. It's simpler and likely less work to just not use a JWT in that case.

The value add is you don't need a cryptographically secure session id generation mechanism when you work with JWTs.

A simple session ID can be (and often was) forged to grant access to things end users shouldn't have. Put the session id in the JWT and now an attacker can't easily change the session they are associated with.

generating a sufficiently random session id is not difficult. Using JWT doesn't substantially make this easier for you and operationally you are going to have to invest in significant key management infrastructure. If you don't need the stateless nature of JWT you should just not use them.

> generating a sufficiently random session id is not difficult

There are enough CVEs on this specific topic that I tend to disagree. I've been around on the internet long enough to witness a HUGE number of session hijacking attacks. [1]

> Using JWT doesn't substantially make this easier for you and operationally you are going to have to invest in significant key management infrastructure.

IDK about making it easier, but rather using JWTs for this makes it harder to get wrong.

> If you don't need the stateless nature of JWT you should just not use them.

Agreed. Use them when they make sense and not when they don't. I'm not arguing that JWTs are panacea. They are neither good nor bad, just a tool.

[1] https://owasp.org/www-community/attacks/Session_hijacking_at...

> I've been around on the internet long enough to witness a HUGE number of session hijacking attacks.

JWTs don't make it any harder to hijack sessions, in fact, they often make it easier.

Session sniffing and man in the middle attacks don't discriminate between JWT and cookies/session IDs. Nowadays they are very hard to achieve with the vast majority of the web operating over HTTPS with optional HSTS.

Cookies containing the session ID can be marked as HTTP only, unlike JWTs which are often stored in localStorage, which makes them vulnerable to extraction via XSS vulnerabilities.

> using JWTs for this makes it harder to get wrong

Any popular web framework these days should provide secure built-in functions to generate and validate cryptographically secure signed cookies containing the session ID.

JWT libraries have had critical vulnerabilities in the past, such as allowing usage of the badly designed "alg: none" feature of the JWT specification.

https://auth0.com/blog/critical-vulnerabilities-in-json-web-...

JWTs have been in the news a lot for trivial vulnerabilities and among security/cryptography professionals is widely regarded as a problematic standard. I would argue just as you seem to be that the surface area for ways to get them wrong is much worse than session tokens.

You do need a cryptographically secure RNG to work with JWTs though. There's no getting around the need for randomness.

You only need a cryptographically secure RNG to generate a key pair. Assuming asymetric keys. That private key can then be used to sign many many JWTS.

Whereas generating new session ids will always need fresh entropy.

That depends on the algorithm, some depend on randomness like IVs.

Maybe you are thinking of JWE?

If the signing of the JWT wasn’t deterministic, then it would be hard to verify.

Correct. Some auth systems use JWE. Some even use it interchangeably with just JWS.

You can track JWTs on the server, via a sessionId or whatever you wish, it just breaks the intended pattern. If you have to do a lookup on each request (necessary to invalidate the token imperatively) your JWT is no longer stateless which is a core tenet of the JWT approach.

It'd be like building a React app and calling getElementById(id) to update DOM values. You _can_ do it but...

> breaks the intended pattern.

Who's intended pattern? Where is this stated as being the "right" way to use JWTs?

I'm seeing a lot of claims about the intent behind JWTs but frankly I think it's because people are skipping over having a fundamental understanding about WHAT JWTs are and instead are cargo culting on what they believe they should be.

My perspective is that I had recently realized that I didn't have a great justification for having used JWTs in my last two projects (and worried I had been part of a cargo cult myself). Truly.

I can't see their value against a bearer token + session tracking on the server for most cases (e.g. it won't be a huge performance hit to do a lookup of some sort on each request).

The two apps I'm referring to have a few thousand users who only make occasional requests.

I think a lot of apps fall into this broad category and I don't see what extra value JWT is providing. Encoding user data is pretty convenient (though more opaque) but if you want to be able to ad-hoc invalidate them you need refresh tokens or a session list. Not only does that re-introduce needing to do a sort of lookup and server user tracking, the encoded data on the token is no longer a positive, since you bifurcated knowledge of the user (token + list), and all its data would be more discoverable by including it where you are now tracking sessions anyways.

Help me out if I'm missing something. My mind is open.

It’s pretty simple to check a JWT’s issued time again a timestamp representing the last time an account changed password / revoked all sessions.

If the password is changed then the encryption on the JWT is no longer valid though. So it is unusable at that point.

I believe GP is referring to user password not the encryption key. Rotating the encryption key would invalidate all previously minted JWTs. A user changing their password would not because it is not used to sign the JWT, therefore the old JWTs would still be valid until expiry after a user changes their password.

It's my understanding that user's password + a server secret = the encryption key. Changing either one of those will invalidate the token.

Having to look up the dynamic signing key reintroduces a trip to the database. At that point it's nothing more than a session ID with extra steps.

Why in the fresh hells would you store a users password in plain text, in order to decrypt that key?

Even if you didn't you still need to retrieve the user and password from some storage to validate the key, which invalidates the reason for JWTs in the first place, since you supposed to be able to validate them without access to an auth service/db

Plain text?? A user's password is hashed...You don't need a paint text password to compare text encrypted with it to other text encrypted in the same method. Either they match or they don't. The user's hashed password doesn't leave the server and plain text is never involved.

If you use the password's hash as a key, the plain text no longer matters, because the hash is now the thing that an attacker needs to forge a credential. So your database is effectively storing the real password, as if you had not used a hash.

I think I see what you're saying but how would that be useful still? Like is an attacker has a hash of the users password they still don't have the server secret.

The users password isnt involved with the encryption of JWTs

If the user's password isn't involved then what's the mechanism for invalidating existing tokens?

There is none.

And now you're starting to understand why JWT's aren't worthy of the hype. A truly stateless JWT implementation is insecure since you can't invalidate existing tokens.

The usual compromise is make JWTs have a short (<= 15 min) expiration and provide the client with a refresh token that doesn't expire, but is stored server-side. When the user logs out, the refresh token is invalidated server-side so a new JWT can't be issued. You're re-introducing state with this solution, but you're making it so you don't have to bang on a database with EVERY request, just one every ~15 min or whatever your expiration window is.

One could include the SID claim, with this the token at least could be tested against a users session on the IdP/OP. (This is being used in the ID_Token in OIDC)

There is none. Personally, I use it for authentication on a platform where the user shall be logged out after 30 min anyway.

What? Why whould the signaure be invalidated?

Not the cryptographic signature; they mean the authorization.

I.e. if the user's password has been compromised, then the attacker with the password could have started a new session using it. The question is, how do you (allow the user to) revoke the auth that was granted by the compromised password and invalidate that fraudulent session.