OpenAI: Workload Identity Federation eliminates long-lived API keys through OIDC token exchange

OpenAI announced Workload Identity Federation — a security mechanism that eliminates the need to store long-lived API keys in code or application configuration files.

How does identity token exchange work?

Workload Identity Federation relies on four components. First, a Workload Identity Provider is defined that describes a trusted external issuer with an OIDC endpoint, audience, and key verification source. Then Service Account Mapping authorizes specific attributes of the external token to create tokens for a specific OpenAI service account. In the third step, Token Exchange receives the external workload token and returns a short-lived OpenAI access token. Finally, the application uses this token as a bearer credential for API calls.

The system uses OIDC-compatible JWT tokens. Token attributes can be transformed through Common Expression Language (CEL) to derive custom matching criteria from token claims.

Which platforms and clouds are supported?

OpenAI provides dedicated integration guides for six platforms: Kubernetes (projected service account tokens), AWS (STS or EKS projected tokens), Microsoft Azure (managed identity or AKS tokens), Google Cloud (metadata server or GKE tokens), GitHub Actions (OIDC workflows), and SPIFFE (JWT-SVID standard for infrastructure).

Configuration is performed through Organization Settings > Security > Workload Identity Provider and is available to organization owners. JWKS verification supports both OIDC discovery and manually uploaded key sets. Discovery documents refresh every 600 seconds.

Why is this important for API access security?

Long-lived API keys represent a persistent security risk — once compromised, they allow unlimited access until manually revoked. Short-lived OIDC tokens automatically expire and are bound to the specific identity of the workload, significantly reducing the attack surface.

OpenAI recommends several practices: using separate service accounts per workload, separating development and production environments, precise claim matching (not just wildcards), and regular auditing of unused mappings. Mappings support wildcard matching, but only with a single trailing wildcard.

The introduction of this standard aligns OpenAI with the security practices that AWS, Google Cloud, and Azure already require from production workloads — the token exchange is based on the OAuth 2.0 Token Exchange specification (RFC 8693).