joepie91

One of the articles that TFA links to [0] contains the following paragraphs:

> And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecting a compromise. You also cannot invalidate old sessions when a user changes their password.

> You are essentially powerless, and cannot 'kill' a session without building complex (and stateful!) infrastructure to explicitly detect and reject them, defeating the entire point of using stateless JWT tokens to begin with.

I'm not sure that this is entirely true. Typically, the total number of non-expired issued tokens is much higher than the number of invalidated unexpired tokens. Therefore, if you store only invalidated tokens and delete them when they get expired, you can significantly reduce the amount of required storage and the cost of lookup.

Although, in any real application the performance gains will be minuscule (compared to the cost of, you know, everything else. Auth is just a small part) and probably not worth the extra complexity.

[0] "Stop using JWT for sessions" - http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

The ability to logout existing sessions (typically either via a manual user action or automatically upon changing/resetting their password) is a desirable feature in essentially all applications where user accounts can be compromised.

You can kind of fake this by using a short-lived JWT and constantly refreshing it, but this:

1. Massively increases server strain and bandwidth usage

2. Has problems with users less reliable connections (they'll be randomly logged out all the time)

3. Makes "Remember Me" style features impossible (unless you use a server-side store for that, which brings us back to it not being stateless)

Here's a good graph on why $method to make JWTs work for sessions is bad: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ (note: for some reason the website doesn't support HTTPS :( )

At this point I have yet to work on something that absolutely needs a NoSQL database so I may be a bit biased, but my general impression is they're a solution looking for a problem- or rather, the wrong solution to the wrong problem. I have used things like key-value stores such as memcached but it's also the kind of tools you don't use liberally unless you absolutely must. Perhaps a bit of obscurity isn't that bad of a thing after all.

Doesn't help that people have been talking about the issues with NoSQL for quite a few years now [0]

[0] http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/ (although I do wonder how much of these points still apply)

I've been fond of [1] and [2] for a more focused argument against JWT for sessions.

The JOSE standards (of which JWT is a member) are error-prone and have had numerous critical security-affecting bugs due to how they were designed. [3]

To remedy that, I proposed PASETO. [4]

I still don't recommend PASETO for sessions, because of the arguments laid out in [1] and [2].

[1] http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

[2] http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

[3] https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid

[4] https://paseto.io

A common security issue I've seen with uses of JWT doesn't have to do with JWT itself but how it's used by front-end developers. It's commonly stored in localStorage instead of an HttpOnly cookie, which creates a cross-site scripting vulnerability.

More details here: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

Shockingly, the advice I've seen to protect against this by folks like Auth0 is "keep your tokens expiration low" or not mention it at all.

I don't imagine PAST gets around this, as it's more like misinformation around the storage mechanism, but I think it's worth mentioning in any "how to use" section about PAST or JWT.

Rather than just "JWT is awesome..." wouldn't it be more sensible and responsible to caveat this with some of the drawbacks?

I read this article recently (http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/) that proposes not to use it for sessions but instead for the use cases listed at the end of the article. Follow-up article here http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

Also this https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/