This chapter covers workload identity and federated credentials in Microsoft Entra ID (formerly Azure AD), a critical topic for the AZ-500 exam under domain Identity Access, objective 1.3. Workload identity federation allows external workloads (e.g., GitHub Actions, Kubernetes pods) to authenticate to Azure AD without storing secrets, using tokens from trusted identity providers. This topic appears in approximately 5-10% of exam questions, often in scenarios involving secure CI/CD pipelines, managed identities, and avoiding credential leakage. Mastering this concept is essential for designing secure, secretless authentication architectures.
Jump to a section
Imagine a company with a main office (Azure AD) and a satellite office (an external application or service) that needs to access the main office's resources. The satellite office can't just walk in—it needs a trusted relationship. This is like a foreign embassy (the external workload) wanting to access a government building (Azure AD). The embassy can't use its own ID cards; it needs to be issued special passes (credentials) that the government recognizes. But instead of issuing a permanent pass (a service principal secret), the government sets up a federated trust: the embassy can present a temporary badge (a token from its own identity provider, like GitHub Actions or Kubernetes) that the government validates against a pre-agreed set of rules (federated credentials). The badge must include specific claims (e.g., the embassy's name, the issuer, the subject) that match what the government expects. If the badge is valid, the embassy is issued a temporary government pass (an Azure AD access token) to access resources. This way, the embassy never needs to store a long-lived government key—it uses its own identity system, and the government trusts it based on the federation rules. The key mechanism is that the external workload authenticates to its own identity provider first, then presents that proof to Azure AD, which exchanges it for an Azure AD token. This is exactly how workload identity federation works: an external identity (like a GitHub Actions workflow) authenticates to its own IdP, gets a token, and presents it to Azure AD via a federated credential to obtain an Azure AD token without any secrets.
What is Workload Identity and Why Does It Exist?
Workload identity refers to the identity assigned to a software workload (like an application, service, or script) rather than a human user. In Azure, workload identities are typically represented by service principals. Traditionally, workloads authenticate using client secrets or certificates stored in the code or configuration. This practice is risky because secrets can be leaked, rotated, or stolen. Workload identity federation solves this by allowing an external identity provider (IdP) to issue tokens that Azure AD trusts, eliminating the need for Azure AD secrets. The external workload authenticates to its own IdP, obtains a token, and presents it to Azure AD via a federated identity credential. Azure AD validates the token against the federated credential configuration and issues an access token for Azure resources.
How Workload Identity Federation Works Internally
The mechanism relies on the OpenID Connect (OIDC) protocol. The external IdP (e.g., GitHub, Kubernetes, AWS) must be an OIDC issuer that can issue tokens with specific claims. The workflow is:
The workload (e.g., a GitHub Actions workflow) requests an OIDC token from its own IdP (GitHub's OIDC provider). This token contains claims like iss (issuer URL), sub (subject), and aud (audience).
The workload sends this OIDC token to Azure AD's token endpoint, along with the client ID of the Azure AD application and the federated credential identifier.
Azure AD validates the OIDC token by checking:
- The iss claim matches the issuer URL configured in the federated credential.
- The sub claim matches the subject identifier configured (often using a template with conditions).
- The token is cryptographically signed by the IdP (using its OIDC discovery document and JWKS).
- The token is not expired (typically tokens have a short lifetime, e.g., 5-10 minutes).
4. If valid, Azure AD issues an access token for the workload, scoped to the permissions assigned to the Azure AD application (service principal).
Key Components, Values, Defaults, and Timers
- Federated Identity Credential: A resource in Azure AD that defines the trust relationship. It contains:
- Issuer: The URL of the external IdP (e.g., https://token.actions.githubusercontent.com for GitHub).
- Subject: A string or template that identifies the workload. For GitHub, it's typically repo:owner/repo:ref:refs/heads/main.
- Audience: Usually api://AzureADTokenExchange.
- Description: Optional.
- OIDC Token Lifetime: Depends on the IdP. GitHub tokens expire after 5 minutes. Azure AD caches the exchanged token for up to 8 hours (default token lifetime for access tokens).
- Managed Identities: Azure resources can have a system-assigned or user-assigned managed identity, which is a service principal automatically managed by Azure. Managed identities use certificate-based authentication internally, but they can also be configured with federated credentials for external workloads (preview feature).
Configuration and Verification Commands
To create a federated credential using Azure CLI:
az ad app federated-credential create \
--id <appId> \
--parameters '{
"name": "GitHubActionsDeploy",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:myorg/myrepo:ref:refs/heads/main",
"audiences": ["api://AzureADTokenExchange"]
}'To verify the credential exists:
az ad app federated-credential list --id <appId>In GitHub Actions, the workflow uses the azure/login action with client-id, tenant-id, and subscription-id and sets use-oidc: true. The action automatically requests an OIDC token from GitHub and exchanges it for an Azure AD token.
Interaction with Related Technologies
Azure AD Application Registrations: Federated credentials are attached to an app registration (service principal). The service principal must have the necessary RBAC roles on target resources.
Managed Identities: While managed identities are the preferred identity for Azure workloads, federated credentials allow non-Azure workloads (e.g., GitHub Actions, Kubernetes) to use the same identity without secrets.
Azure Key Vault: Federated credentials reduce the need to store secrets in Key Vault for external workloads, but Key Vault can still be used to store the initial configuration.
Conditional Access: Federated credentials do not bypass Conditional Access policies. The resulting Azure AD token is subject to CA policies like any other token.
Security Considerations
Subject Matching: Use specific subject values (e.g., branch-specific) to prevent token reuse from other branches or repositories.
Issuer Validation: Ensure the issuer URL is exactly correct. For GitHub, it must be https://token.actions.githubusercontent.com (no trailing slash).
Token Replay: OIDC tokens have short lifetimes and are bound to a specific audience, reducing replay risk.
Exam Traps
Common Wrong Answer: Candidates often think federated credentials replace managed identities entirely. Reality: Federated credentials are an alternative authentication method for service principals, not a replacement for managed identities. Managed identities are still the recommended identity for Azure-hosted workloads.
Another Trap: Believing that federated credentials are only for GitHub. They support any OIDC-compliant IdP, including Kubernetes, AWS, and Google Cloud.
Value Trap: The audience must be set to api://AzureADTokenExchange — not https://login.microsoftonline.com or any other value.
Create Azure AD App Registration
First, create an Azure AD application registration that will represent the external workload. This app registration gets a service principal in your tenant. You do not need to generate any client secret or certificate for this app because authentication will be handled via federated credentials. The app registration will be assigned RBAC roles on target Azure resources later. In the Azure portal, navigate to Azure Active Directory > App registrations > New registration. Provide a name (e.g., 'GitHubDeployApp') and select the supported account types (typically 'Accounts in this organizational directory only'). After creation, note the Application (client) ID and Directory (tenant) ID.
Configure Federated Credential
On the app registration, go to 'Certificates & secrets' > 'Federated credentials' > 'Add credential'. Select the credential scenario (e.g., 'GitHub Actions deploying Azure resources'). You must provide the issuer URL (e.g., `https://token.actions.githubusercontent.com`), the subject (e.g., `repo:myorg/myrepo:ref:refs/heads/main`), and the audience (`api://AzureADTokenExchange`). The subject can be a template with conditions like `repo:myorg/myrepo:environment:Production` to restrict to a specific environment. You can add multiple federated credentials for different branches or environments. The credential is stored in Azure AD and used to validate incoming OIDC tokens.
Assign RBAC Role to Service Principal
The service principal of the app registration needs permissions on Azure resources. Assign the appropriate RBAC role (e.g., Contributor, Reader, or a custom role) to the service principal at the desired scope (subscription, resource group, or resource). This is done via Azure RBAC: go to the resource's Access control (IAM) > Add role assignment. Select the role and search for the app registration name. Without this step, the workload will authenticate successfully but have no permissions to perform actions.
Configure External Workload to Use OIDC
In the external workload (e.g., GitHub Actions), configure the workflow to use OIDC authentication. For GitHub, this involves setting permissions for the job to `id-token: write` and using the `azure/login` action with `use-oidc: true`, along with the client ID, tenant ID, and subscription ID. The GitHub Actions runner requests an OIDC token from GitHub's OIDC provider by calling the environment endpoint. The token includes the repository, branch, and other claims. The `azure/login` action then exchanges this token for an Azure AD access token using the federated credential.
Token Exchange and Resource Access
The `azure/login` action sends a POST request to Azure AD's token endpoint: `https://login.microsoftonline.com/{tenantId}/oauth2/token` with grant_type=client_credentials, client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer, and client_assertion set to the OIDC token. Azure AD validates the OIDC token against the federated credential. If valid, it returns an access token (JWT) for the Azure AD application. This access token is then used for subsequent Azure API calls (e.g., ARM, Azure CLI). The access token typically has a default lifetime of 1 hour (configurable up to 8 hours). The workload can now manage Azure resources as per assigned RBAC.
Scenario 1: GitHub Actions CI/CD Pipeline
A large enterprise uses GitHub Actions to deploy infrastructure to Azure. Previously, they stored a service principal secret as a GitHub secret. This posed a risk: if the secret leaked, an attacker could deploy malicious resources. They migrated to workload identity federation. They created an app registration 'GitHubDeploy' and added a federated credential for the main branch. The GitHub workflow uses OIDC to authenticate. Now, no secrets are stored in GitHub. The pipeline runs hundreds of times daily. Performance is excellent: the OIDC token exchange adds about 1-2 seconds. Misconfiguration often occurs when the subject claim doesn't match exactly (e.g., using ref:refs/heads/main vs ref:refs/heads/main with a typo). Also, if the workflow runs on a pull request from a fork, the OIDC token is not issued by default (GitHub requires explicit approval for forks).
Scenario 2: Kubernetes Pods Using Azure AD Workload Identity A company runs microservices on Azure Kubernetes Service (AKS) that need to access Azure SQL Database. They use Azure AD Workload Identity (formerly AAD Pod Identity). Each pod is annotated with a client ID of a managed identity or app registration. A mutating webhook injects an OIDC token from the Kubernetes cluster's OIDC issuer into the pod. The pod uses this token to authenticate to Azure AD via federated credentials. The cluster's OIDC issuer URL must be registered as a federated credential issuer. This avoids storing any secrets in the pod. A common issue is that the Kubernetes service account must have the correct annotation, and the federated credential subject must match the service account namespace and name.
Scenario 3: Terraform Cloud Deployments
Terraform Cloud runs infrastructure deployments to Azure. Instead of storing Azure service principal secrets in Terraform Cloud, they use OIDC federation. Terraform Cloud acts as an OIDC provider. The Azure AD app registration has a federated credential with issuer https://app.terraform.io and subject organization:myorg:project:myproject:workspace:myworkspace. During a run, Terraform Cloud requests an OIDC token, which the Terraform provider exchanges for an Azure token. This eliminates secret management. Misconfiguration often involves incorrect subject patterns, causing token exchange failures. Also, the Terraform Cloud workspace must have the OIDC token enabled in its settings.
AZ-500 tests this topic under objective 1.3: 'Configure and manage identity governance and access reviews for Azure AD'. Specifically, you need to 'implement workload identity federation' and 'manage federated identities for external workloads'. The exam focuses on the following:
Understanding the OIDC flow: Know that the external workload authenticates to its own IdP first, then presents that token to Azure AD. The token exchange uses the OAuth 2.0 client credentials grant with a JWT bearer assertion.
Federated credential configuration: Be able to identify the required fields: issuer, subject, and audience. The audience is always api://AzureADTokenExchange. The issuer is the IdP's OIDC endpoint. The subject is a claim that identifies the workload (e.g., repo:owner/repo:ref:refs/heads/main for GitHub).
3. Common wrong answers: - Wrong: Federated credentials are only for GitHub Actions. Reality: They support any OIDC-compliant IdP (Kubernetes, AWS, Google, Terraform Cloud, etc.). - Wrong: Federated credentials replace the need for RBAC. Reality: After authentication, the service principal still needs RBAC roles assigned. - Wrong: You must create a client secret for the app registration. Reality: No secret is needed; authentication uses the OIDC token. - Wrong: Federated credentials are the same as managed identities. Reality: Managed identities are for Azure-hosted resources; federated credentials are for external workloads. However, managed identities can also use federated credentials (preview).
Specific numbers and values:
The audience is api://AzureADTokenExchange (exact string).
GitHub issuer: https://token.actions.githubusercontent.com (no trailing slash).
Token lifetime: OIDC tokens from GitHub are valid for 5 minutes; Azure AD access tokens default to 1 hour.
Edge cases:
If the subject claim is too broad (e.g., repo:*), any branch or fork could authenticate. The exam emphasizes using specific subjects.
For pull requests from forks, GitHub does not issue OIDC tokens unless the workflow has pull_request_target event or explicit approval.
The federated credential must be created before the workload attempts to authenticate; otherwise, token exchange fails.
How to eliminate wrong answers: Focus on the mechanism: there is no secret involved; the workload presents a token from its own IdP. If an answer mentions storing a secret or certificate, it's wrong. Also, the issuer must match exactly—any variation (e.g., https://token.actions.githubusercontent.com/) is invalid.
Workload identity federation allows external workloads to authenticate to Azure AD using OIDC tokens, eliminating the need for secrets.
Federated credentials are configured on an Azure AD app registration with three required fields: issuer, subject, and audience (api://AzureADTokenExchange).
Supported external IdPs include GitHub Actions, Kubernetes, AWS, Google Cloud, Terraform Cloud, and any OIDC-compliant provider.
After authentication, the service principal still needs RBAC roles assigned to access Azure resources.
The OIDC token from GitHub has a 5-minute lifetime; Azure AD access tokens default to 1 hour.
Subject claims should be specific (e.g., include branch or environment) to prevent token reuse from other contexts.
Federated credentials are not a replacement for managed identities; they are an alternative for non-Azure workloads.
These come up on the exam all the time. Here's how to tell them apart.
Service Principal with Client Secret
Requires generating and storing a client secret (string).
Secret can be leaked, rotated, or compromised.
Authentication uses client_secret in OAuth2 flow.
No external IdP dependency; works anywhere.
Secret must be securely stored (e.g., Key Vault).
Service Principal with Federated Credential
No secret needed; uses OIDC token from external IdP.
Eliminates risk of secret leakage.
Authentication uses client_assertion (JWT) in OAuth2 flow.
Requires trust with external OIDC IdP.
Subject to IdP token issuance policies.
Mistake
Federated credentials require a client secret to be generated for the app registration.
Correct
No client secret is needed. Authentication relies on exchanging an OIDC token from the external IdP. The app registration does not need any secret or certificate.
Mistake
Federated credentials only work with GitHub Actions.
Correct
Federated credentials support any OIDC-compliant identity provider, including Kubernetes, AWS, Google Cloud, Terraform Cloud, and more. GitHub is just one common example.
Mistake
Managed identities and federated credentials are the same thing.
Correct
Managed identities are for Azure-hosted resources and use certificate-based authentication automatically. Federated credentials are for external workloads to authenticate to Azure AD without secrets. They are different concepts, though managed identities can also be configured with federated credentials (preview).
Mistake
The subject field in a federated credential can be any string, and Azure AD will match it exactly.
Correct
The subject field often uses a template with variables (e.g., `repo:owner/repo:ref:refs/heads/main`). Azure AD matches the subject claim from the OIDC token against this template. Wildcards are not supported; it must be an exact match or a template that resolves to an exact value.
Mistake
After setting up federated credentials, the workload can immediately access any Azure resource without additional configuration.
Correct
The workload still needs RBAC roles assigned to the service principal. Federated credentials only handle authentication; authorization is separate.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A managed identity is an Azure AD identity automatically managed by Azure for Azure-hosted resources (e.g., VMs, App Services). It uses certificate-based authentication and is tied to the resource lifecycle. A federated identity credential is a configuration on an app registration that allows an external workload (e.g., GitHub Actions) to authenticate using tokens from an external OIDC provider. Managed identities are simpler for Azure resources; federated credentials are for external workloads. However, managed identities can also be configured with federated credentials (preview) to allow external workloads to use them.
Yes, you can use Azure CLI with federated credentials by logging in with `az login --service-principal -u <client-id> -t <tenant-id> --federated-token <token>`. The token is the OIDC token obtained from the external IdP. This is useful for testing or scripting. The `--federated-token` parameter tells Azure CLI to use the token as a client assertion.
The OIDC token from GitHub has a 5-minute lifetime. The exchange must happen within that window. If the token expires, the Azure AD token endpoint returns an error (invalid_grant). The workload must obtain a new OIDC token. In practice, the exchange happens immediately after the token is issued, so expiration is rare unless there is a delay in the workflow.
No, each federated credential has a specific subject. To support multiple repositories, you need to create separate federated credentials for each repository (or use a more generic subject, but that is not recommended for security). Alternatively, you can create a separate app registration for each repository.
No, workload identity federation is only supported in Azure AD (now Microsoft Entra ID), not Azure AD B2C. B2C has its own identity framework and does not support federated credentials for workloads.
Check the following: (1) The issuer URL in the federated credential matches exactly the `iss` claim in the OIDC token (no trailing slash). (2) The subject matches the `sub` claim. (3) The audience is `api://AzureADTokenExchange`. (4) The OIDC token is not expired. (5) The app registration exists and is in the same tenant. Use Azure AD sign-in logs to see the error: look for 'FederatedCredentialValidationFailure' or similar. Also, enable logging in your external IdP.
Yes, but Azure Functions typically use managed identities. If you need to authenticate from an Azure Function to an external IdP, you can use the managed identity's federated credential feature (preview). Alternatively, you can use the function's system-assigned managed identity directly without federated credentials.
You've just covered Workload Identity and Federated Credentials — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?