4 ms·
Why not create a column in the user table named `jwt_id` which you store a random hex that is added to the JWT payload. To logout the token just invalidate or
by syspec 6y ago
Why not create a column in the user table named `jwt_id` which you store a random hex that is added to the JWT payload.
To logout the token just invalidate or change the `jwt_id`
- domano 6y agowell then we are back in the database, so basically it is a session again.
- e12e 6y agoRight. I've yet to see any combination of easy/sane setup for jwt (beyond the fact that it's somewhat standard, although less standard than basic auth). You might set the jwt to expire in 15 minutes, for a 5-10 minute session allowing for clock drift - and just eschew the black list. But now you need a longer lived "refresh token" and a service endpoint that handles that, along with a black list. It is "simpler" in the sense that: your app have two separate auth/clients - one is very simple - gets a jwt token and renews every ten minutes - the rest of your app simply uses the jwt. On your server side, you can have a dedicated/simple service that only renews jwts given a refresh token (checks refresh token blacklist) - and your other apps blindly trusts the jwt (checks signature and the short timestamp). You've now reimplented half of kerberos - along with "pass the hash" - and at least you can reason about the trade-offs you've made...
- keybits 6y agohttps://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-...
- domano 6y agoI agree with the points made, but want to make a case for JWTs for all service landscapes based on message queues, kafka or asynchronous communication. There the statelessness really shines.