3 ms·

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 sa

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

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.