JWT: support both certs and raw public keys

[maxtropets]

For instance, FB openid conf:
https://www.facebook.com/.well-known/oauth/openid/jwks/

Format:

        {
            "kid": "dcd214c095176e06454dfe832254b0cde52b6052",
            "kty": "RSA",
            "alg": "RS256",
            "use": "sig",
            "n": "6GkDCgRsMiCb2Zsjge86oXAFwvRIOTEAlLCtxtFzsb2x6alKYa1ycSEmiwj_hlGXUQnbrj8VEWkT9ZigNC-WAGxhCe-RikzkmUG99_xACWzoI9zUN50Qj6jZM8-P-pmoYEnKK_7yj2gJSlzMtWYBRzJihz5-zN3Ed75GVQOuANytYbAclPmhm2-g-gfH9g6JRqYsBY6k-MMP0d5VLk8u_nAg6jf0Kw4Ii-PndlNHsyG6aXHXteyFsZ7bBOjb_nUs9C0xgiJPVqMoOtMRhelDLuj4W4N7CQVxoCEvkW6g0932eCOzteOvbawXutx18kF2bGrSgFvIOLCbnzL8dgf7zw",
            "e": "AQAB"
        },

CCF now only supports x5c field though. It has to support both x5c and n + e combination.

• Construct public key from n + e fields
• Save raw public key first OR x5c in jwt_management.h
• Raw key verification impl (currently OpenSSL_Verifier only supports certs)
• Use public key first in jwt_auth.cpp, fallback to cert if needed
• Test-cover public key verifier (unit tests)
• Test-cover third-party key provider (e2e)

[maxtropets]

@achamayou, one design question so far, shall we

• create a self-endorsed certificate and keep it in the existing schema
• OR extend the table to contain pubkeys too
• OR replace all certs with pubkeys?

Self-endorsed cert looks, as we may set expiry date explicitly, however, it may look a little weird. On the other hand, it's a smaller change, no schema changes involved.

[maxtropets]

Talked on-site. Decided to move on with extending

  struct OpenIDJWKMetadata
  {
    Cert cert;
    JwtIssuer issuer;
    std::optional<JwtIssuer> constraint;
    // new key: raw public_key
  };

This avoid breaking old entries format and simplifies transition to the new code version.

[maxtropets]

Wondering which key types to support in here. Checked Google's and Facebook's well-knows configs, both use RSA256 keys.

@PallabPaul do you have a list of providers you intend to support? At least those which you think may be a must-have, just to double-check the key types.

[PallabPaul]

So the overall goal would be to support the same IdP's that other Azure services like Azure Function supports listed here and also allow customers to add their custom IdP as long as they follow the OIDC protocol:

From this list it looks like Apple also follows RSA256 but couldn't find the well-known endpoint for Github or Twitter. IMO, RSA256 keys should suffice and open up many common IdP's that we can support.

We have also started exploring alternatives such as inviting external IdP's to Microsoft Entra Id which would allow the external user to be part of AAD and have a JWT token provided by Microsoft which includes the x5c field but it seems like this is only limited to Google, Facebook and IdP's that follow a SAML/ WS-Fed based authentication protocol.

[maxtropets]

supports listed here

That's a useful one, thank you!