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

81–90 of 101 posts

Re: JWT vs. Opaque Tokens

#81

Post by marcosdumay »

ketzu wrote: post #16
ffo wrote: post #12

Earlier quoted context omitted.

Well you want to check your session cookies as well against something ;-) Surely you could trust a signature and lifetime but that makes the cookie no different than a JWT (only storage wise the differ in that case). Generally speaking it is recommended to use opaque tokens and rely on the userinfo / introspect endpoint call to make for the session management. Only in specific cases where latency and/or scaling might…

> Well you want to check your session cookies as well against something ;-) I think that is the point of the op: If you have to check a db to realize revocation, then you can use session cookies because they also need to hit the db. (Because you don't get rid of the db hit for using jwt).

Well, that certainly depends. One accesses the db on every request, the other accesses the db on every correct request (and the db is smaller).

As a rule, there is no difference. But if you are one of the exceptions, those can have differences of orders of magnitude.

Re: JWT vs. Opaque Tokens

#82

Post by fireflash38 »

goodpoint wrote: post #59
hobofan wrote: post #44

Earlier quoted context omitted.

That they've been around for long enough for proper implementations in all major languages to exist, their pitfalls being documented and a lot of devs have some familiarity with it. With that they are a better choice than most homebrew/framework-specific solutions. There are some other established (/"standardized") solutions, which might fit your use-case better though, but most of them lag behind JWT in implementati…

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

JSON really is the worst serialization, except for all the others.

Re: JWT vs. Opaque Tokens

#83

Post by hbrn »

marcosdumay wrote: post #79
hbrn wrote: post #77

Earlier quoted context omitted.

> As for when these tradeoffs are appropriate, hard to say And that is my biggest problem. If you don't know whether you need something, you don't need it. Or you just don't have enough expertise to understand why you need it, but that means you will implement it the wrong way anyway.

> If you don't know whether you need something, you don't need it. That's a bad approach for security. Starting with the solution is the wrong way to do it, but you certainly need to actively look if you have problems.

Let's say you're a startup that's hiring it's 5th engineer.

Should you do criminal background checks? Install spyware on laptops? Forbid hiring from other countries? Restrict developer access to production env? Invest all your development time into security features until you run out of those?

If you actively look for problems, you will justify all of those.

Security is not about knowing which problems exist and fixing them all. It's about knowing which risks are acceptable at your current stage. If you don't know which risks are acceptable, applying random security practices is worse than no security at all. At least when there's no security you are aware of it.

If you can't come up with an attack vector where HTTP Basic Auth causes significant problems, you don't need JWT to secure communication. And even if you can come up with an attack vector, is it really easiest one to execute?

Speaking of attack vectors, how many of the folks that use JWT for inter-service communication actually rotate encryption keys when anyone who has access to them leaves the company? My bet is very few.

Re: JWT vs. Opaque Tokens

#84

Post by zhte415 »

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 IP address, to a print out that has a user's UUID in the header. In all cases it ties data to an individual.

Better is to just use a high integer that doesn't simply increment, but changes by an amount. But low enough to blur into noise. Heck, this can be rotated.

I stand to be convinced otherwise, but via the reasoning above I believe UUIDs are not desirable for user privacy.

Re: JWT vs. Opaque Tokens

#85

Post by yencabulator »

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/

Worse than that, even when JWT is a solution to a problem you have, it's a bad solution.

https://web.archive.org/web/20180324054020/https://storify.c...

https://twitter.com/FiloSottile/status/1300946068411121665

https://insomniasec.com/blog/auth0-jwt-validation-bypass

https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

Re: JWT vs. Opaque Tokens

#86

Post by Sohcahtoa82 »

goodpoint wrote: post #59
hobofan wrote: post #44

Earlier quoted context omitted.

That they've been around for long enough for proper implementations in all major languages to exist, their pitfalls being documented and a lot of devs have some familiarity with it. With that they are a better choice than most homebrew/framework-specific solutions. There are some other established (/"standardized") solutions, which might fit your use-case better though, but most of them lag behind JWT in implementati…

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

What's wrong with JSON?

Re: JWT vs. Opaque Tokens

#87

Post by P5fRxh5kUvp2th »

marcosdumay wrote: post #79
hbrn wrote: post #77

Earlier quoted context omitted.

> As for when these tradeoffs are appropriate, hard to say And that is my biggest problem. If you don't know whether you need something, you don't need it. Or you just don't have enough expertise to understand why you need it, but that means you will implement it the wrong way anyway.

> If you don't know whether you need something, you don't need it. That's a bad approach for security. Starting with the solution is the wrong way to do it, but you certainly need to actively look if you have problems.

Why do security people think security trumps everything?

It's a serious question. As time goes on I more and more land on the side of Linus Torvalds wrt to security.

It kills me the amount of stupid shit I've seen done in the name of security.

If security people were to come up with driving standards, no one would be allowed to turn left because it's more dangerous then turning right.

Re: JWT vs. Opaque Tokens

#88

Post by P5fRxh5kUvp2th »

jwtbrothrow wrote: post #74
wokwokwok wrote: post #73

Earlier quoted context omitted.

…but how do you get the access token every 5 minutes? Surely not, because, it’s be obviously stupid using a refresh token right? Not a long lived refresh token. A refresh token… that you might, say, need to revoke at some point? Somehow. Definitely a boogeyman. …because people don’t understand how it works.

> Somehow. This word, revoke. It appears in OIDC exactly twice. You can look it up yourself. In order to get a new access token, you have to hit an authorization server URL, not an application server URL, with your refresh token. If it was revoked, you'll know then. The authorization server will simply not give you a new access token, and while you have a string of bits still called a refresh token, it is as useless…

I suspect cookie sessions is still more widely used than anything approaching OAuth and it's ilk. Hell, even JWT's often get associated with cookie sessions, which helps mitigate the revocation problem.

Re: JWT vs. Opaque Tokens

#89

Post by P5fRxh5kUvp2th »

marcosdumay wrote: post #80
jimbobimbo wrote: post #71

Earlier quoted context omitted.

Opaque token is called opaque for a reason - only the issuer knows what's in it, whether it has content or not, is it an identifier or an encrypted payload, what to do to make use of it. Content-full and content-less break that abstraction.

This is a hard area to work on, everybody that says something apply their own meanings to the words, you can never know what anybody else says. Anyway, I have always understood it as the token being opaque for the verifier too, that only ever tested it for equality. The token that is opaque only for the holder is normally called "encrypted". It may not be opaque to the issuer, but that doesn't change much. But anyway…

> Anyway, I have always understood it as the token being opaque for the verifier too

Which falls flat on its face the second you realize the "verifier" can pull out information based upon that opaque token.

It just means the intent is not for the person receiving it to do anything except reflect it back on subsequent requests. That's it. Typically it's done by handing something that is meaningless without context, said context not being available to the consumer being issued the token. But there is absolutely nothing that says you can't hand them a JWT meant to be used as an opaque token. If you're really worried about it, encrypt that bad boy before giving it to them.

Re: JWT vs. Opaque Tokens

#90

Post by feoren »

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 named differently". WTF?

Post reply on HN