OpenID Connect adds an authentication layer to OAuth 2.0. OAuth defines how clients obtain authorization to access resources, but OAuth alone does not standardize how a client learns who authenticated. OIDC introduces an ID token and standardized identity claims to address that gap. The identity provider, called the OpenID Provider, authenticates the user and issues tokens; the application, called the relying party, validates the identity information before establishing its own session.
An ID token is a JSON Web Token containing claims such as the issuer, subject, audience, and expiration time. The issuer identifies the provider, the subject identifies the principal within that issuer, and the audience identifies the intended recipient. Applications should generally identify users by the combination of issuer and subject rather than by email address, which can change or be reassigned. An ID token establishes identity for its intended client; it is not automatically an access token for an API or a credential for cloud management operations.
For interactive applications, the authorization code flow with Proof Key for Code Exchange, or PKCE, is the usual secure choice. An authentication request includes the openid scope. The application receives an authorization code and exchanges it for tokens. Implementations must validate the token signature using trusted provider keys, check the expected issuer and audience, enforce expiration, and validate the nonce when one was included in the request. Discovery metadata and JSON Web Key Sets help applications locate endpoints and obtain signing keys, but the expected issuer must come from trusted configuration rather than arbitrary user input.
Cloud federation extends this trust model to temporary infrastructure access. For example, a deployment job can receive an OIDC token from its CI platform and exchange it for temporary role credentials instead of storing a long-lived cloud access key. In AWS, an IAM OIDC identity provider represents the trusted issuer, an IAM role trust policy controls which token identities may assume the role, and AWS Security Token Service processes AssumeRoleWithWebIdentity. The role's permissions policies then determine what the resulting session can do.
A secure deployment configuration constrains both the audience and the subject. For a GitHub Actions deployment, the audience can be sts.amazonaws.com, while the subject identifies an approved repository and branch or protected environment. Trusting every subject from the issuer would allow unrelated workloads to attempt role assumption. At scale, define provider and role configurations through infrastructure as code, separate deployment roles by account and environment, and review federation activity alongside cloud API audit records.
Workforce federation and workload federation are related but not interchangeable. AWS IAM Identity Center centralizes workforce access across accounts through permission sets and supports external identity providers through SAML 2.0, with SCIM available for provisioning. It should not be treated as a generic inbound OIDC federation endpoint simply because it also exposes OIDC-based application authorization capabilities. Choose the integration based on the identity population, protocol support, and target resource.
OIDC reduces password duplication and static-secret exposure, but it creates dependencies on provider availability, signing-key management, and correct claim validation. Short token lifetimes limit exposure, yet disabling an upstream identity does not necessarily invalidate an already established application session or issued cloud credentials immediately. Federation also does not grant least privilege automatically: token acceptance, role authorization, session duration, and downstream permissions remain separate controls.
Amazon Cognito