Hacker News Reader

Comment by hparadiz | Hacker News Reader

You can make a JWT invalid after 30 seconds or even 1 second. You should set an aud (audience) when creating the JWT. Otherwise the signature is crypto-graphically sound. Validate every single JWT every single time with a short lifetime.

OIDC tokens are all JWTs btw.

View on HN

If your talking about a browser context, where the authority is separate from the requesting body, then expiring even at 30s is excessive for user context, let alone every 1s or every request... you're effectively then inflating every single API request into 2 requests... one for a new token, then another to the API being called. This is irresponsible for not much gain in a user-facing context.

You should not be using them for user contexts at all. The cookie should be the session token and the sessions should be stored on the server side where you can simply delete them and the user's login becomes invalid. Using JWTs for this use case is just plain wrong.

I disagree with you and the article on this... I thought that was pretty clear.

You can use a revocation list with JWT if necessary, and if your JWTs never last more than 15m you'll be fine.. and if your security window is tighter than that, you probably have bigger issues to deal with.

> You can use a revocation list with JWT if necessary

Yes and let me just add that in many cases the use case is such that a revocation list is not even needed and then JWTs are actually stateless and it's a small win for everyone.

Exactly... especially if the expiration is a tolerance window you can handle without revocation at all. I'm a pretty big fan for using it inter-service, APIs and SPA systems.

I think you can use a JWT just fine to introduce a new user into a system but once authenticated just set a classic session cookie with an expiration. I get when you can't for like an API and sure that's where JWTs are best. But a regular website? Not the biggest fan.

But in that case you're just using sessions, and the JWT is a microoptimization to avoid hitting the DB every request.

The ID token is always a JWT when doing OIDC, and it makes sense in this situation.

Because the ID token is not a set of credentials, but signed information you’d use to create/update a user’s profile.

You can technically use JWTs as access tokens, as the spec doesn’t specify a format for access tokens, but in my experience they’re normally opaque bearer tokens.

The main reason I don't like the id token is that I've seen way too many instances of the ID token being used as a trusted identity assertion sent across multiple services or to third parties. This is very dangerous, since ID tokens tend to have longish expiry (several hours), are not revocable, and generally do not carry any concept of authorization (e.g. restricted scope).

It would have been better if instead of implementing ID tokens, OIDC only supported the authorization code flow and returned a JSON payload of claims (which nobody would incorrectly assume to be trustworthy).

see: aud/target

I prefer saml 2.0 for jit provisioning.

Reply on news.ycombinator.com