Moving From GitHub Actions Secrets to OIDC: Cloud Authentication Without Saving Credentials

If your GitHub Actions workflow deploys applications to AWS, Azure, or another cloud platform, you may be storing access keys or other credentials in GitHub repository secrets.

Although GitHub Secrets helps protect sensitive values, long-lived cloud credentials still need to be managed, rotated, and revoked. If a credential is exposed, it could allow unauthorized access to your cloud resources until the credential is disabled or expires.

OpenID Connect (OIDC) offers a more secure alternative. It allows GitHub Actions to authenticate with a supported cloud provider using a short-lived identity token instead of storing permanent cloud access keys in GitHub Secrets. <Cite refs={[“turn131672search0″,”turn131672search11”]}/>

In this guide, you’ll learn how OIDC works and how to configure GitHub Actions to access AWS without saving long-lived AWS access keys.

What Is OIDC in GitHub Actions?

OpenID Connect is an identity protocol that allows one service to verify the identity of another.

With GitHub Actions, a workflow can request an OIDC token that identifies the workflow’s execution context. Your cloud provider validates the token against a configured trust relationship and, if the conditions are satisfied, grants temporary credentials.

For example, a deployment workflow can authenticate with AWS, upload application files to Amazon S3, or deploy infrastructure without storing a permanent AWS access key in GitHub Secrets.

Why Move Away From Long-Lived Secrets?

Using permanent cloud access keys in CI/CD pipelines can create several challenges:

• Credential exposure: A leaked key may allow unauthorized access to cloud resources.
• Key rotation: Teams need to rotate credentials and update dependent workflows.
• Excessive permissions: A permanent key may have broader access than a particular deployment requires.
• Credential management: Multiple repositories and environments can make secret management complicated.

OIDC reduces dependence on long-lived cloud credentials by allowing workflows to request temporary access when needed.

However, OIDC does not remove the need for secure workflow permissions, restricted trust policies, and proper cloud IAM permissions.

How GitHub Actions OIDC Authentication Works

The process follows a simple sequence:

1. A GitHub Actions workflow starts.
2. The workflow requests an OIDC identity token.
3. The cloud provider validates the token and its claims.
4. The provider checks whether the workflow is allowed to assume a particular role or identity.
5. The workflow receives temporary cloud credentials.
6. The workflow uses those credentials to perform authorized deployment tasks.

The trust policy is important because it controls which repositories, branches, or deployment environments can request access. <Cite refs={[“turn131672search1″,”turn131672search3”]}/>

Step 1: Configure an OIDC Identity Provider in AWS

For this example, we’ll use AWS as the cloud provider.

Open the AWS IAM console and add an OpenID Connect identity provider with the following details:

• Provider URL: https://token.actions.githubusercontent.com
• Audience: sts.amazonaws.com

This establishes GitHub Actions as an identity provider that AWS can trust. <Cite refs={[“turn131672search0″,”turn131672search3”]}/>

Step 2: Create an IAM Role for GitHub Actions

Create an IAM role that your GitHub Actions workflow can assume through OIDC.

Attach only the permissions required by your deployment. For example, if your workflow uploads files to one S3 bucket, avoid granting unrestricted access to every S3 bucket in your AWS account.

Configure the role’s trust policy to restrict access to the intended repository and branch.

An illustrative trust policy for a repository named my-org/my-app and its main branch is:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:my-org/my-app:ref:refs/heads/main"
        }
      }
    }
  ]
}

Replace the example account ID, organization, repository, and branch with your actual values.

Important: GitHub subject claims can differ when a workflow uses a GitHub Environment or when immutable subject claims are enabled. Match the trust policy to the actual claims generated by your repository. Avoid broad wildcard trust policies that allow unintended workflows to assume the role. <Cite refs={[“turn131672search0″,”turn131672search1”]}/>

Step 3: Update Your GitHub Actions Workflow

Once AWS is configured, update your workflow file, typically located in .github/workflows/deploy.yml.

The following example shows how to authenticate to AWS using OIDC:

name: Deploy with OIDC

on:
  push:
    branches:
      - main

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    permissions:
      contents: read
      id-token: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v6
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubDeployRole
          aws-region: ap-south-1

      - name: Verify AWS identity
        run: aws sts get-caller-identity

Replace the example role ARN and region with your actual configuration. Before using this in production, review the action’s current documentation and pin third-party actions to verified commit SHAs according to your organization’s security policy.

The important setting is:

permissions:
  id-token: write

This permission allows the workflow to request an OIDC token. It does not independently grant permission to modify AWS resources; AWS must still validate the token and authorize the assumed role. <Cite refs={[“turn131672search0″,”turn131672search2”]}/>

Step 4: Verify the Authentication

Run the workflow from the authorized branch.

If the OIDC configuration and IAM trust policy are correct, the AWS credentials action should obtain temporary credentials, and the verification step should return the identity associated with the assumed role.

If authentication fails, check:

• The IAM OIDC provider URL and audience.
• The role ARN specified in the workflow.
• The repository, branch, or environment in the trust policy.
• The workflow’s id-token: write permission.
• The permissions attached to the IAM role.

Step 5: Remove Unnecessary Long-Lived AWS Secrets

After confirming that OIDC works, review the repository’s Actions secrets.

Remove the old AWS access key ID and secret access key only after confirming that no other workflow or integration depends on them.

If those credentials are no longer required, revoke or deactivate them in AWS IAM as appropriate. Simply deleting a GitHub secret does not invalidate the corresponding AWS credential.

Best Practices for GitHub Actions OIDC

To make your deployment pipeline more secure:

• Restrict OIDC trust to specific repositories, branches, or protected environments.
• Follow the principle of least privilege when assigning cloud permissions.
• Set id-token: write only on workflows or jobs that require OIDC.
• Use GitHub Environment protection rules for sensitive production deployments.
• Pin third-party actions to verified commit SHAs.
• Audit cloud access through AWS CloudTrail.
• Rotate or revoke old static credentials once they are no longer needed.
• Never print identity tokens or temporary credentials in workflow logs.

Final Thoughts

Moving from GitHub Actions Secrets to OIDC can simplify cloud credential management and reduce the risks associated with long-lived access keys.

Instead of keeping permanent AWS credentials in your repository settings, your workflow can establish a trusted identity and obtain temporary credentials when a deployment runs.

With a carefully restricted trust policy, least-privilege permissions, and secure workflow configuration, OIDC provides a practical way to improve CI/CD security while keeping deployments efficient.