Replace long-lived cloud secrets with GitHub Actions OIDC

With OpenID Connect, a workflow job asks GitHub for a signed token, presents it to your cloud provider, and receives a short-lived access token valid for that job. You stop storing cloud keys as GitHub secrets, so there is no long-lived credential to leak, rotate or forget.

The old way and its cost

The traditional setup stores an access key in repository secrets. The key is long-lived, it sits in many places over time, and anyone who can run a workflow in the repository can try to use it. When a key leaks through a log or a compromised action, you may not know until it is abused.

GitHub's hardening guide says OIDC lets you stop storing these credentials as long-lived secrets.

How it works

Per GitHub's documentation:

1. A job requests an OIDC token from GitHub's provider. Each job gets its own JSON web token.
2. A step or action presents the token to the cloud provider as proof of workflow identity.
3. The provider checks the claims against conditions you configured on a cloud role.
4. If they match, it returns a short-lived access token, valid only for a single job.

Benefits listed by GitHub: no duplicated cloud secrets, granular control through the provider's own authorization tools, and automatic expiry.

The subject claim is your guardrail

The sub claim says where the workflow came from. GitHub's example is a repository and an environment. On the cloud side you write a trust condition that matches it.

A loose condition, such as any repository in the organization, defeats the point. Match the specific repository, and where possible the specific environment or branch.

GitHub also notes that repositories created after July 15, 2026 use an immutable subject format with owner and repository IDs, which guards against name reuse. That is not available on GitHub Enterprise Server. Check how your existing trust policies match, since the format differs.

Administrators can also add repository custom properties as claims and write policies against them instead of hard coded lists.

Setup outline

1. Create an identity provider entry in your cloud account for GitHub's token issuer.
2. Create a role with the minimum permissions the deploy needs.
3. Add a trust condition on repository and environment.
4. Grant the workflow permission to request a token. The page I fetched did not cover the exact permission name, so follow your cloud provider's GitHub guide for it.
5. Remove the old stored key, then rotate it at the provider.

Step five is the one people skip. An unused key that still works is a liability.

Limits to remember

OIDC removes a stored credential. It does not remove the need to trust the job. If a compromised step runs inside an approved job, it can request a token too. Pair it with environment reviewers and pinned third party actions.

GitHub notes custom OIDC claims are not available in AWS, so plan your conditions around the standard claims there.

The free Safeguard scan at gold.safeguard.sh/scan can show what dependencies a deploy pulls in.

Quick check

Sources

• OpenID Connect concepts
• Security hardening for GitHub Actions

Last reviewed: 19 October 2026.