| The general idea of the blog post is correct, but so many things are worded in slightly incorrect ways. I think this blog post needs a few edits. > JSON Web tokens (JWTs) for session handling instead of cookies. JWT and cookies aren't mutually exclusive, you can put a jwt in a cookie, unless it's too big.
There are two issues: Where do you store a sessions key, and how you create the session key.
The author correctly argues that the session key should be stored in a cookie, but doesn't make any arguments against JWTs, as far as I can tell. > This approach is insecure because essential flags like HTTPOnly are not supported. This wording is odd, because it's the other way around? It's not that HTTPOnly isn't supported when storing the session key in js, but that HTTPOnly enforces that you don't do it in js. > the logout function often merely overwrites the JWT on the client side, leaving user sessions valid until timeout. That's obviously bad, but there are also people who just set a different cookie, without making the previous session cookie invalid. Then the author goes on to explain a possible XSS attack, but fails to mention that in the example XSS would also be very bad without the vulnerable session key. The injected js could do something evil right away, without steeling the session key. (But yes, it's worse with the session key exposed) The author doesn't mention the relatively common flow of using refresh tokens together with short lived session keys. Overall, I think this article can be misleading. A confused beginner could read this article and misinterpret it to mean that protocols like OAuth or OpenID Connect are insecure, just because they use JWTs in some places. |
I hate to word it this way, but the problem is that JWTs are misused.
The reason I hate to word it this way because the natural step after “X is misused” is “X is prone to misuse”. Which is usually right. But the reason why JWTs are prone to misuse is partly because the underlying problem is hard (security, authentication, the web) and partly because some of the libraries which work with JWTs provide application developers some footguns.
Go ahead and use JWTs if you want, but spend some time understanding the underlying problem space. Authenticate the token before parsing it. Choose one specific signing algorithm—don’t allow tokens to be signed with any algorithm your JWT library supports.
And yes—simple session IDs, rather than JWTs, are often a good choice. But JWTs are fine too. The obvious reason to use JWTs is to speed up authentication in your front-end somewhat—if your front-end can authenticate a request by validating the JWT, and maybe checking it against a list of revoked tokens, then that means you can start processing the rest of the request without waiting for a network request for authentication.