JWT vs. Opaque Tokens

Don't roll your own JWT implementations for client side applications, for the love of dog don't.

Story time.

Our company recently switched to JWTs for our SPAs from regular OAuth2. I told them up front - we need a way to invalidate a token if an account is compromised. The lead on this initiative said we can blacklist any token. I told him that's not practical because you would need to know the exact token to be able to blacklist and because we don't store them in the database and don't log them have any real way to figure out which token is being used by an attacker and which are not that it's basically useless.

I suggested a simple fix: cypher the private key we sign the JWT with the hashed password of the user account we're generating the token for. If an account is compromised, we can reset the password and invalidate all tokens for that one user.

I was ignored and lo-and-behold within a month CTO and tech lead are trying to track down JWTs for a hacked account. I told them we can update the app to cypher the key, it'll invalidate all tokens and people will have to log in again but at least they'll be secured. Nothing has been changed to this day, despite banging this drum for literally over a year. We've recently extracted our authentication into a micro-service (for no reason really, i'm still mad about this too) and still nothing has been done about this issue when it would have been the perfect time to fix this.

I love my job but "priorities" and "business cases" as an excuse for this kind of incompetence is rage inducing.

The point I'm trying to make is. You are most likely using some kind of web framework that can just plug in an authentication implementation, just use that. NIH is very real and it is more than a waste of time, it can be dangerous.

Session tokens need to be stored on the server (redis, db, etc..) so you can change them, see all devices logged in, and other requests product will have.

They should be unguessable and unrelated to anything. Read 20 bytes from /dev/urandom (or whatever stdlib your language provides), create an entry in your store for token->user_id, then put it in a httpOnly + secure cookie (so Javascript can't access it), and send it to the client.

> The whole point of the JWT is that you know with confidence that the client has the data you need and cannot change it

I would change that to "The whole point of the JWT is that you know with confidence that the client can provide tamper proof data, often identity, to other servers and APIs."

Yes, the OIDC id token is for the client to consume, but if it is an access token, it is for the resource servers (to slip into a bit of OAuth jargon). Put whatever you want in the id token, knowing the client will have full access to it. If it is a javascript or native client, you don't know where that will go, but having it shouldn't grant access to anything privileged.

As this applies to access tokens, if your application doesn't need a JWT, it shouldn't care whether the authorization server returns a JWT or an opaque token. On the flip side, if your app needs a JWT, then the authorization server must return one.

Revocation is either offered by the authorization server or managed by the app. If the authorization server manages it, then JWTs vs. opaque tokens are not a concern because the authorization server issues and revokes its own tokens. If the app manages it, then generally it does so based on the token type. If the app revokes based on opaque tokens, it can handle any type of token, including JWTs. If it revokes based on JWTs, then JWTs are required.

Beyond that, the only differences between the two token types are size and data leaks. Size rarely matters (hehe), so just ignore that. Data leaks are only an issue if you app is leaking JWTs, which is usually considered a critical vulnerability. Remember that access tokens are the main units of identity and if I steal an access token, I effectively become that user/client.

Spot on. Even better if they used a better serialization protocol than stupid JSON.