Multiple providers not using jwks_uri

[mnaser]

Hi there.

We are currently using the multiple providers feature, however, it seems that for some reason, the jwks_uri is being ignored, resulting in failures such as this:

2021-09-28 23:48:11.401686 oidc_oauth_validate_jwt_access_token: verify JWT against 0 statically configured public keys and 0 shared keys, with JWKs URI set to (null)
2021-09-28 23:48:11.401693 oidc_proto_jwt_verify: "jwks_uri" is not set, signature validation will only be performed against statically configured keys
2021-09-28 23:48:11.401718 oidc_proto_jwt_verify: JWT signature verification failed: [src/jose.c:931: oidc_jwt_verify]: could not find key with kid: TlwS7nEm3O9Ah1-fgCMwR
2021-09-28 23:48:11.401727 oidc_oauth_validate_jwt_access_token: JWT access token signature could not be validated, aborting

For some context:

...
      OIDCMetadataDir /var/lib/apache2/oidc
...
      <Location /v3/OS-FEDERATION/identity_providers/default/protocols/openid/auth>
          LoadModule headers_module /usr/lib/apache2/modules/mod_headers.so
          Header set Access-Control-Allow-Headers "Authorization,Content-Type"
          Header set Access-Control-Allow-Origin "*"
          AuthType oauth20
          Require valid-user
          LogLevel debug
      </Location>
...

The files located inside /var/lib/apache2/oidc is a copy of our openid-configuration pulled from https://id.vexxhost.net/.well-known/openid-configuration which includes jwks_uri...

If I add the following:

OIDCOAuthVerifyJwksUri https://vexxhost.us.auth0.com/.well-known/jwks.json

It works, but then I'm unable to have multiple providers at this point.

[zandbelt]

the multiple providers feature only works in OIDC RP mode, i.e. using AuthType openid-connect

[zandbelt]

upon receiving an access token in OAuth 2.0 RS mode, there's no way to know which provider you'd have to validate it against; OAuth 2.0 was designed with a single relationship between RS and AS in mind; this means that using multiple ASes for the same path would be impossible without a custom protocol addition; however, if you're looking to configure different paths with different ASes, that would be possible through using mod_oauth2

[mnaser]

@zandbelt

Thank you for your quick response. We do indeed use different paths (or thats' what we planned to do). Therefore, I think the best thing to do would be to use mod_oauth2, and then I assume OAuth2TokenVerify can be scoped by Location and that'll solve my issues I think.

Now to build an image that includes those packages, as we are/were relying on upstream packaging for this.

[lu1as]

I ran into the same problem and tried to merge the keys from multiple JWKS servers into one endpoint which is then used in OIDCOAuthVerifyJwksUri. This worked, but resulted in a security problem as providers can now fake the issuer in the iss claim and pretend that the token was issued by another provider.

@zandbelt - Maybe it would be possible to use the iss token claim value to fetch the JWKS URI from the metadata folder? This would allow using separate JWKS URIs and ensure that the token was actually issued by the provider defined in the iss claim.

[zandbelt]

just use mod_oauth2, it supports multiple OAuth2TokenVerify statements in a single location and will try each in the order of specification; this also works when using it together with mod_auth_openidc for OpenID Connect on the same path (i.e. using AuthType auth-openidc)

[lu1as]

Thanks for your response, this works for sure. I thought it would be nice to have it in one module, so that e.g. also the environment variable names (like for the iss claim) match and the backend does not need to be aware of the two auth modules. But I was able to build a workaround for that:

<LocationMatch /v3/OS-FEDERATION/identity_providers/vault/protocols/openid/auth>
      AuthType auth-openidc
      OAuth2TokenVerify jwks_uri https://vault.example.com/v1/identity/oidc/.well-known/keys
      Require oauth2_claim iss:https://vault.example.com/v1/identity/oidc
      SetEnv HTTP_OIDC_ISS https://vault.example.com/v1/identity/oidc
</LocationMatch>