[FEATURE REQ] DefaultAzureCredential should send x5c claim for app authentication #25822
Labels
Azure.Identity
Client
This issue points to a problem in the data-plane of the library.
customer-reported
Issues that are reported by GitHub users external to the Azure organization.
needs-team-attention
Workflow: This issue needs attention from Azure service team or SDK team
question
The issue doesn't require a change to the product in order to be resolved. Most issues start as that
Library name
Azure.Identity
Please describe the feature.
DefaultAzureCredential covers many basic authentication scenarios, including application ID + certificate. However, if the application is configured to use subject name + issuer certificate validation (as opposed to thumbprint validation),
DefaultAzureCredential
fails because the certificate's x5c claim is never sent to AAD when generating an auth token. Given the increasing number of applications using SNI authentication for automatic certificate rollover support, this scenario should be supported byDefaultAzureCredential
.Proposal
Modify DefaultAzureCredentialOptions to support the option to send certificate x5c claim by adding a
EnvironmentCredentialSendCertificateChain
bool property.Details
When
AZURE_TENANT_ID
,AZURE_CLIENT_ID
, andAZURE_CLIENT_CERTIFICATE_PATH
environment variables are set,DefaultAzureCredential
creates anEnvironmentCredential
which creates aClientCertificateCredential
which creates anMsalConfidentialClient
which uses MSAL to conditionally send the x5c claim here. This condition is controlled by ClientCertificateCredentialOptions.SendCertificateChain property.DefaultAzureCredentialOptions.EnvironmentCredentialSendCertificateChain
propertyEnvironmentCredentialOptions
class with aSendCertificateChain
propertyDefaultAzureCredentialOptions
toClientCertificateCredentialOptions
Alternative Proposal
Enable
ClientCertificateCredentialOptions.SendCertificateChain
by default whenEnvironmentCredential
creates aClientCertificateCredential
.Reference
Support for SNI was added in PR 14636
The text was updated successfully, but these errors were encountered: