This is pretty standard for rolling signing keys and api auth methods and all kinds of stuff like that.
How do you tell RS256 and ES256 JWTs apart - so you can figure out how to validate them - unless the JWT actually encodes that information?
The trick is that JWT APIs need to force developers to choose which algorithms they want - having a `decode_jwt` function is not a good idea, `decode_es256_jwt` is much better. It'd validate that the alg in the header is correct, and return a specific error if it's not - if that error is returned, the developer can try `decode_rs256_jwt`.
This is how I've designed the API used in my OpenID Connect implementation. It works wonderfully.
Which still support webbrowsers that were released before 2007. (But somehow, they can’t support Firefox Mobile. mmhhmk. Totally not a plot to get rid of mobile ad blocking.)