This is exactly the solution I use. I use a secret server (Vault, using Consul as a backend) to securely distribute and manage the encryption keys.

And if you want to be able to authenticate users to a service that you do not want to send private keys to?

Then sign / encrypt the token with a private key and distribute a public key to the untrusted peers. Since you're just using bog-standard cryptography primitives you can change them at will to match your use case. Need to handle untrusted peers? Asymmetric keys are the answer.

Or, you use the asymmetric key/pair to sign the JWT, and lock your environment to only public keys signed by your DC's cert in your org. If only that was supported by JWT.. oh, that's right, it is.

Nobody has to implement the FULL spec, you only need to allow what your environment needs.

I'm not really sure what your point is, other than an apparently fervent desire to prove JWT's worth while speaking down to me. I didn't say that JWT couldn't do that... You're the one who set up the strawman of untrusted parties, then gleefully knock it down after I address the issue. You have contributed no other valid feedback to my proposal, just a defense of JWT which is not an answer to anything I ever stated.

I just want you to know that such tactics are not very appreciated from this side of the conversation.

What does JWT provide that using bog-standard crypto primitives in the way I described doesn't? Other than a name and a standard?

You do understand that this is fundamentally the exact underlying mechanic of JWT?

You call it the underlying mechanic. I call it the only necessary mechanic. If those additional mechanics are where the security issues come from, then just get rid of them.

No one is forcing you to accept/implement ALL possible aspects of JWT.. in fact, that's generally a bad idea... Only need to implement what you need. If a specific algorithm is bad, don't allow it...

Isn't this how HTTPS works, HTTPS today doesn't use the same SSL and algorithms allowed in 1996, it's evolved and changed in practice. The author isn't suggesting everyone just not use HTTPS because some possible algorithm has been determined to be weak is he?

> No one is forcing you to accept/implement ALL possible aspects of JWT.. in fact, that's generally a bad idea...

I think this is a very interesting, because it's basically validating the article's argument. People are going to feel safe implementing JWT because it's an RFC, without knowing where these "generally bad idea" landmines are. That's the dangerous part.

And yes, the same issues exist in SSL / TLS. And guess what? There's loads of articles just like this one stating how dangerous older modes of these protocols are. Articles like this and the discussions they spawn are exactly the kind of thing necessary to move the world forward into safer implementations.