I'm wondering if there is any guidance on including "jku", "jwk", "x5u", and "x5c" claims in a JWT/JWS used as a bearer assertion for authentication.
Specifically, in the case of service-to-service authentication, where the "iss" is set to the service acting as a client, say "https://client.example.net/"; making a request to "https://api.example.com/";, and the assertion is signed using client.example.net's private key. In this situation, api.example.com authenticates the assertion by finding the corresponding public key (possibly in a JWK set, the location of which can be obtained by something like OpenID Provider Configuration [1]). It is clear that any claims in the assertion are self-asserted until validated, including both the "iss" and any keys or URLs to keys. Thus, when a service validates the assertion, it *must not* use the values of "jku", etc to validate the signature. Instead it should use some trusted channel to obtain the keys directly from the issuer. If this were not done, a malicious entity could freely generate assertions claiming to be client.example.net, using any private key and including a malicious reference to its own public key using a "jku" set to " https://malicious.com/jwks.json"; This security consideration is not called out anywhere that I've noticed, which I've seen leading to insecure implementations and/or bad examples. For example, this example on Gluu's wiki: http://ox.gluu.org/doku.php?id=oxauth:jwt is blindly using the value of "jku" to fetch the key used to validate the signature, without any way to validate that the URL itself belongs to the issuer. I'm raising this point hoping that guidance can be clarified and included in the specification. Thanks, Jared Hanson PS. I separately sent this same message to the JOSE list, and later figured it was equally relevant to OAuth, if not more so. [1] http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig -- Jared Hanson <http://jaredhanson.net/>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
