{"id":7871,"date":"2026-02-24T10:36:22","date_gmt":"2026-02-24T09:36:22","guid":{"rendered":"https:\/\/blog.redbaronofazure.com\/?p=7871"},"modified":"2026-03-05T16:03:40","modified_gmt":"2026-03-05T15:03:40","slug":"entra-workload-identity-federation","status":"publish","type":"post","link":"https:\/\/blog.redbaronofazure.com\/?p=7871","title":{"rendered":"Entra Workload Identity Federation"},"content":{"rendered":"\n

Scenarios for Entra Workload Identity Federation<\/a> includes Github Actions or apps running in Google Cloud (GCP) or AWS or other computing platforms. The traditional way of configuring authentication between those platforms and Entra would be to share an application client id and secret, or certificate, so that the external apps can authenticate with Entra. This works well but comes with the tax on lifecycle management where you have to periodically share new client secrets or certificates with the external party as they expire overtime.<\/p>\n\n\n\n

Token Exchange<\/h2>\n\n\n\n

Entra Workload Identity Federation is a new and simpler way of solving this identity integration. Via trusting an external identity provider (IDP), such as GCP, AWS or any OIDC provider, Entra can accept an access token from these IDPs and exchange it for an Entra access token. The benefit of token exchange is that a) the external app must first authenticate with its IDP to get an access token to give Entra, and b) Entra does not have to share client secrets or certificates and do the lifecycle management of them. The possible risk with this federation is that you now trust an external identity provider to do the right thing in keeping secure. However, sharing client secret or certificate, you took the same risk in trusting that the external party kept them secure.<\/p>\n\n\n\n

Entra configuration<\/h2>\n\n\n\n

You configure Workload Identity Federation on an App registration. This makes sense as the external app calls the Entra oauth2\/v2.0\/token<\/a> endpoint using the client_credentials<\/a> grant_type flow, passing the client_id of the Entra application.<\/p>\n\n\n\n

In the \u201cCertificates & Secrets\u201d blade, there is a tab named \u201cFederated credentials\u201d. When you click \u201c+Add credential\u201d, you are presented with a drop-down of preselected federation scenarios, like Github Actions, Kubernetes, etc. For OIDC identity providers, like GCP, AWS and others, you choose \u201cOther issuer\u201d.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

To accept an access token from the other IDP, you need to specify:<\/p>\n\n\n\n