TykTechnologies / tyk

Tyk Open Source API Gateway written in Go, supporting REST, GraphQL, TCP and gRPC protocols
Other
9.73k stars 1.09k forks source link

Support multiple JWKS sources / one source per OIDC provider/issuer #6320

Open djablonski-moia opened 5 months ago

djablonski-moia commented 5 months ago

Is your feature request related to a problem? Please describe.

Tyk nicely supports configuring multiple OIDC identy providers in parallel in the OpenId Connect middleware openid_options within an apidefintion. Unfortunately, the JWT middleware only supports configuring one global jwt_source endpoint for signature verification, so effectively, only one OIDC IdP can be securely used (i.e. with signature verification).

Describe the solution you'd like

We'd like to be able to configure one JWKS source URL per OIDC IdP, either within the openid_options.providers entry, or alternatively (and likely easier to implement due to being a different middleware), as an alternative jwt_sources property, that could look like this (using the same issuer URLs that are used in the openid_options):

"jwt_sources": [
    {
        "issuer": "<issuer url>",
        "jwt_source": "<key or jwks url>"
    },
    {
        "issuer": "<issuer url>",
        "jwt_source": "<key or jwks url>"
    }
]

Describe alternatives you've considered

The only alternative to solve the issue is to implement an "aggregating proxy", i.e. a component that collects & combines all key sets from all the OIDC IdPs, and generates a huge list containing all keys from all IdPs. In assition to the need for extra infrastructure, this has a significant risk of causing issues due to non-unique kids, that may occur with different providers.

Additional context

none

andyo-tyk commented 3 weeks ago

Hi @djablonski-moia, We are actually deprecating the dedicated OIDC Auth middleware from the next release, due to known limitations in the implementation - and recommend that users switch to the JWT Auth middleware (don't worry, we won't be EOL-ing the middleware just yet). From your description, I'm guessing this recommended alternative won't fit your needs. I'd be interested to understand what is missing from the JWT Auth capability to support your use case