Azure Learning

workload-identity-federation

Properties2
tagsidentity, security, federation, service-connections
aliasesworkload identity, federated credential, OIDC federation, token federation

2 min read

Workload identity federation

What it is

Workload identity federation lets a workload (a CI pipeline, container, or app) authenticate to a cloud — here Microsoft Entra ID / Azure — by exchanging a token it already holds (an OIDC token from GitHub, another cloud, or an identity provider) for a cloud access token. It replaces storing a long-lived service-principal secret with a short-lived, scoped, per-run credential.

Why it exists

Classic service principals authenticate with client id + client secret. Secrets end up in repos or secret-stores, get leaked, expire, and must be rotated. A federated identity lets a pipeline ask the issuer for a token and trade it for a short-lived Azure-scoped token — no static secret to store, leak, or rotate.

Key ideas

  • Federated credential — a rule on a service principal saying “accept this issuer’s tokens when these claims match” (e.g. sub = the GitHub repo, ref/aud = a target branch/job).
  • OIDC federation — the common CI case: the issuer (GitHub Actions, Azure Pipelines, etc.) mints an OpenID Connect token the workload presents to Microsoft Entra ID.
  • Exchange — issuer issues token → workload presents it to the identity as proof → Entra ID checks signature + claims → returns an Azure access token bound to the identity’s RBAC roles.
  • Short-lived & scoped — the cloud token is minimal-scope and expires quickly, so a leak has low blast radius.

How it fits

[CI run] → [issuer mints OIDC token] → [present to workload identity] → [Entra ID verifies claim → issues scoped token] → [deployment action]

It is the secure substrate for service connections and deployment-automation in Azure Pipelines / GitHub Actions.

Exam notes

  • Differentiator vs classic service principal: no stored long-lived secret — the federated identity exchanges a short-lived issuer token.
  • vs managed identity (see service-principal): managed identities are for Azure-resident workloads; workload identity federation lets external issuers (GitHub, third-party IdPs) authenticate.
  • It powers OIDC federation for CI/CD without placing PATs/client-secrets in Actions secrets.

service-principal · entraid · azure-pipelines · github-actions · key-vault · deployment-automation

📘 Source: Microsoft Learn — Workload identities overview · GitHub Docs — OIDC hardening

Graph View

Backlinks