The choice isn't "JWT" or "server-side sessions". It's client-side sessions versus server-side sessions, and JWT is just one (bad) option among many for client-side sessions.
'lvh and I are working on a piece about this for our clients, so I want to be careful not to write a crappy version of it in an HN comment first. But I think you'll find something close to a consensus on JWT/JWS/JWE/JWK among crypto engineers of our ilk.
I guess I'd close by saying: if you were writing a Rails app, it's almost certainly the case that you'd be better off just using ActiveSupport::MessageEncryptor to create an encrypted token than you would be building a shambolic equivalent of MessageEncryptor in JWT.
You didn't actually answer the why not JWT question there.
We're pretty heavily invested with using JWT wrapped inside OpenID Connect, and given you garner a lot of respect on such topics, I'd really be appreciate if you cited a source or gave us a reason. Anything would be better rather than just appealing to a vague consensus.
Why would my advice change because you're building something that uses JWT?
This thread, though, is about Go web applications. So I guess apropos this thread, I'd just say we probably don't need an example of how to use JWTs in Go. But session management, yes!
> Why would my advice change because you're building something that uses JWT?
I never said it would, I was simply stating my interest in your opinion on the topic. It seems a shame that you don't seem to be willing to expand though.
The equivalent of ActiveSupport::MessageEncryptor. Virtually every platform has something. Go has crypto/cipher.AEAD. Python has fernet. Most platforms have access to Nacl's "secretbox". All of these things are simpler, safer, and just as effective as JWT.
And even that presumes you want to actually encrypt data to the client: many (most) JWT users are just signing tokens, which makes an alternative to JWTs even simpler.
token = data:expiry:hmac(key, data+expiry) is super simple in most languages, is robust, and nacl provides useful helpers for doing this as well.
Nope. If there was, virtually every Rails app would be doomed.
There's a sort of intuitive insecurity quotient for things that goes something like C/W_s where C is complexity and W_s is the number of people in the world who would be screwed if something was totally broken.
Encrypted session cookies have, as a design, relatively modest C and very, very high W_s.
JWT has extraordinarily high C and, at present, modest W_s (relative to session cookies).
(They also have a bunch of design flaws that amplify their complexity).
Yep. I was brought on to a project where the JWT secret was a 6 letter band name. It's the hotness newness in the JS community and there's a lot of tutorials out there that show how easy it is to set up without explaining the risks/trade-offs.
'lvh and I are working on a piece about this for our clients, so I want to be careful not to write a crappy version of it in an HN comment first. But I think you'll find something close to a consensus on JWT/JWS/JWE/JWK among crypto engineers of our ilk.
I guess I'd close by saying: if you were writing a Rails app, it's almost certainly the case that you'd be better off just using ActiveSupport::MessageEncryptor to create an encrypted token than you would be building a shambolic equivalent of MessageEncryptor in JWT.