CONCEPT Cited by 3 sources
OIDC identity federation¶
OIDC identity federation is the pattern of using an OpenID Connect identity provider (IdP) to issue short-lived, signed JWTs that downstream services verify and exchange for their own scoped, time-bounded credentials — without provisioning or storing long-lived secrets at the identity boundary.
In practice: workload A runs in some execution context
(GitHub Actions job, AWS Lambda, Fly.io Machine, Kubernetes
pod). Context provides A with an OIDC token whose claims
(sub, aud, iss, exp) identify the workload
cryptographically. A presents the token to service B (AWS
STS, GCP IAM, another GitHub repo, an internal API). B
validates the token against the IdP's public keys (via the
standard .well-known/openid-configuration discovery
endpoint) and issues a scoped credential tied to the claims.
Why it matters¶
The alternative is long-lived secrets — Personal Access Tokens, GitHub App private keys, AWS IAM access keys, service account JSONs — stored in the dependent system's secret store. Leakage has arbitrary blast radius: the secret is usable by anyone who exfiltrates it, for its full lifetime, from anywhere. OIDC federation replaces this with:
- Per-workflow scoping via claim-matching (
subprefix matching,repo/workflowclaims). - Time bounds (typically ≤ 1 hour, often ≤ 15 minutes).
- Auto-rotation — every job gets a fresh token.
- No credential at rest — the credential lives only in the job's runtime.
Canonical deployments¶
GitHub Actions → cloud providers¶
GitHub Actions acts as an OIDC IdP
via ACTIONS_ID_TOKEN_REQUEST_TOKEN / ...URL env vars.
Downstream:
- AWS:
sts.AssumeRoleWithWebIdentitywith an IAM Role whose trust policy accepts the GitHub IdP and matchessubclaims (patterns/oidc-role-assumption-for-cross-cloud-auth). - GCP: Workload Identity Federation.
- Azure: OIDC-federated service principals.
- PyPI: Trusted Publishing with OIDC.
GitHub Actions → GitHub itself¶
octo-sts and dd-octo-sts-action use OIDC tokens to issue scoped GitHub tokens — replacing long-lived PATs and GitHub App keys in repo secrets.
Fly.io → AWS (Fly.io self-hosted IdP)¶
oidc.fly.io/<org> is Fly's per-org IdP that issues JWTs to
Fly Machines; AWS IAM trust policies scope role assumption via
sub prefix matching. See
sources/2024-06-19-flyio-aws-without-access-keys.
OPKSSH (user SSH → cloud)¶
OPKSSH uses OIDC to tie SSH access to ephemeral, SSO-validated per-boot keys, shifting the SSH trust root from long-lived key files to an OIDC IdP.
Seen in¶
- sources/2026-03-09-datadog-when-an-ai-agent-came-knocking — Datadog cites OIDC federation as the mechanism backing systems/dd-octo-sts-action for replacing long-lived GitHub PATs.
- sources/2024-06-19-flyio-aws-without-access-keys — Fly.io-to-AWS canonical disclosure.
- sources/2025-03-25-cloudflare-opkssh-open-sourcing — SSH analogue at the human-identity layer.
Related¶
- concepts/oidc-federation-for-cloud-access — more specific cross-cloud application of the pattern.
- concepts/short-lived-credential-auth — the downstream posture this concept instantiates.
- concepts/workload-identity — the broader "what is this workload" question that OIDC federation answers cryptographically.
- systems/octo-sts, systems/dd-octo-sts-action — GitHub-specific OIDC→token brokers.
- patterns/short-lived-oidc-credentials-in-ci, patterns/oidc-role-assumption-for-cross-cloud-auth — canonical patterns.