World map

 

BM

World C3: Release & Deploy

OIDC: no long-lived keys

You will learn: how a workflow gets a short-lived cloud key for one job, instead of storing a key forever.

Checked with GitHub Actions 2026-10 on 31 Oct 2026

The problem

Tap each point on the timeline.

A key that never expires is a key waiting to leak. Tap the story. What if keys lasted one job only?

Watch

OIDC (OpenID Connect): The runner shows a visitor badge for one job. The cloud checks it and lends a key that expires when the job ends. swaps the stored key for a visitor badge. The badge works for one job, then melts. Put the steps in order.

First step at the top. Put these in order. Use the arrows, or drag.

  • The cloud lends a short-lived key
  • The job asks GitHub for an ID token
  • It shows the token to the cloud
  • The cloud checks the repo and environment
  • The key expires when the job ends

Try it

Build an OIDC deploy to AWS. No keys in secrets.

Tap blocks to add them. Put them in order.

Blocks

Your workflow

Tap a block above to start.

Workflow file .github/workflows/

name: Deploy to AWS

What runs

Nothing to run yet.

Predict

You forget id-token: write. What happens?

Check

The cloud decides whom to trust. Are these trust rules good, or do they need work?

Swipe right for good, left for needs work. Or use the buttons.

1 / 4

Trust only repo you/shop, environment production.

Check

One honest catch: Cloudflare’s Wrangler still needs an API token in CI. How should you keep it?

You did it!

You can now deploy to a cloud with no stored keys.

Go deeper (optional)

The cloud reads claims inside the badge. The subject names the repo and environment, like repo:you/shop:environment:production. Repos made after 15 July 2026 use a newer format with ids. So copy the exact rule your cloud’s docs show.

Real rep (optional): follow your cloud’s GitHub OIDC guide on a test account.