Lesson266 words
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. Now it exists in two places, is long-lived, and must be rotated in both.
How OIDC removes it
- You establish an OIDC trust relationship in the cloud provider, allowing specific workflows to request access tokens on behalf of a defined cloud role.
- Every run, GitHub's OIDC provider auto-generates a token — a JWT containing claims that identify the workflow, repository and environment.
- The workflow presents that token to the cloud provider as proof of identity.
- On validating the claims, the cloud provider issues a short-lived access token, available only for the duration of the job.
The documented benefits are exactly three:
| Benefit | Meaning |
|---|---|
| No cloud secrets | Nothing duplicated as a long-lived secret |
| Authentication and authorization management | Granular control via the cloud provider's own authN/authZ |
| Rotating credentials | A token valid for a single job, then automatically expired |
Claims are the authorisation surface
The token's sub claim references things like the repository and the job's environment — for example a prod environment in octo-org/octo-repo. Scoping the cloud trust to specific claims is what stops any workflow in the organisation from assuming a production role.
Azure Pipelines has the equivalent in workload identity federation service connections, with the same property: a federated credential, no stored secret.
Primary sources