What is the point of signing a JWT with a JWK if you need to communicate with the token issuer?

Question

If I understand correctly, a JSON Web Token (JWT) can be asymmetrically signed with a special private key (JWK). At least in some common configurations, the public part of the signing key can't be obtained via classic x.509 certificates, but rather by accessing some trusted API endpoint, fetching the public key, and using that to verify the JWT signature.

How is that any better than just sending the entire token over to the trusted API and asking it to validate it? I thought that the whole point of using tokens was that they can be verified without contacting the token issuer, just by checking its signature with a widely available public key.

EDIT: Also, like I commented on @bk2204's answer, even if you cache the JWK, every time you need to refresh the JWK, you need to use the x.509 key to make an HTTPS request to the JWK server. And if the x.509 certificate is expired or revoked, then one should also revoke the JWKs. Seems to me that if the x.509 key can be used for every single HTTPS request that the JWK server gets, then surely it should be good enough to sign the tokens directly.

Answer 1

The benefit of using some sort of public key for verification is that the verification can be done offline. For example, say I ask service XYZ to validate a user and, if authorized, provide a JWT. I can query service XYZ to provide me their long-term signing key once, and validate the JWTs that have been issued. As long as they continue to use the same signing key, I can validate the JWTs, even if service XYZ goes down or is otherwise unavailable.

There is, of course, a tradeoff here. You want to rotate keys every so often to limit the risk of compromise, but you also don't want to fetch the key all the time, so there needs to be a balance.

Note that a X.509 certificate isn't necessarily ideal for verifying things that don't use the X.509 framework, such as JWTs. It certainly can be used, but a JWK can provide similar key material without the overhead of public certificate issuance if the provenance of the key can be trusted (as with a trusted API endpoint).

Note also that the X.509 certificate in use might not be suitable for other reasons as well. Publicly trusted X.509 certificates cannot currently use Ed25519, which may be desirable; they may expire before the tokens become invalid if they have a short duration; and the service that performs TLS termination in the environment may be totally separated from the service that issues tokens.

Answer 2

This might not provide a full answer but I am unable to comment. The most common reason I can think of is the token containing data you might not want to leak to the user agent. This applies primarily to access tokens, which by design are only to be handled through the resource server. This could be either:

• Claims that might hint on how your API logic behaves;
• Internal user Information, such as a GUID, you want to keep obscure.

Think of an attacker somehow being able to sniff the data traffic of an API running in business intranet and thus hijacking a bunch of tokens. Since these are encrypted, it limits his ability to construct valid requests. If your tokens were merely signed, he might just grab the one out of dozens of tokens with the longest remaining validity and the claim "role: Admin".