Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JWT vs. Opaque Tokens

zitadel.com

Post reply on HN
Print view View original

61–70 of 101 posts

Re: JWT vs. Opaque Tokens

#61

Post by jwtbrothrow »

mooreds wrote: post #55
giancarlostoro wrote: post #41

Earlier quoted context omitted.

> I agree with the premise of the article, which is that JWTs aren't the right answer for every solution. Ine pattern we've often seen to mitigate some of the issues of JWTs is to store them serverside, in a session. Now you get all the benefits of session management (revokability, single view of usage) but can still present a JWT to other APIs if needed. This seems weird to me. The whole point of the JWT is that you…

> 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 i…

> Regarding that last, there's a lot of brainpower put towards edge cases and security in the OAuth working group

This is obviously why people should adopt OIDC.

I don't really get the hate for OIDC. Nothing says "Junior Developer" like posting on Hacker News how shitty this widely adopted, durable technology is, especially by calling it "JWT."

This token expiration boogeyman is especially dumb. If there's a security misconfiguration so disastrous that the user can exploit it in less than 5 minutes (a typical access token lifetime), you're only going to be booting them out of the system after they've done the damage anyway.

Re: JWT vs. Opaque Tokens

#62

Post by FreakLegion »

Something that never comes up in these discussions is services with built-in JWT validation, like AWS API Gateway HTTP APIs. If you're already using one of these, you might as well take advantage of JWTs in addition to your scheme of choice, whether that's opaque tokens or something else. Let the service provider worry about unauthenticated people banging on your APIs.

You can even maintain statelessness with opaque tokens if you really need it, e.g. issue both a JWT and a session cookie bound together by some shared value, say Fernet tokens. One goes in the JWT in local storage (anti-CSRF), the other goes in an HttpOnly cookie (anti-XSS), requests still require both to decrypt to the same value after the service passes them through.

Generally this is overkill, though. JWTs for the service and your preference for the app works fine decoupled.

Re: JWT vs. Opaque Tokens

#63

Post by phamilton »

We moved from jwt to opaque tokens and it's been fantastic. We also moved from using redis as our token store to using postgres (aurora).

Querying against over 100M on postgres adds one or two millisecond p99 latency to all requests. That's perfectly fine. In fact, that's about the same performance we saw with Redis. Both were over the network, so I presume the network accounts for most of that delay.

Having them in an rdbms is so convenient. It makes customer facing feature like enumerating current sessions very simple. It makes token expiration and remote logout simple. It makes spotting weird bugs much easier.

I can't recommend it enough.

Re: JWT vs. Opaque Tokens

#64

Post by Octoth0rpe »

Lots of messy terminology use here. Example:

> In addition, since [opaque] tokens are stored on the server, they can carry more data than JWTs, and you can easily revoke them if necessary.

Opaque tokens don't carry _anything_. THey're just an identifier used to query a database inside your application. The article repeatedly implies there is meaningful content inside an opaque token.

More messiness:

> Opaque tokens cannot be read by people that hold them since they are undecodable strings. A client cannot read the contents of the token

Sure they can be read. It's just that the totality of the content _is_ the token itself.

Re: JWT vs. Opaque Tokens

#65

Post by dfee »

Octoth0rpe wrote: post #64

Lots of messy terminology use here. Example: > In addition, since [opaque] tokens are stored on the server, they can carry more data than JWTs, and you can easily revoke them if necessary. Opaque tokens don't carry _anything_. THey're just an identifier used to query a database inside your application. The article repeatedly implies there is meaningful content inside an opaque token. More messiness: > Opaque tokens c…

> Opaque tokens don't carry _anything_.

Opaque tokens are opaque to consumers. There’s no limit on what can be in there, as long as they’re opaque. So yeah, you don’t need that token to just be a PK. It can be a real payload (generally encoded).

Re: JWT vs. Opaque Tokens

#66

Post by xvinci »

gboone wrote: post #38
xvinci wrote: post #33

Unless I misread I consider this statement not true or contradictory: it has all the information the server needs except the signing keys, so the server doesn't need to store this information server-side. This means that users can get a token from your authorization server and use it in another without those servers needing to consult a central service. In order to not have to care about rotating keys, a typical Reso…

Maybe it's about "can get" vs "should be allowed to get"? They can carry whatever so it's technically true, right?

It was more about the

  and use it in another without those servers needing to consult a central service.
part. Unless you take care of key distribution yourself (like another poster wrote), this consultation of a central service has to take place to exchange key information (but not for additional authentication or authorization information).

Re: JWT vs. Opaque Tokens

#67

Post by Octoth0rpe »

dfee wrote: post #65
Octoth0rpe wrote: post #64

Lots of messy terminology use here. Example: > In addition, since [opaque] tokens are stored on the server, they can carry more data than JWTs, and you can easily revoke them if necessary. Opaque tokens don't carry _anything_. THey're just an identifier used to query a database inside your application. The article repeatedly implies there is meaningful content inside an opaque token. More messiness: > Opaque tokens c…

> Opaque tokens don't carry _anything_. Opaque tokens are opaque to consumers. There’s no limit on what can be in there, as long as they’re opaque. So yeah, you don’t need that token to just be a PK. It can be a real payload (generally encoded).

> Opaque tokens are opaque to consumers.

> It can be a real payload (generally encoded).

Based on your definitions, a JWT is therefore a specific kind of opaque token. I don't think it is personally.

I think we really should be talking about tokens as falling into two categories, of which JWT is an implementation of the first:

1) stateless - the token contains meaningful content that can be verified by a consumer. JWT is such an implementation with a standardized way of verifying the content without additional database queries (excepting revocation here)

2) pure identifiers - the token is merely an identifier, and all consumers must reach out to some other service (eg redis) to retrieve the details/capabilities that the session should have.

Edit: alternative proposed terms: content-full, content-less

Re: JWT vs. Opaque Tokens

#68

Post by [deleted] »

gboone wrote: post #36
dkarl wrote: post #28

Earlier quoted context omitted.

Where I've seen this turn into an argument is when people disagree about whether authorization info is "sensitive." Is it okay to send a list of roles or other authorization info in an unencrypted JWT? Security-wise this seems like it adds risk, but people often argue that it's a good trade-off in order to avoid a round-trip to an auth server (probably with a caching layer in front) for every call.

I figure unencrypted should be useful to the frontend, but use encrypted for authentication or authorization. Unencrypted: maybe a user preference, or first name, or something that adds value but does not overlap with auth. Like if a frontend could serve the same functionality across three departments but the styling is different, the token's unencrypted claims could determine which style set to use. Encrypted: user…

[deleted]

Re: JWT vs. Opaque Tokens

#69

Post by [deleted] »

goodpoint wrote: post #60
senko wrote: post #14

My biggest problem with JWT is that it's way overhyped, leading less experienced devs to believe JWT is the only way to implement auth, unless you use a 3rd party provider. JWT is a solution to a problem 95% of us don't have: https://apibakery.com/blog/tech/no-jwt/

Like most web stuff and the blockchain, JWT sound fancy but it is a very trivial thing.

[deleted]

Re: JWT vs. Opaque Tokens

#70

Post by dkarl »

gboone wrote: post #36
dkarl wrote: post #28

Earlier quoted context omitted.

Where I've seen this turn into an argument is when people disagree about whether authorization info is "sensitive." Is it okay to send a list of roles or other authorization info in an unencrypted JWT? Security-wise this seems like it adds risk, but people often argue that it's a good trade-off in order to avoid a round-trip to an auth server (probably with a caching layer in front) for every call.

I figure unencrypted should be useful to the frontend, but use encrypted for authentication or authorization. Unencrypted: maybe a user preference, or first name, or something that adds value but does not overlap with auth. Like if a frontend could serve the same functionality across three departments but the styling is different, the token's unencrypted claims could determine which style set to use. Encrypted: user…

The front end almost always needs to know what a user is authorized to do, because it is reflected in the UI. Which edit/delete buttons are visible and active? Is there a link to the admin page? Is there a link to a supervisor dashboard? Most apps send that information to the front end in a way that maps 1-to-1 to how they model authorization on the back end, often using exactly the same language, in which case you don't gain much by encrypting it in the JWT. But if you are taking measures not to leak your authorization model in the front end, then it makes sense not to expose it in an unencrypted JWT.
Post reply on HN