Revamp the client authentication method negotiation logic and support mTLS token binding in the client, server and validation stacks#2426
Merged
kevinchalet merged 1 commit intoopeniddict:devfrom Feb 21, 2026
Conversation
… mTLS token binding in the client, server and validation stacks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2421.
This PR implements the remaining mTLS tasks that were not implemented as part of the mTLS PR dedicated to the client authentication part:
TlsClientAuthenticationCertificateSelectorandSelfSignedTlsClientAuthenticationCertificateSelectoroptions present in the System.Net.Http integration packages have been marked as deprecated, are no longer used and will be removed in a future version as they didn't allow flowing certificates dynamically, which is required for mTLS token binding using certificates generated on-the-fly (typically per user or per authorization flow).OpenIddictClientSystemNetHttpContextandOpenIddictValidationSystemNetHttpContextclasses have been introduced to allow flowing X.509 certificates from OpenIddict to HttpClientFactory via some targeted async-local sorcery. This is required as HttpClientFactory doesn't allow defining handler-specific options for each HTTP request (which is something we need to dynamically select the TLS client authentication certificates).OpenIddict.ClientandOpenIddict.Validationwill now negotiatetls_client_auth,self_signed_tls_client_authandclient_secret_basicwithout requiring more specific handlers in the System.Net.Http integration packages.GetPublicKeyInfrastructureTlsClientAuthenticationPolicyAsync()has been updated to support resolving intermediate CA certificates, which is essential to support subordinate ACs scenarios where the organization owning the authorization server wants to allow each client organization to sign its own end certificates.