Actions → Azure with OIDC

One way to connect GitHub Actions to Azure is to create an app registration and service principal, generate a client secret, and store that secret in GitHub. The secret is a reusable credential. If the app has broad Azure RBAC permissions, anyone who obtains the secret may use those permissions until the credential expires or is revoked. Scope the role narrowly either way.¹

A stored secret needs protection, rotation, and eventual revocation. A workflow that can access it must be reviewed as privileged code; log masking is only a backstop. OIDC federation removes this long-lived client secret from GitHub. It does not remove the need to protect workflow changes, limit Azure roles, or avoid printing the short-lived tokens issued during a run.

OIDC federation

A trust relationship in Microsoft Entra ID that accepts a signed GitHub OIDC token with matching issuer, subject, and audience. The workflow exchanges that token for short-lived Azure access without a stored client secret.

With OpenID Connect, the job requests a signed identity token from GitHub instead of reading a stored client secret. Entra checks that token against the trust you configured and may issue a short-lived Azure access token. The workflow still handles live tokens while it runs, so keep them out of logs. Follow the five steps:

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. The token remains usable until it expires, so the job must not disclose it.

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.

The durable client secret is gone. Each authorized job requests fresh, short-lived tokens, while the federated credential records which GitHub subject Entra will trust. You can inspect and revoke that trust. A token accidentally exposed during a run can still be used until it expires, and a workflow that can request tokens still needs review.

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 one part of the authorization boundary. A branch subject such as repo:ORG/REPO:ref:refs/heads/main matches a job on main that does not declare an environment. An environment subject such as repo:ORG/REPO:environment:production matches jobs targeting that environment; it does not also prove they came from main. Restrict the environment to the intended deployment branches, configure reviewers where supported, and grant the Azure identity only the RBAC it needs. A broad repo:ORG/REPO:pull_request subject is unsuitable for production. The workflow requests a token with:

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

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

The client, tenant, and subscription IDs identify the target; they do not authenticate on their own.² The Azure Login action recommends storing them as GitHub secrets, as shown. This design removes a reusable client secret, but do not assume a leaked workflow log is harmless: a run can still hold short-lived tokens, and a malicious workflow with matching OIDC claims could request new ones.

AZURE_CLIENT_ID        11111111-aaaa-4bbb-8ccc-000000000001   # the app registration's Application (client) ID
AZURE_TENANT_ID        22222222-aaaa-4bbb-8ccc-000000000002   # your Microsoft Entra directory
AZURE_SUBSCRIPTION_ID  33333333-aaaa-4bbb-8ccc-000000000003   # where its Reader role is assigned
Federated credential subject:  repo:campux/campux-platform:ref:refs/heads/main

OIDC answers how a job proves its identity. GitHub environment rules decide which jobs may target a named deployment environment. Where required reviewers are supported, configure them for production, and restrict deployment branches to main. A job declaring environment: production waits for those configured rules before it runs; its OIDC subject then names the environment. Entra matches that subject against the production federated credential. The environment name alone neither demands approval nor limits the branch.

No long-lived client secret in GitHub.

An environment subject does not include the branch by default. A feature-branch workflow that is allowed to target production can present the same environment subject after passing any configured rules. Use the environment's branch restrictions and approval rules together with a narrowly scoped Azure role. Protect workflow changes too: a trusted run with id-token: write can request a new OIDC token.

GitHub normally withholds repository secrets and limits the repository token on forked pull requests. Do not make that the only Azure control. A branch-scoped credential for main will not match a pull-request subject, regardless of whether the PR comes from a fork or the same repository. Be especially careful with pull_request_target: it runs in the base repository context, and checking out and executing untrusted PR code there can expose powerful credentials. Review the event, subject, environment rules, and Azure RBAC together.

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 1 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.