Validating JWT tokens and supporting multiple issuers

[dluc]

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]

@dluc we recognize the pattern: multiple identity providers. We have some work in that area, but it's early. That pattern is to decompose artifacts that arrive and see what policy can handle them.

Currently the handlers in asp.net handle a single providers at a time and require overloading of TokenValidationParameters with delegates such as AudienceValidator. Asp.net allows for setting TokenValidationParameters as a somewhat catch all extensibility point. I haven't completed an end-to-end example so I am not entirely sure, but since this would be blocking an important scenario, adding features or fixing bugs would make sense to consider, until a real solution is ready.

[MedAnd]

@brentschmaltz - any update on this feature?

[brentschmaltz]

@MedAnd we are figuring out when we can get this in. It's in our committed backlog.

[MedAnd]

@brentschmaltz - more of related topic but hope this will also include guidance on how to configure for multi-issuer scenarios as I could not find in existing docs? For example OpenIdConnectConfiguration may need to retrieve public IssuerSigningKeys from multiple IdPs...

Are there any performance considerations of above use case scenario, for example should the OpenIdConnectConfiguration be a singleton, are the IssuerSigningKeys cached internally, is ValidateToken designed for high performance scenarios etc?

Thx.

[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.

[brentschmaltz]

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

[henrik-me]

@mafurman : to be considered in the configuration manager work? CC: @GeoK @RojaEnnam

[jmprieur]

ValidIssuers exists on TokenValidationParameters. See:

https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/eeaa61ba4887ded80875ed5659aa8a7c04b1da96/src/Microsoft.IdentityModel.Tokens/TokenValidationParameters.cs#L906

[bh3605]

It would be really great now if the ConfigurationManager was set up to be able to use multiple issuers instead of just one. I really enjoy the ConfigurationManager can essentially renew the signing key when it finds a SecurityTokenSignatureKeyNotFoundException is thrown