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

91–100 of 101 posts

Re: JWT vs. Opaque Tokens

#91

Post by dwaite »

hbrn wrote: post #72
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/

To add to that, even if you have microservices everywhere on the backend, JWT is still rarely a good choice. Those services are typically exposed to customers via some sort of API Gateway/BFF. So if your clients don't speak to microservices directly, authentication between those services could easily be done via plain old HTTP Basic Auth. Stripe has been doing that for their public API since forever, and that's one o…

You have different approaches of security depending on your desire for risk mitigation. Examples (with somewhat made-up names);

1. An ingress moat - your ingress makes decisions on whether someone should be allowed in, after which internally anything goes.

2. Two-stage auth - building on top of the above, internal messages need authentication/authorization for communication channels to be established. This might be basic, x509, kerberos, or federation-based protocols. Microservices environments might use SPIFFE for this.

3. Messenger auth - in addition to the above, requests need to show evidence of direct/indirect interaction with the parties involved. For example, an access JWT may be sent around since it would provide indication of a user and tenant.

4. Intermediary-authorization - a variation of the above, evidence is required on each communication channel 'hop' that the initiator(s) are authorized to make the request against a service. This may involve more centralized services to create many opaque/integrity-protected authorization decisions from an external systems view.

5. Transactional auth - another variation of 3, evidence is required specifically that a given action is authorized, including parties and potentially parameters. This might be sent directly from the original initiating party, or may be created for internal systems close to the ingress point.

Note that for a service with a public API, all of these can hypothetically look identical. However, once you get to a certain amount of internal authorization checks, you naturally start to try to represent those with integrity-protected stateless tokens to avoid needing a massive centralized system with low latency consistency and high uptime needs. OAuth access and refresh tokens were designed to help there.

Re: JWT vs. Opaque Tokens

#92

Post by adamckay »

zhte415 wrote: post #84
mooreds wrote: post #18

Full disclosure, I work for FusionAuth, a competitor of Zitadel in the auth server market. Our software issues a lot of JWTs. 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 o…

UUIDs leak information, by definition. For that reason, I'm not a fan. It's just leaking on the other side. I'll explain: A UUID should be pretty unique in the universe. Wherever it crops up, as there should always be an assumption of the possibility of leaking data and associated data at the same time, whomever the UUID belongs to has had their information leaked. That could be associated meta data in a request like…

I don't understand what you mean here.

You're saying that because UUIDs can be assumed to be unique in the universe, when it's leaked alongside other data it can then be correlated with other data leaks to tie data to an individual? How does a user ID being `8646846` make it any safer from leaks or correlation than `123e4567-e89b-12d3-a456-426614174000`?

Re: JWT vs. Opaque Tokens

#93

Post by jsmith45 »

feoren wrote: post #90
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/

> This brings us back to how we implement authentication in Node projects you generate with API Bakery. If you've read all of the above, no surprise here - we use bearer tokens. WTF? They just spent the whole article talking about how bearer tokens were stupid (everything they said about JWT applies to all bearer tokens). And then they say "instead of this thing we said was stupid, we use the exact same thing but nam…

Nonsense. Issues like inability to revoke JWTs don't apply to bearer tokens where the API server needs to query the token issuer to found out who the user is (which can then implment revoking the token simply by dropping the record for the token from the DB, all further calls will fail the lookup!)

Remember they stated:

> Major advantage of JWT compared to bearer tokens [...] is that they don't require looking up the token.

Other problems with JWTs vs opaque bearer tokens they listed include:

- increased attack surface due to complexity of JSON parsing/validation

- misconfiguring JWT libraries to allow no signature

- leaking data to users because you thought JWTs were encrypted

Now you are right that some of the complexities involved with JWTs like refresh token can apply with arbitrary bearer tokens, especially if you want to limit the lifespan of the access token, but those are implementation choices. Technically you can just have a single long lived bearer token instead of a long lived refresh token, and a short lived access token.

Re: JWT vs. Opaque Tokens

#94

Post by Aeolun »

jrochkind1 wrote: post #40
Aeolun wrote: post #24

I feel people come down too hard on JWT. If you do just two things there’s basically no difference between sessions and tokens. Don’t use it for storing sensitive data Expire often

If there is no difference, then what is the advantage of JWT?

Mostly the fact you can check their validity without going to the database.

If you have one you can keep using it without extra network roundtrips as long as it doesn’t expire.

Only the validity of refresh tokens (for generating new access tokens) is checked.

Re: JWT vs. Opaque Tokens

#96

Post by Aeolun »

dkarl wrote: post #28
Aeolun wrote: post #24

I feel people come down too hard on JWT. If you do just two things there’s basically no difference between sessions and tokens. Don’t use it for storing sensitive data Expire often

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.

Say you steal the token, what are you going to do with it? You could argue that you can now iterate all the tokens you steal, decode all of them, and find the ones with admin permissions. But if you have a frontend that wishes to know user permissions/access, you already have an endpoint for that too, so they can call that with all the tokens instead.

The thing is that you cannot change the payload of the token without invalidating it, so you couldn’t set the role to admin and then still have the server accept it.

Re: JWT vs. Opaque Tokens

#97

Post by Aeolun »

dkarl wrote: post #70
gboone wrote: post #36

Earlier quoted context omitted.

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

> But if you are taking measures not to leak your authorization model in the front end

How would you do that? At the end of the day the front-end needs to know what you can access somehow.

I guess you could add a compile step that rewrites all your permission checks into validating opaque uuid’s.

Re: JWT vs. Opaque Tokens

#98

Post by feoren »

jsmith45 wrote: post #93
feoren wrote: post #90

Earlier quoted context omitted.

> This brings us back to how we implement authentication in Node projects you generate with API Bakery. If you've read all of the above, no surprise here - we use bearer tokens. WTF? They just spent the whole article talking about how bearer tokens were stupid (everything they said about JWT applies to all bearer tokens). And then they say "instead of this thing we said was stupid, we use the exact same thing but nam…

Nonsense. Issues like inability to revoke JWTs don't apply to bearer tokens where the API server needs to query the token issuer to found out who the user is (which can then implment revoking the token simply by dropping the record for the token from the DB, all further calls will fail the lookup!) Remember they stated: > Major advantage of JWT compared to bearer tokens [...] is that they don't require looking up the…

Hold on, this is backward. They said:

> You should not use Thing X because the advantage it has over Thing Y is not an advantage. In fact both Thing X and Thing Y have the same disadvantage. Except that Thing X has a workaround and Thing Y doesn't. But that workaround adds (gasp!) complexity! Obviously, we only ever use Thing Y and you're a bad developer if you use Thing X.

It's smoke and mirrors. They never give an advantage of bearer tokens over, well, JWT barer tokens, which are a type of bearer token, the thing they said they use. They just said JWTs don't actually have one specific advantage, except when they do. That's not an argument against JWTs!

> increased attack surface due to complexity of JSON parsing/validation

People who use JWTs are already parsing JSON everywhere. It's not hard. If it's not valid JSON, clearly you don't authenticate.

> misconfiguring JWT libraries to allow no signature

You can misconfigure anything. You can misconfigure your server to not actually check the bearer token. Why is it more likely you'll forget to check the JWT signature than the bearer token? This is something you write one time and never touch; it takes an afternoon at most.

> leaking data to users because you thought JWTs were encrypted

Yes, you should not put sensitive data in a JWT, encrypted or not. This is a fair criticism.

> Technically you can just have a single long lived bearer token instead of a long lived refresh token, and a short lived access token.

Which, as they pointed out in that article, is a disadvantage of long-lived bearer tokens.

Re: JWT vs. Opaque Tokens

#99

Post by dkarl »

Aeolun wrote: post #96
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.

Say you steal the token, what are you going to do with it? You could argue that you can now iterate all the tokens you steal, decode all of them, and find the ones with admin permissions. But if you have a frontend that wishes to know user permissions/access, you already have an endpoint for that too, so they can call that with all the tokens instead. The thing is that you cannot change the payload of the token witho…

There's no concrete exploit that it enables, but in principle it's always a risk to leak information about your security implementation. My opinion is that it's a very low risk for almost everybody, worth trading away for extra reliability and scalability if you need it.

To answer the question in your other comment, the back end can, in principle, provide a boolean yes/no value for every authorization-related decision the front end needs to make: can_change_order_status, can_view_supervisor_dashboard, can_view_all_conversations, etc. That way you never leak the model (such as roles) underlying those decisions. In practice, I've never seen anybody bother. Instead they have the back end send the front end values that map 1:1 to the back end authorization model: is_supervisor, is_account_admin, etc. That's why I think for most applications it doesn't matter if users roles are encrypted in the JWT.

Re: JWT vs. Opaque Tokens

#100

Post by goodpoint »

Sohcahtoa82 wrote: post #86
goodpoint wrote: post #59

Earlier quoted context omitted.

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

What's wrong with JSON?

It requires a complex scanner with a stack to track nested data structures.

Not good for security nor speed in the use-case of a auth token!

Post reply on HN