Support bare keys in JWKS for JWT auth
Currently, CCF only accepts JWKS documents where each key has an x5c field. While this is the case for Microsoft, it is not required by the spec:
The JWK x5c parameter MAY be used to provide X.509 representations of keys provided. When used, the bare key values MUST still be present and MUST match those in the certificate.
An example where only bare keys are used: https://accounts.google.com/.well-known/openid-configuration
At the moment, CCF converts x5c into DER encoding and then stores that in the kv. At validation time, it assumes a DER-encoded X.509 cert was stored.
An alternative may be to store a DER-encoded public key instead. This key would have to be created from the individual fields in the JWK, like kty, n, and e. To remain backwards compatible, CCF would have to support both variants for a while. Unfortunately, DER is not self-describing, so it's not possible to easily figure out if something is a public key or cert. An option may be to try parsing as public key first, and fall-back to cert parsing. The fall-back would only be used until the next (auto-)refresh of the keys.
@letmaik is this a blocker for a particular use case?
Google uses bare keys for example, but I don’t have that use case myself. https://www.googleapis.com/oauth2/v3/certs
On 25 Jul 2022, at 11:37, Amaury Chamayou @.***> wrote:
@letmaik is this a blocker for a particular use case?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
Closing for now, since there is no immediate demand for this.