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

71–80 of 101 posts

Re: JWT vs. Opaque Tokens

#71

Post by jimbobimbo »

Octoth0rpe wrote: post #67
dfee wrote: post #65

Earlier quoted context omitted.

> 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. JW…

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.

Re: JWT vs. Opaque Tokens

#72

Post by hbrn »

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 of the big reasons why it is so easy to work with them.

Re: JWT vs. Opaque Tokens

#73

Post by wokwokwok »

jwtbrothrow wrote: post #61
mooreds wrote: post #55

Earlier quoted context omitted.

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

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

Re: JWT vs. Opaque Tokens

#74

Post by jwtbrothrow »

wokwokwok wrote: post #73
jwtbrothrow wrote: post #61

Earlier quoted context omitted.

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

…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 as an old password.

I get that your snark is stylized, and this is Hacker News, and uniformly, the junior developers in my life that I engage with deploy snark, that's all fine. Really the emphasis is on how much the OIDC people have thought about all these things, and while I agree it is a lot to learn, it is in principle the only winning standard for authentication and authorization nowadays, it is what everyone uses, so you might as well learn it.

Re: JWT vs. Opaque Tokens

#75

Post by tobyjsullivan »

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…

It's worth noting this coconut pattern (hard auth facade, soft interior), while popular and helpful for dev efficiency, is a weak security practice. Using simple pre-shared keys between internal services excludes any meaningful access controls over user data. Whether that's important depends on the domain.

For stripe, though, I'm surprised they wouldn't want to ensure internal data requests are being made on behalf of customers who should actually have access to the data.

Also, for bigger companies (although, why not smaller ones?), you hit a point where you can't keep blindly trusting every service. Better to have internal security controls.

As for when these tradeoffs are appropriate, hard to say. But a good rule of thumb could be when the product is big enough to need an SOA.

Re: JWT vs. Opaque Tokens

#76

Post by mooreds »

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…

> In order to not have to care about rotating keys, a typical Resource Server would fetch the public key from the [authorization] server.

Another option would to be prepackage N public keys with the resource server during deployment. This means there is absolutely no network access required, just filesystem access to the public keys.

You want more than 1 so that you can rotate the signing keys if you need to, without redeploying said service.

What is the correct value for N? I dunno, depends, but it's not hard to generate 100 public/private keypairs and then bundle up the 100 public keys into a deployment artifact.

Is this as common as using JWKS? No, not in my experience. Is it possible? Absolutely.

Re: JWT vs. Opaque Tokens

#77

Post by hbrn »

tobyjsullivan wrote: post #75
hbrn wrote: post #72

Earlier quoted context omitted.

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…

It's worth noting this coconut pattern (hard auth facade, soft interior), while popular and helpful for dev efficiency, is a weak security practice. Using simple pre-shared keys between internal services excludes any meaningful access controls over user data. Whether that's important depends on the domain. For stripe, though, I'm surprised they wouldn't want to ensure internal data requests are being made on behalf o…

> 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.

Re: JWT vs. Opaque Tokens

#78

Post by schwap »

tobyjsullivan wrote: post #75
hbrn wrote: post #72

Earlier quoted context omitted.

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…

It's worth noting this coconut pattern (hard auth facade, soft interior), while popular and helpful for dev efficiency, is a weak security practice. Using simple pre-shared keys between internal services excludes any meaningful access controls over user data. Whether that's important depends on the domain. For stripe, though, I'm surprised they wouldn't want to ensure internal data requests are being made on behalf o…

Ironically, authorization downstream of an API gateway is an application that JWTs are a good candidate for.

Re: JWT vs. Opaque Tokens

#79

Post by marcosdumay »

hbrn wrote: post #77
tobyjsullivan wrote: post #75

Earlier quoted context omitted.

It's worth noting this coconut pattern (hard auth facade, soft interior), while popular and helpful for dev efficiency, is a weak security practice. Using simple pre-shared keys between internal services excludes any meaningful access controls over user data. Whether that's important depends on the domain. For stripe, though, I'm surprised they wouldn't want to ensure internal data requests are being made on behalf o…

> 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.

Re: JWT vs. Opaque Tokens

#80

Post by marcosdumay »

jimbobimbo wrote: post #71
Octoth0rpe wrote: post #67

Earlier quoted context omitted.

> 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. JW…

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, depending on what you read, you will get different meanings.

Post reply on HN