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.
JWT vs. Opaque Tokens
11–20 of 101 posts
Re: JWT vs. Opaque Tokens
#12I 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.
Well you want to check your session cookies as well against something ;-)
Surely you could trust a signature and lifetime but that makes the cookie no different than a JWT (only storage wise the differ in that case).
Generally speaking it is recommended to use opaque tokens and rely on the userinfo / introspect endpoint call to make for the session management.
Only in specific cases where latency and/or scaling might become an issue you should opt for JWT. At least this is my opinion.
Re: JWT vs. Opaque Tokens
#13What'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.
Re: JWT vs. Opaque Tokens
#14My 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/
Re: JWT vs. Opaque Tokens
#15What'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.
There isn't one - the session identifier is an example of an opaque token
Re: JWT vs. Opaque Tokens
#16I 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.
Well you want to check your session cookies as well against something ;-) Surely you could trust a signature and lifetime but that makes the cookie no different than a JWT (only storage wise the differ in that case). Generally speaking it is recommended to use opaque tokens and rely on the userinfo / introspect endpoint call to make for the session management. Only in specific cases where latency and/or scaling might…
> Well you want to check your session cookies as well against something ;-)
I think that is the point of the op: If you have to check a db to realize revocation, then you can use session cookies because they also need to hit the db. (Because you don't get rid of the db hit for using jwt).
Re: JWT vs. Opaque Tokens
#17What'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.
Cookie is a mechanism to store and send tokens to the server, which is orthogonal to what the token is.
You could store JWT in a cookie, or use opaque token in a HTTP header, for example.
That said, the session cookies we loved back in the day were usually opaque tokens, yeah.
Re: JWT vs. Opaque Tokens
#18Full 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 of usage) but can still present a JWT to other APIs if needed.
I'd never put sensitive data in a signed JWT. In fact, at FusionAuth, even JWT claims like the user id is a UUID, just so you don't inadvertently leak information like "how many users are there" via an integer user id.
The main reason why JWTs work so well is their statelessness. By that I mean the fact that you can verify their integrity without "calling home" (especially if you've set up asymmetric keys correctly). In this case, you don't have the same availability and scaling requirements for your server that issues JWTs that you would for a server that was responding to opaque token requests.
It's from last year, but I compare and contrast these two approaches in this video I presented at a meetup, starting a few minutes in: https://youtu.be/rArCF7nUcvY?t=451
JWTs are part of building an app that scales. But like any other scaling choice, it has consequences. Just as you wouldn't shard a database before you need to, you shouldn't build an app that uses JWTs to scale unless you need to. Though switching between sessions and JWTs is going to be an easier transition than sharding vs unsharding a database. Data has inertia and all that.
I don't believe there is much functional difference between sessions and opaque tokens. Both have to be stored somewhere, both require a central source of truth, both require that store of truth to be constantly available. There are differences in how they are managed/acquired, but from an architectural perspective they are similar.
Re: JWT vs. Opaque Tokens
#19I 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 authenticates somewhere else, and they only provide you an opaque token.
Re: JWT vs. Opaque Tokens
#20What'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.
For a normal web app, not too much.
As sibling comments point out, an opaque token can be stored elsewhere (though, to be fair, the session identifier which is in that cookie can be placed elsewhere too).
Cookies are limited in where they can be sent (https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...).