Workload identity federation and OIDC: issuer, audience and subject
Replace static automation credentials with a scoped OIDC trust relationship. Validate issuer, audience and subject, and separate token exchange from the permissions granted afterward.
TL;DR: Federation lets a workload exchange a trusted identity assertion for bounded access without storing a long-lived cloud key. The security decision lives in the trust policy: validate the issuer, intended audience and permitted workload identity before granting a narrowly scoped role.
Token exchange has two authorization questions
First, may this external identity obtain credentials for the requested role? Second, what may those credentials do? A strict resource policy does not repair a trust policy that lets an unintended repository assume the role, and a strict trust policy does not make administrator permissions minimal.
With OpenID Connect, an issuer signs a token containing claims about the workload. The relying system validates the token and configured trust conditions, then may issue its own temporary credentials. Signature verification is necessary but insufficient: a correctly signed token can still be intended for a different audience or an unapproved workload.
GitHub's OIDC documentation describes workflow identity and short-lived cloud access. Providers differ in supported claims and policy syntax; test the actual exchange rather than copying another provider's trust configuration.
Identify what each condition protects
| Condition | Security question | Example mistake |
|---|---|---|
| Issuer | Which identity system do we trust? | Accepting tokens from an unintended tenant |
| Audience | Was this token intended for this relying party? | Reusing a token meant for another service |
| Subject and supported claims | Which repository, environment or workload is allowed? | Trusting every branch in an organization |
| Token validity | Is the assertion currently acceptable? | Ignoring expiry or broken clock handling |
| Assumed-role permissions | Which resources and actions may follow? | Granting broad administration for one deployment |
Claims are meaningful only within the issuer's documented semantics. A repository name embedded in an arbitrary untrusted string is not equivalent to a verified workload identity.
Worked boundary: production deployment from one repository
Suppose an organization wants one release workflow to update a production service. The workflow should obtain temporary credentials only through the approved repository and protected deployment environment, with the cloud role limited to the required service operations.
Configure the trust conditions using the issuer's actual subject format. Environment-based subjects can differ from branch-based subjects. Also protect the environment and workflow: a trust condition naming an environment is useful only if untrusted changes cannot freely execute inside it with privileged approval bypassed.
GitHub's AWS OIDC guide documents provider-specific audience and subject constraints. Verify supported claim matching rather than assuming every token claim can be referenced in every cloud policy.
Test one allowed job and several denied cases: another repository, an unapproved branch or environment, and a token with the wrong audience. A successful production exchange proves the positive path; denied tests prove the boundary that justified removing static keys.
The example is a trust design, not a ready-to-apply policy. Account identifiers, subject formats, environment protection and exact deployment actions must come from the target environment.
Short lifetime changes exposure, not authority
Temporary credentials reduce the useful lifetime of a stolen credential, but an attacker can still act during that lifetime. Keep permissions narrow and avoid logging tokens or exporting them into artifacts. Separate build jobs processing untrusted input from jobs able to obtain deployment credentials. In push and pull deployment designs, trace which actor actually holds target authority before assigning the federated role.
Revoking future exchanges may not invalidate credentials already issued. Incident response must account for the provider's credential lifetime and revocation behavior, then inspect activity during the exposure window. Secrets management still applies to sensitive tokens and the credentials obtained from them.
For Kubernetes, a service-account identity can participate in a supported federation design. The cloud trust relationship remains separate from Kubernetes RBAC. Permission to read a Kubernetes object does not automatically grant permission to write a cloud bucket.
When the exchanged credential is an API token, review OAuth access tokens and scopes. Its worked example separates a valid token from authority to call the intended resource and access a particular object.
Diagnose failed exchanges without broadening trust
Compare the requested role, issuer configuration, token audience and subject with the expected policy. Inspect sanitized claims through approved tooling without pasting a live bearer token into a public decoder. Check clock and expiry errors separately from permission denials after successful exchange.
Does a signed token prove this job may deploy? No. It proves the issuer made the assertion, subject to successful validation. Trust conditions and resource authorization still decide deployment access.
Should a failed exchange be fixed by allowing every subject? No. Find the precise claim mismatch and the intended workflow identity. A wildcard can turn a configuration error into a production access vulnerability.