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

41–50 of 101 posts

Re: JWT vs. Opaque Tokens

#41

Post by giancarlostoro »

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…

> 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 know with confidence that the client has the data you need and cannot change it. I mean, if it works for them cool, but at that point you might as well just have a session with an ID and a table with all the relevant session information in one swoop.

Re: JWT vs. Opaque Tokens

#42

Post by magicalhippo »

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…

Indeed. We validate Azure AD tokens for our native application. Not all of our on-prem installations have unrestricted internet access. So we have a task that periodically checks and downloads Azure's signing keys[1], so we can distribute them to our customers.

[1]: https://login.microsoftonline.com/common/v2.0/.well-known/op... (jwks_uri element)

Re: JWT vs. Opaque Tokens

#43

Post by orange_joe »

I don’t have experience with JWTs, but if you can encode data, why couldn’t you encode a “freshness” time stamp and just invalidate the token after an elapsed time. Does this compromise the encryption?

Re: JWT vs. Opaque Tokens

#44

Post by hobofan »

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?

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 implementations/dev familiarity.

Re: JWT vs. Opaque Tokens

#45

Post by tgv »

ffo wrote: post #13
aaronmu wrote: post #11

What's the difference between an opaque token and a cookie that has a single session identifier in it? 'y know - the way we did it in the 90's.

The cookies is mainly used to identity the user (e.g. his session and prior authentication), while the tokens are used to forward something to proof that the an application wants to access one or multiple apis.

So if you need the client to pass on sensitive (authentication/authorization) information to another party without that party having access to the original provider of that data (except its public key, I suppose). Then JWT is a usable format, with a lot of support.

Re: JWT vs. Opaque Tokens

#46

Post by sibit »

orange_joe wrote: post #43

I don’t have experience with JWTs, but if you can encode data, why couldn’t you encode a “freshness” time stamp and just invalidate the token after an elapsed time. Does this compromise the encryption?

You can. Usually it's an "exp" value that you set when the token is issued. The time can be whatever you want, I might do something like now + 15 minutes. Then when verifying the token you can check if exp <= now kick out a 401 response.

Re: JWT vs. Opaque Tokens

#47

Post by mattacular »

orange_joe wrote: post #43

I don’t have experience with JWTs, but if you can encode data, why couldn’t you encode a “freshness” time stamp and just invalidate the token after an elapsed time. Does this compromise the encryption?

You can do that. A related problem: there is no obvious way to revoke early (ie. before the timestamp that was encoded when the token was issued). There are solutions but they require building extra mechanisms.

Re: JWT vs. Opaque Tokens

#48

Post by ffo »

tgv wrote: post #45
ffo wrote: post #13

Earlier quoted context omitted.

The cookies is mainly used to identity the user (e.g. his session and prior authentication), while the tokens are used to forward something to proof that the an application wants to access one or multiple apis.

So if you need the client to pass on sensitive (authentication/authorization) information to another party without that party having access to the original provider of that data (except its public key, I suppose). Then JWT is a usable format, with a lot of support.

Well, yes ;-)

Re: JWT vs. Opaque Tokens

#49

Post by mvf4z7 »

My biggest problem with using JWTs for authenticating a SPA is where do you store them so that a user does not have to login every time they visit your application? Every SPA tutorial I have seen says to throw them in the browser's localStorage. Well now you just opened yourself up to XSS vulnerabilities. Any code running on your page can access localStorage and make requests to ship the tokens anywhere they would like.

I prefer session cookies for web applications. Sure you have to worry about CSRF, but that is easily solved with CSRF tokens. Furthermore, is CSRF even really an issue when you are using a JSON API and have CORS properly configured.

Re: JWT vs. Opaque Tokens

#50

Post by philliphaydon »

franky47 wrote: post #3
pmontra wrote: post #2

I investigated this issue with a customer recently with a focus on revocation. We concluded that if we have to hit the database to check if a JWT token is still valid we can use a session cookie (or equivalent) and hit the database to get the user, the associated capabilities, etc.

Another drawback for JWTs (when used fully statelessly) is the inability to list active sessions on other devices (which may lead to revocation). That being said, always going to the database for connecting an opaque session token to an identity can quickly become slow, and if those features listed above are not desirable, having a blocklist of revoked JWT IDs in an in-memory cache (like Redis) can bring back some pe…

> always going to the database for connecting an opaque session token to an identity can quickly become slow

If select by id or token is slow for you then I worry about the rest of the application quality. Probably much slower elsewhere that the identity lookup is the least of your concern.

Post reply on HN