Skip to content

Audience Mismatch

Symptom

The pod has a projected service account token and the issuer looks correct, but Microsoft Entra rejects token exchange or the application reports invalid audience errors.

Possible Causes

  • The federated identity credential was created with the wrong audience value.
  • Automation built a credential template for a different token exchange pattern.
  • The application or SDK is not using the intended workload identity flow.
  • Operators fixed the issuer and subject but never validated audience alignment.

Diagnosis Steps

flowchart TD
    A[Projected token exists] --> B[Confirm issuer and subject already match]
    B --> C[Inspect federated credential audience]
    C --> D[Compare with workload identity token exchange expectation]
    D --> E{Audience matches?}
    E -->|No| F[Recreate or update federated credential]
    E -->|Yes| G[Inspect SDK path and downstream auth]

  1. Confirm the workload identity basics are already correct before isolating audience.

    az aks show \
    --resource-group "$RG" \
    --name "$CLUSTER_NAME" \
    --query "oidcIssuerProfile.issuerUrl" \
    --output tsv

kubectl get serviceaccount "$SERVICE_ACCOUNT_NAME" \
    --namespace "$NAMESPACE" \
    --output yaml
    Command Purpose
    az aks show Read the cluster OIDC issuer URL.
    --resource-group Resource group that contains the AKS cluster.
    --name Name of the AKS cluster.
    --query Selects the OIDC issuer URL.
    --output Output format for the result.
    kubectl get serviceaccount Show the workload service account definition.

  2. Inspect the federated identity credential definition.

    az identity federated-credential show \
    --resource-group "$RG" \
    --identity-name "$USER_ASSIGNED_IDENTITY_NAME" \
    --federated-credential-name "$FEDERATED_CREDENTIAL_NAME" \
    --output json
    Command Purpose
    az identity federated-credential show Show a federated credential on the identity.
    --resource-group Resource group that contains the identity.
    --identity-name Managed identity that owns the credential.
    --federated-credential-name Name of the federated credential.
    --output Output format for the result.

  3. Correlate application logs with token exchange attempts.

    kubectl logs "$POD_NAME" \
    --namespace "$NAMESPACE" \
    --since=30m

  4. If the workload reaches Azure but still fails, continue with downstream authorization checks.

    az role assignment list \
    --assignee "<object-id>" \
    --scope "$RESOURCE_ID" \
    --output table
    Command Purpose
    az role assignment list List role assignments for the identity.
    --assignee Object ID of the identity to inspect.
    --scope Resource scope to filter assignments.
    --output Output format for the result.

Resolution

  • Recreate or update the federated identity credential so the audience matches the workload identity token exchange expectation.
  • Roll a canary pod and verify fresh token exchange before changing production deployments.
  • If the credential matches and failures persist, shift to downstream authorization or SDK-path debugging.

Prevention

  • Template federated identity credentials from validated automation, not from ad hoc portal entry.
  • Validate issuer, subject, and audience together during every workload identity rollout.
  • Keep a known-good example for each namespace and service account pattern you standardize.

See Also

Sources