Microsoft Azure

A Entra ID workload identities

A federated identity credential lets any OIDC issuer stand in for a client secret, and managed identities hand out Entra-signed JWTs on demand. Client secrets cap at two years and tenant policy can shorten or ban them; you get 20 federated credentials per app, exact-match only.

Docs: learn.microsoft.com · Checked 2026-09-16 · source YAML · dispute via PR

Inbound A

How a workload running anywhere authenticates to this product.

Federated identity credential on an app registration or user-assigned managed identity that trusts an external OIDC issuer URL with an exact issuer, subject and audience match; the workload presents the external JWT as a client_assertion in the client credentials flow and gets an Entra access token for Azure Resource Manager or any Entra-protected API.

Issuers: any

learn.microsoft.com checked 2026-09-16
“You use workload identity federation to configure a user-assigned managed identity or app registration in Microsoft Entra ID to trust tokens from an external identity provider (IdP), such as GitHub or Google.”
learn.microsoft.com checked 2026-09-16
“The Federated Identity Credential issuer, subject, and audience values must case-sensitively match the corresponding issuer, subject and audience values contained in the token being sent to Microsoft Entra ID by the external IdP in order for the scenario to be authorized.”
learn.microsoft.com checked 2026-09-16
“Issuer: must match the iss claim in the token issued by the external identity provider. A URL that complies with the OIDC Discovery spec. Microsoft Entra ID uses this issuer URL to fetch the keys that are necessary to validate the token.”
learn.microsoft.com checked 2026-09-16
“A maximum of 20 federated identity credentials can be added to an application or user-assigned managed identity.”
learn.microsoft.com checked 2026-09-16
“Only issuers that provide tokens signed using the RS256 algorithm are supported for token exchange using workload identity federation.”

Bring-your-own issuer via the "Other issuer" scenario: any OIDC-discoverable https issuer. Limits worth knowing: 20 federated identity credentials per app or user-assigned managed identity; issuer plus subject must be unique per app; exactly one audience per credential (recommended api://AzureADTokenExchange); no wildcards in any field, so one credential per branch, environment or service account, though a "flexible federated identity credential" with claim-matching expressions is in preview; RS256 signing only; Entra stores at most 100 signing keys from the issuer's JWKS; issuer and subject fields are capped at 600 characters. Entra-issued tokens cannot themselves be used as the external token, except through the managed-identity-as-credential path within the same tenant. Misconfigured credentials are created silently and only fail at exchange time. Ambient identity inside Azure (system- or user-assigned managed identity via IMDS) is table stakes and does not earn the A on its own.

Outbound A

How this product reaches into your cloud, repos, or other SaaS.

Managed identities obtain Entra-signed JWT access tokens from the Azure Instance Metadata Service for a chosen resource/audience, verifiable at the tenant's OIDC discovery endpoint; a managed identity token can also serve as the federated credential for an app registration, so no client secret is needed anywhere.

learn.microsoft.com checked 2026-09-16
“Managed identities for Azure resources provide Azure services with an automatically managed identity in Microsoft Entra ID. You can use this identity to authenticate to any service that supports Microsoft Entra authentication, without having credentials in your code.”
learn.microsoft.com checked 2026-09-16
“A query string parameter, indicating the App ID URI of the target resource. It also appears in the aud (audience) claim of the issued token.”
learn.microsoft.com checked 2026-09-16
“You can then exchange the managed identity token for an access token that can access Microsoft Entra protected resources without needing to use or manage App secrets.”
docs.cloud.google.com checked 2026-09-16
“can use managed identities to obtain Azure access tokens.”

The IMDS token endpoint returns a standard Entra JWT whose aud is the resource you ask for, and Google Cloud's workload identity federation accepts exactly these tokens; AWS accepts them through a generic IAM OIDC provider pointed at the tenant's v2.0 issuer. Two caveats that keep this from being effortless: the resource must be an App ID URI registered in the tenant (IMDS returns invalid_resource otherwise), so you typically register an app to represent the third party; and cross-cloud (public to US Government or China) token exchange is not supported. Managed identities exist only on Azure compute that supports them; an app registration running elsewhere in Azure without a managed identity is back to certificates, secrets or a federated credential.

Hygiene for any static credential the product still issues

✓ Expiry enforceable	Every client secret has an end date (default and portal maximum two years). The tenant default app management policy can enforce a shorter passwordLifetime, or block passwordAddition entirely, for all apps and service principals. Note the policy only blocks creating or updating non-compliant credentials; it does not stop token issuance for credentials that already exist. learn.microsoft.com checked 2026-09-16 “Client secret lifetime is limited to two years (24 months) or less. You can't specify a custom lifetime longer than 24 months.” learn.microsoft.com checked 2026-09-16 “Optional. The default value is "startDateTime + 2 years".” learn.microsoft.com checked 2026-09-16 “passwordLifetime \| Enforce a max lifetime range for a password secret. \| Restrict all new password secrets to a maximum of 30 days for applications created after 01/01/2015.”
✓ Rotation via API	Microsoft Graph addPassword / removePassword (and addKey / removeKey for certificates) with startDateTime and endDateTime, so overlap-and-cut-over rotation is fully scriptable. learn.microsoft.com checked 2026-09-16 “Adds a strong password or secret to an application.” learn.microsoft.com checked 2026-09-16 “Remove a password from an application.”
✓ Scoped keys	A secret carries its service principal's Azure RBAC role assignments (built-in or custom, at any scope) and Graph app permissions, nothing more. Same reasoning as the other clouds: bound to a machine principal, not a human's rights. learn.microsoft.com checked 2026-09-16 “A security principal is an object that represents a user, group, service principal, or managed identity that is requesting access to Azure resources. You can assign a role to any of these security principals.” learn.microsoft.com checked 2026-09-16 “In Azure, you can specify a scope at four levels: management group, subscription, resource group, or resource.”
✓ Last-used visible	Service principal sign-in logs record which credential key ID (or certificate thumbprint) was used, and the "Remove unused credentials from applications" recommendation lists credentials idle for 30 days. Caveats: the per-credential fields are on the beta Graph signIn resource (v1.0 lacks them), downloading sign-in logs via Graph needs Entra ID P1/P2, and the recommendation reports requiredLicenses microsoftEntraWorkloadId. Still a pass: the vendor does show it. learn.microsoft.com checked 2026-09-16 “servicePrincipalCredentialKeyId \| String \| The unique identifier of the key credential used by the service principal to authenticate.” learn.microsoft.com checked 2026-09-16 “Your tenant has applications with credentials which have not been used in more than 30 days.”
✓ Leak revocation	GitHub lists Azure Active Directory Application Secret as a partner pattern with push protection. On Microsoft's side the leak surfaces as an ID Protection "Leaked Credentials" risk on the service principal; blocking it automatically needs a risk-based Conditional Access policy for workload identities, which requires Workload Identities Premium, and managed identities are out of scope. The secret is not revoked for you. docs.github.com checked 2026-09-16 learn.microsoft.com checked 2026-09-16 “This risk detection indicates that the account's valid credentials leaked. This leak can occur when someone checks in the credentials in public code artifact on GitHub, or when the credentials are leaked through a data breach.”

Notes

Graded on machine access to Azure Resource Manager and other Entra-protected APIs using app registrations and managed identities. Azure DevOps PATs, storage account keys, SAS tokens and other per-service keys are separate products and are not graded here. Certificates on app registrations are long-lived credentials too and the same hygiene checks apply to them (asymmetricKeyLifetime policy, addKey / removeKey, thumbprint in sign-in logs).

Badge

[![wif.tax grade](https://wif.tax/badge/azure-entra-workload-identity.svg)](https://wif.tax/p/azure-entra-workload-identity/)