How to verify that a JWT was in fact generated by the claimed issuer (iss)?

Question

JSON Web Tokens (JWTs) (RFC, introduction) are digitally signed using a secret key (which can be symmetric, but for distributed use cases will typically be asymmetric). The signature forms the third and final part of the JWT, and can be verified from the JWT recipient side using the same secret key (for symmetric signing), or the private key's corresponding public key (for asymmetric signing). This allows the JWT recipient to verify the integrity of the JWT, i.e. that it has not been tampered with by some third party.

Further recommended validation mechanisms include verifying that the token has not yet been expired, that the recipient is the intended audience, etc.

For asymmetric signatures, the public key might be transmitted embedded as part of the JWT itself (jwk or x5c claim), or a URL to the public key might be provided (jku or x5u claim). There may be further public key transmission mechanisms of which I am not aware.

However, how can the JWT recipient verify that the JWT was in fact actually generated by the issuer that it claims (iss claim) to be generated by? What prevents any arbitrary malicious actor from generating a JWT with their own private key, masquerading in the iss claim as an issuer they do not actually represent, and passing in the JWT itself the public key (or a link to it) for verifying the signature. In such a scenario, the recipient would be able to know that the JWT wasn't tampered with, but they wouldn't know that the issuer was false, and that the content therefore could not be trusted.

As far as I've been able to gather, the best practice in when using asymmetric JWT signing is for the JWT recipient to explicitly whitelist specific public keys or public key URLs/domains. This would allow the recipient to know for sure whether the JWT was generated by the purported issuer, assuming that the recipient can be confident in which domains or public keys the issuer actually owns.

Does verification of issuer always rely on manual whitelisting such as this by each and every recipient, or are there other mechanisms by which the recipient can verify with certainty whether the JWT was indeed generated by the issuer it claims to be, without the same level of manual effort.

I've found little information about this conundrum online, and the original JWT RFC itself also does not seem to touch upon it, from what I can see.

Answer 1

From the JWT RFC:

The contents of a JWT cannot be relied upon in a trust decision unless its contents have been cryptographically secured and bound to the context necessary for the trust decision. In particular, the key(s) used to sign and/or encrypt the JWT will typically need to verifiably be under the control of the party identified as the issuer of the JWT.

This part of the text shows that the trust management is deliberately left outside of the RFC. That makes the standard very flexible: it can be used by any authorization framework. It's best to see it as a building block.

Tokens are however generally signed and verified by the parties that have a trust relationship. The party that operates the authorization endpoint issues tokens to the client, and the token is verified by the service that requires the authorization for the client.

There are multiple authorization frameworks that are able to use JSON web tokens, such as OpenID connect and Auth0. For instance, in Auth0 the public keys are distributed using JSON web keysets, which is defined in a separate RFC. Note that this leaves something to be desired when it comes to key management (expiration, revocation or polling rate of list), which I would then consider implementation specific.

Similarly, the way that the tokens may or should be used may depend on the framework.