Support for resolving keys from a HTTPS x509 certificate service
The org.jose4j.keys.resolvers.HttpsJwksVerificationKeyResolver class resolves verification keys for a JWT from a org.jose4j.jwk.HttpsJwks object, which gets a JWKS over HTTPS per Open ID Connect.
I am using a Ping Federate token server which is issuing OAuth2 access tokens in the JWT format, and the (asymmetric, public) verification keys are made available as x509 certificates in a different manner than JWKS. See the last two field descriptions on this documentation: https://documentation.pingidentity.com/display/PF70/Configuring+JSON-Token+Management . The URL format seems like something that could be specified as a template.
Was that type of key resolution intentionally left out of jose4j, or not implemented out of lack of interest/awareness?
I can decode test tokens, find a range of key ids used for signing, and then copy and paste the public certificate returned from the token server into something that the org.jose4j.keys.resolvers.X509VerificationKeyResolver can deal with, but this leaves much to be desired as the tokens only list the key id in the JWT header rather than the x509 cert thumbprint, and thus I need to set the "try all the keys" option on the x509 verifier at that point. Also, when the certs are renewed based on expiration, or added/deleted based on use, I would need to manually make changes to the token server clients which are doing local token verification.
Comments (3)
-
repo owner -
Okay thanks for the code! We're looking forward to that feature in the next version of the token server, which would make things nice and streamlined overall.
-
repo owner - changed status to resolved
You are welcome! Thanks for using my open source project and my employer's product.
- Log in to comment
As it happens, I built that stuff in PingFederate some years ago. The X.509 endpoints that PingFederate optionally exposes in support of JWT access token validation were developed before the JWK standard and applications of it like OpenID Connect's HTTPS JWKS URI had really stabilized. That kind of key resolution wasn't included in jose4j because, while it's conceptually similar to an HTTPS JWKS endpoint, it's not standardized to the same extent. Generally, I try to keep the scope of core stuff in jose4j relatively small, focused and standards based.
The next release (8.2) of PingFederate actually has a new option to expose the certs and keys from JWT access token managers as an HTTPS JWKS endpoint to better align with standards (and integrate with jose4j more easily for that matter). So that may be an option in the future.
With all that said, however, the key resolver functionality in jose4j is extensible and customizable so you can plug in your own implantation of the VerificationKeyResolver interface to do exactly what you need. The following code has a VerificationKeyResolver implementation wrapped in a little test I used to check it that also shows kinda how to use it. Hope this helps!