What Is OIDC in GitHub Actions?

OIDC lets a workflow prove its identity to a cloud provider with a short-lived token, so you do not store long-lived credentials.

Storing static cloud keys as secrets is risky. With OpenID Connect (OIDC), GitHub issues a signed identity token per run that your cloud trusts, exchanging it for temporary credentials with no stored secret.

What it is

OIDC is a standard for federated identity. GitHub acts as an identity provider, minting a JWT that describes the run; your cloud verifies it and grants short-lived access.

OIDC cloud auth

permissions:
  id-token: write
  contents: read
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123:role/ci
      aws-region: us-east-1

How it works

You grant the job id-token: write, configure a trust relationship in the cloud keyed on claims like repo and branch, and the workflow exchanges its OIDC token for temporary credentials.

Why it beats stored keys

No long-lived secret to leak or rotate.
Access is scoped to specific repos, branches, or environments.
Credentials expire automatically when the job ends.

Why it matters

OIDC is the modern, recommended way to authenticate workflows to AWS, GCP, Azure, and more. It removes a whole class of secret-leak risk from your pipelines.

Related concepts

OIDC requires the id-token permission and is an alternative to storing cloud keys as secrets; it pairs well with environments for tight trust scoping.

Key takeaways

OIDC gives workflows a short-lived identity token.
It replaces stored cloud keys with federated trust.
Grant id-token: write and scope trust by claims.