What Is an OIDC Role for GitHub Actions?

An OIDC role is an IAM role whose trust policy accepts a short-lived token GitHub issues to your workflow, letting the pipeline deploy to AWS with no stored credentials.

Storing long-lived cloud keys in CI secrets is a security liability. OIDC (OpenID Connect) replaces them with federated trust: GitHub acts as an identity provider, your workflow gets a signed token describing the run, and AWS exchanges that token for temporary credentials. The result is keyless, auditable deploys.

How the token exchange works

During a workflow, GitHub mints a signed OIDC token containing claims like the repository, branch, and environment. The workflow presents it to AWS STS, which checks the token against the role trust policy and, if it matches, returns temporary credentials.

Setting up the trust

• Register GitHub as an OIDC identity provider in IAM.
• Create a role whose trust policy references that provider.
• Scope the trust to specific repos, branches, or environments via the sub claim.
• Attach a least-privilege permission policy for what the deploy needs.

What the claims let you restrict

Because the token carries the repo, ref, and environment, the trust policy can require, say, only the main branch of one repository. A leaked workflow from another repo cannot assume the role, which dramatically narrows the blast radius.

Why teams adopt it

OIDC removes the highest-value secret from CI: cloud keys. There is nothing to rotate, nothing to leak, and every assumption is logged. The same pattern works for Google Cloud (Workload Identity Federation) and Azure (federated credentials).

Role in CI/CD

In GitHub Actions you grant the workflow id-token: write permission, then use the configure-aws-credentials action with a role ARN. The action handles the token exchange and exports temporary credentials for later steps. No AWS access keys ever touch your repository secrets.

Key takeaways

• OIDC lets GitHub Actions assume an AWS role via a signed token, with no stored keys.
• The trust policy can scope access to specific repos, branches, or environments.
• The same federation pattern exists for Google Cloud and Azure.

Related guides