JWT vs. Opaque Tokens
zitadel.com
JWT vs. Opaque Tokens
1–10 of 101 posts
Re: JWT vs. Opaque Tokens
#2I 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.
Re: JWT vs. Opaque Tokens
#3I 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 performance benefits.
Re: JWT vs. Opaque Tokens
#4Whats the drawback for just including the ip in jwt and revoke if either time is up or ip change ?
Re: JWT vs. Opaque Tokens
#5I 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.
Than you don't need it if you don't see the advantage.
You normally do lots of API requests while you are logged in. To services and to download an image for example.
You make sure the current jwt is valid for a few minutes and hit only the database with the refresh token for example.
Only in worst case you really need to block a token and it might be much easier to sync those few tokens in your system into some local cache and let them expire automatically (because you know when they expire as it is contained in the token).
But yes if all of this sounds complicated, use sessions and a distributed redis for your session or just the database.
Re: JWT vs. Opaque Tokens
#6Whats 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.
Re: JWT vs. Opaque Tokens
#7I 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…
You still can add a post response filter to update some statistics table after you send out the response to the customer to keep latency low and pressure on db low too.
Still very few companies need something like this.
Re: JWT vs. Opaque Tokens
#8Whats the drawback for just including the ip in jwt and revoke if either time is up or ip change ?
The IP can change, is not guaranteed unique (many people can be behind 1 IP).
Imagine unstable mobile connections going over 4/5g or random wifi as you move.
Re: JWT vs. Opaque Tokens
#9Whats the drawback for just including the ip in jwt and revoke if either time is up or ip change ?
Best things would be webauthn were you have crypto hardware like your smartphone
Re: JWT vs. Opaque Tokens
#10An ex-colleague loved JWTs, using them in systems where I'd argued strongly they were inappropriate, and since I wasn't able to cut holes in the resulting system in a few hours spare time spent tinkering and they really wanted to do it, it went ahead. I guess I at least know they didn't fuck up in any of the obvious ways because I checked those.
Recommended thought experiment: Every programmer who makes or consumes the tokens in your system needs to attend a meeting about the tokens. Picture that meeting in your head. Was it a huge endeavour, involving several hotels and many months of planning? Then you probably need JWTs. If the meeting could happen in a coffee break then JWTs are wildly inappropriate.