Add client registration handling to OpenIdConnect authentication flow

[glucaci]

Add client registration handling to OpenIdConnect authentication flow

Summary

Adds per-request extension points to OpenIdConnectHandler to support multi-tenant scenarios where the OIDC client identity, credentials, and token validation settings vary per request — without requiring a full handler fork.

Motivation

Applications that serve multiple tenants through a single OIDC authentication scheme (e.g., resolving Entra ID app registrations per-request) currently have no way to override client_id, client_secret, or TokenValidationParameters on a per-request basis. The only option today is to fork the entire handler. This PR adds minimal, non-breaking extension points that close that gap.

Changes

New type: OpenIdConnectClientRegistration

A simple, unsealed class grouping the three per-request client values:

ClientId — used in authorize, token, PAR requests and protocol validation
ClientSecret — used in token and PAR requests (nullable for public clients / assertion-based auth)
TokenValidationParameters — used for ID token validation

New virtual method: ResolveClientRegistrationAsync

protected virtual ValueTask<OpenIdConnectClientRegistration> ResolveClientRegistrationAsync(
    AuthenticationProperties properties)

Default implementation returns values from OpenIdConnectOptions(with a cloned TokenValidationParameters), preserving existing behavior. Override to resolve a different client registration per request.

New event method: AuthorizationCodeReceivedContext.HandleClientAuthentication()

Mirrors the existing PushedAuthorizationContext.HandleClientAuthentication() pattern. When called in OnAuthorizationCodeReceived, the handler removes client_secret from the token endpoint request, allowing the event to provide alternative credentials (e.g., client_assertion / private_key_jwt).

Design notes

• ValueTask<T> — The default implementation is synchronous (ValueTask.FromResult), avoiding a Task allocation on the hot path.
• HandleClientAuthentication on AuthorizationCodeReceivedContext — Follows the identical pattern already shipped on PushedAuthorizationContext
• Scope / Prompt / MaxAge excluded — These already have per-request overrides via AuthenticationProperties.GetParameter<T>()

[dotnet-policy-service]

Thanks for your PR, @@glucaci. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

Pull request overview

Adds per-request extension points to OpenIdConnectHandler to support multi-tenant OpenID Connect scenarios by dynamically resolving client registration and allowing events to take over token endpoint client authentication.

Changes:

• Introduces OpenIdConnectClientRegistration and OpenIdConnectHandler.ResolveClientRegistrationAsync(...) for per-request client settings.
• Adds AuthorizationCodeReceivedContext.HandleClientAuthentication() / HandledClientAuthentication to allow alternative token endpoint authentication (e.g., client assertions).
• Adds a comprehensive new test suite covering default and overridden behaviors across challenge, PAR, token redemption, and protocol validation.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/Security/Authentication/test/OpenIdConnect/OpenIdConnectExtensionTests.cs	Adds tests validating dynamic client registration and handled client authentication behavior.
src/Security/Authentication/OpenIdConnect/src/PublicAPI.Unshipped.txt	Records newly added public APIs for the OpenIdConnect package.
src/Security/Authentication/OpenIdConnect/src/OpenIdConnectHandler.cs	Wires dynamic client registration through challenge, PAR, token redemption, and protocol validation; honors handled client authentication.
src/Security/Authentication/OpenIdConnect/src/OpenIdConnectClientRegistration.cs	Introduces the per-request client registration data container (id/secret/TVP).
src/Security/Authentication/OpenIdConnect/src/Events/AuthorizationCodeReceivedContext.cs	Adds event-controlled client authentication handling for code redemption.

[Copilot]

properties is used elsewhere in this method as nullable (e.g., passed as properties! later), but here it's passed as non-null to ResolveClientRegistrationAsync(AuthenticationProperties properties). This is a nullability mismatch and may not compile (or can introduce a nullability warning-as-error). Use properties! here (consistent with the existing usage) or ensure properties is non-nullable by construction before this point.

Suggested change

	var registration = await ResolveClientRegistrationAsync(properties);
	var registration = await ResolveClientRegistrationAsync(properties!);

[Copilot]

This assertion would still pass if client_secret is present but empty, which weakens the test and could mask a regression (the comment says it should be omitted). Prefer asserting that the key is not present at all (e.g., Assert.DoesNotContain(\"client_secret\", capturedTokenParams.Keys)).

Suggested change

	Assert.False(capturedTokenParams!.ContainsKey("client_secret") && !string.IsNullOrEmpty(capturedTokenParams["client_secret"]));
	Assert.DoesNotContain("client_secret", capturedTokenParams!.Keys);

[Copilot]

The tests create TestServer instances but never dispose them. This can leak resources across the test run and cause flakiness. Update the tests to dispose servers (e.g., await using var server = ...; / using var server = ...;) consistently after each test.

[Copilot]

HttpUtility.ParseQueryString(...) returns a NameValueCollection whose enumerator can yield null keys. Declaring the loop variable as non-nullable string makes the key is not null check ineffective (the assignment would already have failed). Use foreach (string? key in query) or iterate query.AllKeys to accurately reflect nullability and simplify the code.

[glucaci]

@halter73 thanks for taking a look to this PR.