4 ms·

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

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.

franky47 4y ago
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.
- Awerion 4y ago
  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.
- Aeolun 4y ago
  > 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)
- mooreds 4y ago
  > 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-jwts https://fusionauth.io/learn/expert-advice/tokens/revoking-jw...
- nodefortytwo 4y ago
  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
- philliphaydon 4y ago
  > 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.
Awerion 4y ago
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.
ffo 4y ago
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.
- ketzu 4y ago
  > 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).
  - marcosdumay 4y ago
    Well, that certainly depends. One accesses the db on every request, the other accesses the db on every correct request (and the db is smaller). As a rule, there is no difference. But if you are one of the exceptions, those can have differences of orders of magnitude.
mooreds 4y ago
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.
- ffo 4y ago
  Or you want to share sessions across multiple domains. This is where a identity service also can help ;-)

franky47 4y ago

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.

Awerion 4y ago
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.
Aeolun 4y ago
> 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)
mooreds 4y ago
> 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-jwts https://fusionauth.io/learn/expert-advice/tokens/revoking-jw...
nodefortytwo 4y ago
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
philliphaydon 4y ago
> 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.

Awerion 4y ago

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.

ffo 4y ago

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.

ketzu 4y ago
> 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).
- marcosdumay 4y ago
  Well, that certainly depends. One accesses the db on every request, the other accesses the db on every correct request (and the db is smaller). As a rule, there is no difference. But if you are one of the exceptions, those can have differences of orders of magnitude.

mooreds 4y ago

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.

ffo 4y ago
Or you want to share sessions across multiple domains. This is where a identity service also can help ;-)