OpenID Connect (OIDC) lets a GitHub Actions deployment workflow request a short-lived access token from its cloud provider instead of presenting a long-lived cloud credential copied into GitHub secrets. It relies on a trust relationship between the provider and the repository that runs the workflow. section 9.3.2 section 9.3.3
When the workflow runs, it authenticates using execution context such as its organization, repository, workflow, or branch. After the OIDC handshake, the workflow exchanges its OIDC token, typically a JWT, for credentials that can perform the deployment. This removes the recurring operational risk of expired, rotated, or duplicated deployment secrets. section 9.3.3 section 9.3.2
Enable OIDC for a deployment workflow in three parts:
- Create a provider-side trust relationship that identifies the GitHub repository allowed to access the target cloud resources. section 9.3.3
- Grant id-token: write at workflow or job scope so the workflow can complete the OIDC handshake and request its JWT. section 9.3.3
- Use the cloud provider’s official authentication action to exchange the OIDC token for a cloud access token, then run deployment commands. section 9.3.3
permissions: id-token: write
The required permission may be placed at workflow or job level; give only the scope needed by the deployment. section 9.3.3
AWS deployment workflow
An AWS workflow grants id-token: write, checks out the repository, and uses aws-actions/configure-aws-credentials to assume a configured role before copying index.html to an S3 bucket. The role trust relationship is established outside the workflow YAML. section 9.3.3
OIDC support is required on the cloud-provider side; supported providers include AWS, Azure, Google Cloud Platform, and HashiCorp Vault. Configure trust narrowly: allowing every GitHub repository to deploy to cloud resources creates unnecessary exposure. For cloud deployments, OIDC is presented as the safer alternative to token-based authentication. section 9.3.3 section 9.4
