Critical Vulnerabilities in JSON Web Token Libraries

I appreciate the distinction you're making, but in my opinion security and reliability are one and the same when you're discussing authentication methods. The lack of security would render your system unreliable (as you can't ever be certain the credentials are valid); and an unreliable software stack would be detrimental to the security of the authentication (bugs are, after all, often security issues).

> They will be more reliable, as you don't need to talk to e.g. MySQL that might be down or slow. This disadvantage is that they're difficult to revoke.

I'm all for building fault tolerant systems, but the database being available is the bare minimum you'd normally need for a web / cloud / whatever service to operate. Even authentication aside, I'm not really sure what good the service would be with the database offline (so you can log in, but can you now post comments in the community portal, or use the CMS, or book manufacturing jobs, etc. And what about any required form of audit logging?). So I don't really understand why you would need login process to be tolerant to that specific failure.

Your database performance point is an interesting one though. Personally I'd approach that by having the session table mirrored on a high performance key-value store to reduce the load on your RDBMS (to use your MySQL example). But then that solution quickly runs into additional security, reliability and complexity issues; much like using JWTs. So I'm definitely not trying to say my approach to the same problem is any better.

What I did find the most interesting about this JSON web token approach was a comment made by sandstrom (https://news.ycombinator.com/item?id=9302304) where he discussed the decentralised / portability possibilities of such an authentication model. This isn't something I've ever needed to consider in my line of work, but it seems a very useful method of linking different platforms in a clean way, and without them necessarily having direct access to each other.

Anyway, I don't want to sound like I'm dismissing your points. It's a very interesting solution on a common problem. Sometimes I need help to understand the process and the best way to do that is to question it so any ignorance (on my part) is counter argued and thus corrected :)

[1] https://github.com/liquidz/clj-jwt/issues/8

They are signed with a private key (e.g. a secret random 32-bytes kept by the server) when they are issued. Revocation is typically based on an expiration time, hence the timestamp in the header.

The JWT libraries in this case failed their basic premise, that is, to verifying the signature. An unsigned token which contains trusted data is just an open door for the user to claim whatever they want.

The centralized session model is easier to reason about, but has many pitfalls. Now all your servers need to be able to contact that centralized state in order to service even a basic request. HMAC is very fast, much faster than pulling central state from a network service. If you're asking a client to maintain a session token, might as well ask them to maintain the session state itself if it's small enough to fit in a cookie.

I would guess the reason for any downvote is the question you're asking is directly addressed by TFA, so it strongly implies you didn't bother to read it.

The client can send something wrong? Yes, as long as the client can digital sign what is sending with the secret you expect.

JWTs can be signed with a symmetric key or an asymmetric key, the vulnerability mentioned in this post is when the server-side expect a token digitally signed with an asymmetric key but an unauthorized client uses the public key to create a signature as if the key where symmetric. The issue in this case is when the server is blindly accepting any algorithm.

[1]: http://security.stackexchange.com/a/20301/9332