4 ms·

> …pattern we've often seen to mitigate some of the issues of JWTs is to store them serverside, in a session. … > The main reason why JWTs work so well is the

> …pattern we've often seen to mitigate some of the issues of JWTs is to store them serverside, in a session. … > The main reason why JWTs work so well is their statelessness. You realise this is obviously a very weak argument for using them? Stateless in a way that is apparently not useful for most people. Great. I’ve never seen a serious JWT implementation that didn’t use a database to manage lockout and other state related things that inevitably turn up as product requirements. Once you do, you now have a stupid pointlessly complicated session implementation that potentially leaks sensitive information. That’s the whole point of the article. If you you need jwt for “other services” issue jwts for them when they become a requirement.

mooreds 4y ago
> You realise this is obviously a very weak argument for using them? Stateless in a way that is apparently not useful for most people. Great. Well, it depends. With JWTs in a session, you get a time bound set of credentials that can be verified server side, with rotation built in and a lot of docs, libraries and experts thinking about things. (Regarding that last, there's a lot of brainpower put towards edge cases and security in the OAuth working group!) Other sets of users use JWTs in their pure stateless form, often with a short expiration time in a secure HTTPOnly cookie, transparently refreshing often. This offers easy horizontal scaling, as long as you only want to talk to servers in a single domain (you can always proxy calls other domains if needed). I don't think that JWTs are a magic bullet, but they definitely have some strengths.