← Blog

OIDC Tokens: Replace Static API Tokens with Short-Lived Credentials

Storing cloud API keys in CI/CD secrets creates a problem: those credentials are long-lived, must be rotated, and can be abused if leaked. OpenID Connect (OIDC) lets a workload prove its identity and exchange that proof for short-lived credentials—without keeping a static API token in your repository.

How it works

OIDC is an identity layer built on OAuth 2.0. A CI platform such as GitHub Actions can issue a signed ID token describing the running workflow.

The cloud provider trusts that identity issuer. It validates the token’s signature and claims—typically the issuer (iss), audience (aud), and subject (sub)—then grants a temporary role or access token if the claims match its trust policy.

The flow is:

  1. A workflow requests an OIDC ID token from its CI platform.
  2. The workflow presents it to the cloud provider’s security token service.
  3. The provider validates the token and its claims.
  4. The provider returns short-lived, limited credentials.
  5. Those credentials expire automatically.

Example: GitHub Actions and AWS

Instead of saving AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as repository secrets, configure an AWS IAM OIDC identity provider and a role whose trust policy restricts which repository and branch or environment can assume it.

Then use the role in your workflow:

permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/DeployRole
      aws-region: ap-south-1

The action obtains the workflow’s OIDC token and exchanges it for temporary AWS credentials. Replace the example role ARN with your own, and pin third-party actions to a reviewed commit SHA in production.

Why this is better

  • No static cloud secret to leak: there is no permanent access key sitting in CI secrets.
  • Automatic expiry: stolen temporary credentials have a limited lifetime.
  • Narrow trust: policies can restrict access to a specific repository, branch, environment, or workflow identity.
  • Better auditability: cloud logs can identify the role and federated workload that requested access.
  • Less rotation work: you manage trust policies instead of manually rotating long-lived keys.

What OIDC does not replace

OIDC does not magically remove every API token. The target service must support federation or token exchange. For services that only accept API keys, you still need a secret-management and rotation strategy. Also, a valid OIDC token is not enough by itself: overly broad trust policies can let untrusted workflows obtain credentials.

Takeaway

For CI/CD-to-cloud authentication, prefer OIDC federation plus short-lived, least-privilege credentials over static API keys. You reduce secret sprawl, simplify rotation, and make workload identity an explicit part of your security boundary.