Course contentsShow
← C#
Lesson 1257 of 1,90811. Identity, Security, and ClaimsFree lesson

Identity Provider Discovery

Implement dynamic discovery for OIDC providers to support multiple identity sources.

In this lesson, you will learn how to implement dynamic discovery to allow your application to automatically configure itself for different OpenID Connect (OIDC) providers at runtime.

Why Dynamic Discovery?

When your application supports multiple identity sources (e.g., Azure AD, Auth0, or internal identity servers), hardcoding endpoints like authorization_endpoint or jwks_uri becomes unmanageable. Instead of configuring these manually, we use the OIDC discovery specification (/.well-known/openid-configuration). This allows your application to fetch the provider’s metadata programmatically, ensuring your app stays synced even if the provider rotates their signing keys or shifts infrastructure.

Implementing Discovery in C#

In ASP.NET Core, you don't need to manually fetch these JSON files. The OpenIdConnectOptions class handles the heavy lifting through the MetadataAddress property. When you provide the issuer URL, the middleware performs an HTTP request to the discovery document to populate its internal configuration.

To support multiple dynamic sources, you can intercept the OnRedirectToIdentityProvider event or utilize a custom IAuthenticationConfigurationProvider to resolve the issuer based on user input (like a domain name):

services.AddAuthentication()
    .AddOpenIdConnect("DynamicOIDC", options =>
    {
        // Point to the well-known discovery endpoint
        options.MetadataAddress = "https://login.example.com/.well-known/openid-configuration";
        options.Authority = "https://login.example.com";
        options.ClientId = "your-client-id";
        
        // This triggers the background fetch of metadata
        options.RefreshOnIssuerKeyNotFound = true;
    });

The Workflow

  1. Trigger: The user enters their email or domain.
  2. Resolution: Your app identifies the correct issuer URL based on the domain.
  3. Discovery: The middleware calls the .well-known endpoint.
  4. Validation: The app automatically caches the keys (JWKS) and endpoint URLs found in the response.

By relying on discovery documents, your system becomes resilient to infrastructure changes. If a provider updates their token signing certificate, your application will see the change in the discovery metadata and pull the new public key without requiring a code deployment or a service restart.

Key Takeaway: Use the OIDC .well-known/openid-configuration endpoint to dynamically resolve identity provider settings, reducing manual configuration errors and enabling seamless support for multi-tenant or multi-provider identity architectures.