Validating JWT tokens and supporting multiple issuers

moved from: https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/issues/1619

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

I’m using OpenID Connect (Microsoft.IdentityModel.Protocols.OpenIdConnect 5.4.0 nuget) in my C# web API, and I’d like to support and validate JWT tokens issued by multiple identity providers (MSA, LinkedIn, GitHub, Google, etc.), and I appreciate the fact that Microsoft.IdentityModel.Tokens.TokenValidationParameters supports multiple issuers (via ValidIssuers).

On the other hand Microsoft.IdentityModel.Protocols.ConfigurationManager<OpenIdConnectConfiguration> ctor requires and allows only one metadataAddress (.../.well-known/openid-configuration URL) so I assume it’s possible to download public keys only from one provider, is that correct?

Would it be possible to remove the required metadataAddress param, and use the trusted issuer URL to construct that URL instead? In fact that’s what I’m currently doing for MSA, using the trusted issuer (e.g. https://login.microsoftonline.com/<GUID>/v2.0) and appending /.well-known/openid-configuration. In other words, the library allows multiple trusted issuers, but only one metadata address.

Describe the solution you’d like

Could you provide guidance about supporting multiple identity providers, e.g. sample code or tutorial showing how that works?

Describe alternatives you’ve considered

I considered creating multiple instances of the OpenID Connect manager, one per provider.

[brentschmaltz]

This should be handled by the ASP.Net handler under development.

[brentschmaltz]

@MedAnd we developed a model that supports multiple inbound security policies including multiple IDP’s (google, aad, aws, …), authentication schemes (bearer, pop, …), token types (saml1, saml2, jwt, cbor, …).

When a request arrives, processing obtains a policy that can process a specific authentication scheme. It may be the case multiple policies exist (bearer, where both google and aad are trusted).

The contents of the authentication header are examined, hydrated and validated as far possible using the first policy. Since it is possible that multiple policies are in play, intermediate results are maintained when continuing with the next policy. No cpu cycles are wasted, an exception is thrown only if the message cannot be validated by any policy.

Configuration is cached per IDP’s.