Federated Credential Audience Mismatch Silently Blocks Azure Workload Identity Token Exchange

Symptom

A workload running in Azure (an AKS pod using workload identity, or an application using a federated credential from an external OIDC issuer) fails to acquire an Azure AD access token. The failure surfaces as an authentication error from the Microsoft Authentication Library (MSAL) or the Azure SDK’s default credential chain, typically reported as AADSTS70021 (“No matching federated identity record found”) or a token exchange timeout. Crucially, the federated identity credential was created successfully in Microsoft Entra ID with no validation warnings, and the subject and issuer values were confirmed correct during setup.

False Assumption

The engineer configuring the federated identity credential assumes that because Entra ID accepted the credential without error, the audience field is correct by implication, or that the audience defaults to a value Entra ID will match automatically against whatever token the workload’s OIDC issuer actually presents. In practice, Entra ID’s federated credential creation only validates that the audience field is a syntactically well-formed value (commonly api://AzureADTokenExchange); it does not verify that the workload’s issuer will ever produce a token whose ‘aud’ claim matches that string. The credential can be saved, appear in the portal as fully configured, and remain non-functional indefinitely because the mismatch is never checked at creation time.

Root Cause

Azure AD federated identity credentials perform trust exchange based on three fields: issuer, subject and audience. At token exchange time, Entra ID retrieves the workload’s OIDC token, checks the issuer against the configured issuer URL, checks the subject claim against the configured subject, and separately checks that the token’s audience claim exactly matches the configured audience value. If the workload’s OIDC provider (for example, an AKS OIDC issuer, GitHub Actions OIDC, or a third-party identity provider) issues tokens with a different audience string than what was entered in the federated credential’s audience field, the match fails silently at exchange time, not at configuration time. This is a validation gap: Microsoft Entra ID validates credential shape, not run-time audience compatibility. The Microsoft cloud security benchmark documents identity federation and access control as governed control domains, but does not itself assert a specific default audience behaviour for every issuer combination; that behaviour must be confirmed against the specific OIDC issuer and Entra ID documentation in use, and treated as version- and issuer-sensitive rather than assumed.

Impact

The workload cannot obtain an Azure AD token, so every downstream call depending on that identity fails: Key Vault access, storage access, Azure Resource Manager calls, or any Azure service gated by Azure RBAC. Because the credential object exists and looks correctly configured in the portal, on-call engineers frequently escalate to network or RBAC troubleshooting first, extending time to resolution. The blast radius is contained to the specific workload identity’s ability to authenticate; it does not expose other identities or grant unintended access, but it does produce a full authentication outage for the affected workload with no data exposure.

Diagnosis

Confirm the failure is an audience mismatch, not an issuer, subject, or permissions problem, using read-only inspection before changing anything.

Read-only diagnostic commands

Correction

The fix is to align the federated credential’s audience value with the audience actually issued in the workload’s OIDC token, not to guess a default. Decode the workload’s presented OIDC token (from the issuer, not from Entra ID) and read its ‘aud’ claim directly; then update the federated credential’s audience field in Entra ID to match that exact string.

For Azure Kubernetes Service workload identity, the audience is almost always api://AzureADTokenExchange, but this must be confirmed against the specific AKS OIDC issuer and service account annotation in use, since some third-party or custom OIDC issuers emit a different default. For GitHub Actions OIDC federation, the audience is set explicitly in the workflow’s id-token permission request and must match what is configured in Entra ID, not assumed to be a platform default.

Validation

Validation requires observing a successful token exchange, not merely a config change without error. After updating the audience value, re-run the workload’s authentication path and confirm token issuance succeeds end-to-end, with the correct audience visible in the exchanged token and no AADSTS70021 error in Entra ID sign-in logs.

Rollback

If the audience change does not resolve the failure, or introduces a new authentication error, revert the federated credential’s audience field to its prior value immediately; this is a metadata-only change with no cascading state, so reversal is immediate and low-risk. Record the exact prior and new audience strings before changing anything, since Entra ID does not retain a built-in change history for federated credential field edits in the portal view used here.

Prevention

Treat the federated credential’s audience field as a value that must be verified against the actual OIDC issuer’s token output, not inferred from the credential form accepting the entry. Before deploying any new federated identity credential, decode a sample token from the issuer and confirm its audience claim matches what will be entered in Entra ID, and record that verification step as part of the change record for the credential. Re-verify audience alignment whenever the OIDC issuer, its signing configuration, or the client application requesting tokens changes, since any of these can silently alter the issued audience without altering the federated credential configuration itself.