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

21–30 of 101 posts

Re: JWT vs. Opaque Tokens

#21

Post by Aeolun »

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

PHP does this every single request. I’ve never had enough users that this became a significant issue (and you probably don’t either)

Re: JWT vs. Opaque Tokens

#22

Post by deepstack »

nkristoffersen wrote: post #6
rawoke083600 wrote: post #4

Whats the drawback for just including the ip in jwt and revoke if either time is up or ip change ?

I would imagine it would be a very poor user experience. Especially on mobile, where you jump around 4G/5G/WiFi networks and get a new IP address each time.

or if the user allows JS in their browser, then just do some GPU/CSS/Font Collections,etc. finger printing and get the unique id, since all the major bowser vendors are not fixing this problem (except may be for webkit).

Re: JWT vs. Opaque Tokens

#23

Post by mooreds »

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…

> having a blocklist of revoked JWT IDs in an in-memory cache (like Redis) can bring back some performance benefits.

Doing this obviates some of the benefits of JWT's statelessness, but for situations where revocation is really important and you can't have that few seconds of JWT validity after a user logs out, this totally works.

My employer has an article about this topic here: https://fusionauth.io/learn/expert-advice/tokens/revoking-jw...

Re: JWT vs. Opaque Tokens

#24

Post by Aeolun »

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

Re: JWT vs. Opaque Tokens

#25

Post by notimetorelax »

rawoke083600 wrote: post #4

Whats the drawback for just including the ip in jwt and revoke if either time is up or ip change ?

IP can change multiple times when switching between mobile stations and wifi hotspots. Plus IP may change for each new TCP request if your operator uses CGNAT

Re: JWT vs. Opaque Tokens

#26

Post by ffo »

mooreds wrote: post #19
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.

Exactly this! If you are hitting an authorization server via the introspect endpoint, why not simplify things even further and just hit dynamodb or redis or database and check the value of a cookie? A few reasons why you might want the opaque token come to mind: * You want the OAuth ecosystem (the libraries, the scopes, the user permissioning) * You are being forced to use an opaque token because your user authentica…

Or you want to share sessions across multiple domains.

This is where a identity service also can help ;-)

Re: JWT vs. Opaque Tokens

#28

Post by dkarl »

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.

Re: JWT vs. Opaque Tokens

#29

Post by xxs »

rawoke083600 wrote: post #4

Whats the drawback for just including the ip in jwt and revoke if either time is up or ip change ?

you can have multiple IPs at the same time.

The "IP changes" is a common fallacy - even the mobile IP depend on the datacenter(s) process it. There is no grantee there will be a designated aliasing, and effectively there could be multiple IPs for the same client interleaving.

Re: JWT vs. Opaque Tokens

#30

Post by nodefortytwo »

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…

Not all requests are created equally, maybe you don't check jwt revocation on some high throughput read endpoints but on updates or reading of sensitive data you do check that list.

with JWTs you have the flexibility with the opaque you don't.

JWTs also allow you to do client-side logic on things like entitlements but then verify against database when the user tries to view something

Post reply on HN