Actions → Azure with OIDC

Here is how most teams first connect a pipeline to Azure, and how many still do. Create a service principal — the Class Nine robot account. Generate a client secret for it. Grant it Contributor on the subscription. Paste the secret into GitHub. Done in ten minutes, and it works. Now count what you have actually built: a permanent credential with the power to create and destroy most of your Azure estate, sitting in a third-party system, readable by every workflow in the repository, copied — be honest — into a teammate's password manager "just in case", and stamped with an expiry date that will surprise you at the worst possible moment.¹

Every property of that arrangement ages badly. The secret does not expire when the project pauses; it waits. Rotation is a calendar reminder somebody snoozes, and the day it finally expires the deploy fails at release time. Anyone who can edit a workflow can, per Class Twenty-Two's Lab 2, exfiltrate the value past masking with one line of encoding. And when a security review asks the simple question — who has these keys, and where have they been? — the honest answer is a shrug. The problem is not carelessness. The problem is the design: a long-lived secret, stored outside your tenant, whose blast radius is your subscription. What this class replaces is not a bad habit but a bad architecture.

OIDC federation

An arrangement where Entra ID is configured to trust tokens issued by GitHub's identity provider — so a workflow run proves its identity with a short-lived, signed token minted for that run, exchanges it for Azure access, and stores no credential anywhere.

OpenID Connect turns the problem inside out. Instead of the workflow holding a credential, the workflow is the credential: GitHub's identity provider signs a statement about the run — this repository, this branch, this environment — and Entra ID, which you have configured to trust such statements, exchanges it for a short-lived Azure token. Five steps, all inside one job, nothing stored before and nothing left after:

1 · The run asks

The job requests an OIDC token from GitHub's identity provider — allowed because the workflow declares permissions: id-token: write.

2 · GitHub signs

GitHub mints a signed JWT describing the run: which repository, which branch or environment, which event. This is the subject claim — the run's identity papers.

3 · Entra checks

The token goes to Entra ID, which checks it against the federated credential on your app registration: right issuer, right subject, right audience. No match, no entry.

4 · Entra issues

On a match, Entra returns a short-lived access token for the service principal — valid for this job, then gone.

5 · The job works

The azure/login action holds that token; every az command in the job runs with exactly the RBAC the principal was granted in Class Eight fashion.

Sit with what changed. There is no secret to leak, so Class Twenty-Two's echo-and-base64 attack retrieves nothing. There is no expiry cliff, because nothing is stored long enough to expire. Rotation is not a chore that gets skipped; it is the design — every job gets a fresh token and every token dies with its job. And the security review question flips from unanswerable to trivial: the trust relationship is a configuration object in your tenant, inspectable, auditable, and revocable in one delete.

The setup is three Azure-side objects and one workflow block. On the Azure side: an app registration (the Class Nine service principal), a federated credential attached to it, and an RBAC role assignment scoped as tightly as Class Eight taught. The federated credential is small enough to read in full:

# the trust object on the app registration
Issuer:   https://token.actions.githubusercontent.com
Subject:  repo:campux/campux-platform:environment:production
Audience: api://AzureADTokenExchange

The subject is where all the security lives. It is a filter over which runs may become this principal: repo:ORG/REPO:environment:NAME admits only jobs running in that environment — which means only jobs that have passed that environment's protection rules; repo:ORG/REPO:ref:refs/heads/main admits only runs on the main branch; repo:ORG/REPO:pull_request admits any pull request event, which is almost never what production should accept. Write the subject as narrowly as the job allows, because everything the token can do, anyone who can satisfy the subject can do. The workflow side is four lines and one action:

# deploy.yml (excerpt) — note what is absent: any secret value
permissions:
  id-token: write
  contents: read

steps:
  - uses: azure/login@v2
    with:
      client-id: ${{ vars.AZURE_CLIENT_ID }}
      tenant-id: ${{ vars.AZURE_TENANT_ID }}
      subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

Look closely at those three values: a client id, a tenant id, a subscription id. All three are identifiers, not credentials — knowing them grants nothing, which is why they can live in plain vars rather than secrets.² The thing that grants access is the signed token minted at run time, and no line of this file contains it. This is the first deploy pipeline you have seen where a full leak of the repository — code, workflow, variables, logs — hands an attacker nothing they can log in with.

OIDC answers "how does the machine prove who it is?" One question remains: who decided this deploy should happen at all? That is what Class Twenty-Two's environments were built for, and OIDC snaps into them precisely. Give the production environment a required-reviewers rule, and point production's federated credential at environment:production. Now trace what a deploy to production requires: the job must declare environment: production; declaring it stops the job until a named human approves; only after approval does the run carry the environment:production subject; and only that subject satisfies the federated credential that Entra checks.

Nothing stored, nothing to steal.

The gate and the key are the same object. A compromised workflow on a feature branch cannot reach production's principal, because its token's subject says ref:refs/heads/feature-x and Entra shrugs. An impatient engineer cannot skip the approval, because skipping the environment means never earning the subject that unlatches the credential. Compare that with the old way, where the client secret worked from any branch, any fork with access, any laptop, at any hour — and the approval step was a custom in front of a door that was never actually locked. With OIDC federation the politeness is the lock; there is no path around the gate because the gate is what mints the key.

Step back and see the arc, because interviewers who probe this topic are really probing whether you see it. Class Nine drew the line: humans get accounts, machines get identities, and the best machine identity is one with no credential to manage — that was managed identity, and it worked only for things running inside Azure. A GitHub runner lives outside, so for five classes the question hung open: what about the machine that is not ours?

OIDC federation is the same idea stretched across an organisational boundary. Managed identity works because Azure vouches for its own compute; federation works because Entra is told, precisely and revocably, to accept GitHub's vouching for a specific repository, branch, or environment. Same principle — trade stored credentials for attested identity — new trust anchor. And the pattern is bigger than this class: the same federated-credential mechanism connects Kubernetes workloads, other clouds, and other CI systems to Entra without a stored key.³ When an interviewer asks "how does your pipeline authenticate?", the strong answer walks the Figure 13 handshake and then names the general rule. The weak answer says "we have a secret for that" — and now you know exactly what follows from it: an unrotated key, an unanswerable audit, and a door that was never really locked.