'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.
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.
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!
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.
What you recommend then instead of JWT in a non-Rails environment?
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.
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).
That's why this Category #2 stuff is so important. People can agree without much controversy what "best practice" is for the Category #1 stuff, but at the next level it's just blog posts and discussion thread comments passionately arguing opposite statements.
I'm curious... if not JWT, then how would you approach the problem of authenticated sessions without server-side state? (assuming you aren't rejecting the overall premise entirely)
If you track authentication with a server-side session, then you have to either:
(1) Setup a backing store for your session state (e.g. Redis, relational database, proprietary app server solution, etc). Share the backing store across all instance nodes in your server-side cluster. Tune the inevitable performance issues and point-of-failure risks, and expect the worst if you're using a proprietary thing (they're all terrible).
(2) Use a hardware solution. Have the load balancer always route a given client's requests to the same server-side instance. Deal with failover scenarios when that instance goes down, have to drain traffic every time you want to do a deployment, etc.
JWT's ugly, but no uglier than either of those! Always on the lookout for other recipes...