Logging in Without a Password

• It leaks. Anything pasted into a settings box can be pasted somewhere else — a log, a screenshot, a support ticket.
• It expires, noisily. Client secrets have expiry dates, and the first sign is usually a broken deployment at an inconvenient moment.
• It doesn't know who's using it. A secret authenticates whoever holds it, whether that's your workflow, a fork, or someone who copied it.

GitHub already knows, with certainty, which repository, branch, and environment a run belongs to. OIDC lets it issue a signed token stating those facts, valid for minutes. Azure verifies the signature, checks the statement against a rule you configured, and hands back a short-lived access token. Nothing durable is ever stored on the GitHub side — only non-secret identifiers.

1. The job declares permissions: id-token: write, which allows it to request a token describing itself.
2. azure/login asks GitHub for that token. GitHub signs a statement including an issuer (token.actions.githubusercontent.com), an audience (api://AzureADTokenExchange), and a subject describing the exact repository and environment.
3. It presents that token to Entra ID along with the AZURE_CLIENT_ID of a user-assigned managed identity.
4. Entra ID looks up the federated identity credential attached to that identity and checks whether the issuer, audience, and subject all match. If they do, it returns a normal, short-lived Azure access token.
5. Subsequent az commands use that token. What they're permitted to do is decided entirely by the role assignments on that identity.

This project creates two GitHub-facing identities with different powers: one for deploying applications, trusted for the Development environment, and one for running Terraform, trusted for the Terraform environment. The infrastructure identity is far more privileged, which is exactly why it isn't the one used by routine deploys.

There's a third identity type in play too — each Web App's own system-assigned identity, which it uses to pull images from the registry. No GitHub involvement at all.

Those numeric suffixes are GitHub's internal owner and repository IDs. They don't change when an account or repository is renamed, so the trust relationship survives a rename — and can't be hijacked by someone later claiming an abandoned name.

Because :environment:Development is inside the subject, a job that doesn't declare environment: Development produces a different subject and is refused. Deleting the environment: key from a workflow doesn't quietly lower security — it stops the login working at all.

Terraform builds this string in main.tf, and the manual OIDC script constructs the same value, with an override parameter for repositories whose subject differs.

az acr build doesn't build locally and push. It uploads your source to Azure and asks the registry's build service to run the Dockerfile — which are management operations, not image push operations. So the data-plane roles that sound right (AcrPush) don't cover it, and the failure is a 403 naming the exact missing action: Microsoft.ContainerRegistry/registries/listBuildSourceUploadUrl/action.

Read the action name in an AuthorizationFailed message — it tells you precisely what's missing, which is far faster than guessing at roles.

• Each Web App's system identity — AcrPull on the registry. Just enough to start its own container.
• The GitHub deployment identity — Website Contributor on both Web Apps (to configure and restart them) and Contributor on the registry (to build and push).
• The Terraform identity — subscription Contributor, plus a tightly conditioned RBAC administrator role, plus write access to the state container.

Every one of those is scoped as narrowly as the task allows. The registry Contributor grant, for instance, is scoped to the single registry resource — not the resource group, and not the subscription.

The Terraform identity holds Role Based Access Control Administrator, but the attached condition permits creating or deleting a role assignment only when the role being granted is Website Contributor or Contributor, and only when the recipient is a service principal. Attempting anything else — granting Owner, for example — is refused by Azure itself, not by convention.

The condition restricts which role may be granted, not at what scope. Because the administrator role is held at subscription level, the Terraform identity could grant Contributor to a service principal anywhere in the subscription — not only on the container registry. That's an accepted trade-off for a teaching subscription; a production setup would narrow the scope as well.

Changing this condition requires applying the bootstrap module locally with an elevated account. The CI pipeline deliberately cannot modify its own guardrail — which is the entire point of keeping bootstrap in a separate state.