OIDC (OpenID Connect) is an identity layer built on top of the OAuth 2.0 authorization framework. It lets an application — called the relying party — verify who a user is by delegating authentication to a trusted identity provider (IdP), such as Google, Okta, or Microsoft Entra ID, and receiving back a signed, verifiable proof of identity called an ID token. So what is OIDC, in practical terms? It is the standard that turns "prove you have access to this resource" (OAuth's job) into "prove you are this specific person" (authentication). It runs over TLS, uses JSON Web Tokens (JWTs), and is built into nearly every modern single sign-on (SSO) flow, CI/CD pipeline authentication scheme, and workload-to-cloud trust relationship in use today, including GitHub Actions' keyless authentication to AWS and GCP.
What Is OIDC and Why Was It Created?
OIDC is a thin, standardized identity protocol that the OpenID Foundation published in 2014 to solve a problem OAuth 2.0 deliberately left unsolved: proving a user's identity. OAuth 2.0 was designed purely for delegated authorization — granting a third-party app scoped access to a resource, like letting a photo-printing service read your Google Photos without handing over your password. It was never meant to answer "who is this user," but developers kept bending it to do exactly that, using access tokens as makeshift identity proof. That workaround was insecure because OAuth access tokens are opaque-by-design, audience-ambiguous, and not guaranteed to be verifiable JWTs. OIDC closed that gap by adding a formal authentication layer on top of OAuth's authorization flow: a defined openid scope, a standardized /userinfo endpoint, discovery metadata (/.well-known/openid-configuration), and — most importantly — the ID token. A concrete example: when you click "Sign in with Google" on a SaaS product, that product isn't using raw OAuth to guess your identity; it's running an OIDC authorization code flow and validating a Google-issued ID token before creating your session.
How Is OpenID Connect Different From OAuth 2.0?
OpenID Connect extends OAuth 2.0 by adding a verifiable identity token and standardized claims, while OAuth 2.0 alone only issues access tokens for resource authorization. The distinction matters more than it sounds: an OAuth 2.0 access token tells a resource server "this bearer is allowed to call this API with this scope," but it says nothing trustworthy about who the human or workload behind that token actually is, and its format isn't guaranteed to be a parseable, signed structure. The OpenID Connect vs OAuth 2.0 comparison usually comes down to this: OAuth answers "what can you do," OIDC answers "who are you." OIDC achieves this by layering three things on top of standard OAuth grant types — the openid scope parameter, a mandatory ID token in the token response, and a /userinfo endpoint for fetching additional profile claims. In practice, almost every "Login with X" button you see is OIDC, not bare OAuth, precisely because bare OAuth was never built to make identity assertions. A real-world consequence of confusing the two: several early-2010s breaches traced back to applications treating a Facebook OAuth access token as proof of login, which allowed attackers to replay tokens issued for unrelated apps and impersonate users — the exact failure mode OIDC's audience-bound ID tokens were designed to prevent.
What Is an OIDC ID Token and What Does It Contain?
An OIDC ID token is a signed JSON Web Token that serves as cryptographic proof that a specific user authenticated with the identity provider at a specific time. Unlike an OAuth access token, the ID token is meant to be parsed and validated directly by the relying party, not sent to a resource server. Its payload carries standardized claims: iss (the issuer, e.g., https://accounts.google.com), sub (a stable, unique subject identifier for the user), aud (the client ID the token is intended for), exp and iat (expiry and issued-at timestamps), and nonce (a value that binds the token to a specific authentication request to prevent replay). The token is signed with the IdP's private key, and relying parties fetch the corresponding public key from the IdP's JWKS endpoint to verify the signature before trusting anything inside it. Concretely: when an engineer authenticates to a GitHub Actions workflow that needs AWS credentials, GitHub's OIDC provider issues an ID token with claims like repository, ref, and workflow, and AWS STS validates that signed token against GitHub's published keys before issuing temporary credentials — no long-lived AWS secret ever has to exist in the repository.
How Does OIDC Enable Federated Identity Across Systems?
OIDC enables federated identity by letting one trusted identity provider authenticate users or workloads on behalf of many independent relying parties, so no individual application has to store or manage credentials itself. This is what allows a single Okta or Azure AD login to grant access across dozens of unrelated SaaS tools, and it's the same underlying mechanism that lets a CI/CD job in one cloud account authenticate into a completely separate cloud provider without a shared secret. OIDC federated identity works because trust is established out-of-band, ahead of time: the relying party registers the IdP's issuer URL and fetches its signing keys and metadata once, and from then on any ID token bearing that issuer, a valid signature, and a matching audience is trustworthy — regardless of which system generated it. A concrete example is GitHub Actions' OIDC integration with AWS, Azure, and GCP: instead of storing static cloud credentials as GitHub secrets, teams configure a federated trust relationship where the cloud provider accepts short-lived, workflow-scoped ID tokens issued by GitHub's OIDC provider (token.actions.githubusercontent.com). This eliminates an entire class of supply chain risk — leaked long-lived cloud keys sitting in CI secret stores — because there's no static credential to steal in the first place.
What Is OIDC Token Exchange and When Is It Used?
OIDC token exchange is the process defined in RFC 8693 that lets one party trade a token it holds — often an ID token or access token from one trust domain — for a new token scoped to a different audience, service, or trust boundary, without re-running a full interactive login. It's used heavily in service-to-service and multi-hop delegation scenarios where a human isn't present to click "sign in" at every step. Consider a microservices pipeline: a CI job authenticates once via OIDC to get a short-lived token from GitHub's provider, then exchanges that token with a cloud identity broker for a narrower, service-specific credential that only has permission to push to one specific artifact registry. OIDC token exchange is also central to workload identity federation patterns in Kubernetes, where a pod's projected service account token (itself an OIDC-compliant JWT) gets exchanged for cloud IAM credentials scoped to exactly that pod's namespace and service account — critical for enforcing least privilege in build and deployment infrastructure rather than handing every workload a broad, standing credential.
How Safeguard Helps
Safeguard secures the software supply chain precisely where OIDC trust relationships live: CI/CD pipelines, build systems, and the identity federation configurations that grant workloads access to cloud resources and package registries. Because OIDC's security guarantees depend entirely on correct configuration — proper audience restriction, issuer validation, short token lifetimes, and tightly scoped trust policies — a single misconfigured federated trust (an overly broad sub claim match, a missing audience check, or a wildcarded repository condition) can let an attacker mint valid-looking tokens and walk straight into cloud infrastructure. Safeguard continuously inventories where OIDC federation is configured across your CI/CD providers and cloud accounts, flags overly permissive trust policies before they're exploited, and monitors for anomalous token exchange patterns that suggest credential misuse or privilege escalation. For teams that have already replaced static secrets with OIDC-based authentication — the right move — Safeguard verifies that the replacement was actually done safely, closing the gap between adopting a stronger identity standard and configuring it correctly at scale.