Secretless authentication
Secrets and secretless authentication (workload identity federation / OIDC)
The problem with a stored cloud credential
Using a hardcoded secret means creating a credential in the cloud provider and duplicating it in GitHub or Azure DevOps. It is long-lived and must be protected and rotated in both places.
Here, secretless means that no long-lived cloud credential is stored in the workflow platform. The workflow still has configuration, identity metadata, permissions, and short-lived runtime tokens.
How OIDC removes it
- Establish an OIDC trust relationship in the cloud provider for the intended workflow identity.
- Grant the workflow or job
permissions: id-token: write. GitHub's OIDC provider then supplies a per-job JWT identity assertion containing workflow and repository claims. - The workflow presents that JWT to the cloud provider.
- After validating it, the cloud provider returns a distinct short-lived cloud access token valid for that job.
id-token: write only permits requesting the OIDC JWT. It does not grant write access to the repository or cloud resources; provider-side trust and roles still control cloud authorization.
| Benefit | Meaning |
|---|---|
| No cloud secrets | No long-lived cloud credential is duplicated into GitHub |
| Authentication and authorization management | The cloud provider controls trust and role authorization |
| Rotating credentials | The exchanged cloud access token is short-lived and job-scoped |
Claims are the authorization surface
Cloud trust normally combines the token's audience and actual subject. An environment appears in the subject only when the job references that environment.
Repositories created after 2026-07-15 use an immutable default subject containing owner and repository IDs. Older repositories retain the previous format unless they opt in; a rename or transfer moves them to the immutable format. Inspect the emitted subject and configure trust to match it instead of copying a name-only example.
For Azure Pipelines, use a workload-identity-federated Azure Resource Manager service connection backed by an app registration or managed identity. New eligible connections use the Microsoft Entra issuer by default. If an eligible existing connection is flagged for the deprecated Azure DevOps issuer, convert it in place rather than replacing it.
Primary sources
- https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/az-400
- https://docs.github.com/en/actions/concepts/security/openid-connect
- https://docs.github.com/en/actions/reference/security/oidc
- https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-azure
- https://learn.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops
- https://learn.microsoft.com/en-us/azure/devops/pipelines/release/configure-workload-identity?view=azure-devops