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

31–40 of 101 posts

Re: JWT vs. Opaque Tokens

#31

Post by ehutch79 »

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.

And then most people hit the db anyways, since they use the jwt as a session cookie anyways.

Re: JWT vs. Opaque Tokens

#32

Post by kyrra »

It's funny to read about all the web app usage of JWT, and here I am dealing with it server side.

For those unaware, JWT has the 2 ways of encoding it: JWS and JWE. Because of these properties, you can use it how people would use it for application level messaging. If you are already on a secure channel, you can sign or encrypt the message so application level checks can happen.

This makes it act like a replacement of PGP for you paranoid people out there.

(Btw, I recommend against this, and think people should use PGP or Tink, as it's easy to footgun yourself with JWS.)

Re: JWT vs. Opaque Tokens

#33

Post by xvinci »

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 Resource Server would fetch the public key from the SSO server. Not necessarily in real-time, but at least on a frequent periodic basis. It even says "except the signing key", which is half true, since the public key needs to be well.. public and available.

Now this may be nitpicking but it comes with an important implication: Your jwt validating party needs to have network access to the SSO service (unless you want to provide keys for token verification yourself, which I do not recommend), which is not always a given, especially in hybrid setups (On-Prem + Cloud).

Re: JWT vs. Opaque Tokens

#34

Post by wokwokwok »

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…

> …pattern we've often seen to mitigate some of the issues of JWTs is to store them serverside, in a session.

…

> The main reason why JWTs work so well is their statelessness.

You realise this is obviously a very weak argument for using them? Stateless in a way that is apparently not useful for most people. Great.

I’ve never seen a serious JWT implementation that didn’t use a database to manage lockout and other state related things that inevitably turn up as product requirements.

Once you do, you now have a stupid pointlessly complicated session implementation that potentially leaks sensitive information.

That’s the whole point of the article.

If you you need jwt for “other services” issue jwts for them when they become a requirement.

Re: JWT vs. Opaque Tokens

#35

Post by 42e6e8c8-f7b8-4 »

b0afc375b5 wrote: post #27

Whenever I see jwt I always think of tptacek's arguments https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Thanks for the link. tpacek makes useful arguements.

I've come to like JWT's for mundane, tiny projects because I can use https://www.keycloak.org/ and get a lot of boilerplate account stuff for free -- password reset, registration page, eula gate, et c.

Re: JWT vs. Opaque Tokens

#36

Post by gboone »

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.

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 uuid, roles, maybe other known settings, things the backend can handle. Someone stealing a token will just try it anyway whether they can see claim or not, but because it's encrypted it will get decrypted so it's also a different logic flow than unencrypted and could trigger a process i.e. did it come from an accepted ip address or range? Does the ip match the previous? Does the ip match the other known ip for a websocket? So also in this sense we wouldn't want anyone to know what else we might check.

Re: JWT vs. Opaque Tokens

#37

Post by ffo »

42e6e8c8-f7b8-4 wrote: post #35
b0afc375b5 wrote: post #27

Whenever I see jwt I always think of tptacek's arguments https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Thanks for the link. tpacek makes useful arguements. I've come to like JWT's for mundane, tiny projects because I can use https://www.keycloak.org/ and get a lot of boilerplate account stuff for free -- password reset, registration page, eula gate, et c.

Well you can have the turnkey of keycloak and JWT optional with ZITADEL ;-)

Re: JWT vs. Opaque Tokens

#38

Post by gboone »

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?

Re: JWT vs. Opaque Tokens

#39

Post by ffo »

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…

Well true, public keys would be better wording wise.

One thing I just wanted to append to this here:

> Not necessarily in real-time, but at least on a frequent periodic basis.

Periodically fetching the keys is not really a best practice on its own. The consumer (RP) must be able to handle newly published keys at runtime. Since a JWT includes a KID it is recommended to lookup a local cache pre-filled from a scheduler while fetching new KIDs on demand.

Re: JWT vs. Opaque Tokens

#40

Post by jrochkind1 »

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?
Post reply on HN