Don't trust the data before you verified it is indeed the common problem here. You have to be careful with JWK in a similar way: the public key can be specified a as a URL via the x5u parameter, you have to make sure you only trust keys from a whitelisted URL otherwise whoever supplies the token signed with a JWK can just provide their own public key and self-sign it.

This can be problematic and need some leg-work on a developer's side when the URLs to be whitelisted aren't documented. For example Apple use a similar signed blob to allow 3rd parties to verify a Game Center identity, using generateIdentityVerificationSignatureWithCompletionHandler. The data you get back includes the publicKeyUrl, but not which URLs to expect. A naive implementation would just download the public key and run with it. Bad for two reasons: you're now downloading data from an arbitrary location and you are trusting a signature that you verified using untrusted information. In case anyone is interested, the two locations I've seen Apple provide here are https://sandbox.gc.apple.com and https://static.gc.apple.com .

That's a great link (which I've seen before) and I upvoted it.

But these "typical JWT lib api vulns" are WAY SIMPLER than Vaudenay etc. Any programmer could do this in minutes or less. WOW. It's so obvious and straightforward (in hindsight I suppose). My mouth is still hanging open.

We've recently been looking at adding JWT, and one of the things I looked out for was that we were protected against downgrade attacks. This was done both as a check of the current library code, and an explicit check on our side that the alg is what we expect to protect against future library changes.