What Is OIDC? OpenID Connect Explained for Security and Identity Teams

Key Takeaways

• OIDC is an identity layer on top of OAuth 2.0. OAuth answers what an application can access, and OIDC adds a verifiable answer to who the user or workload is.
• The tokens OIDC issues are bearer tokens, meaning whoever holds one can use it, which makes token theft a primary attack path against identity systems.
• The 2023 Okta support breach showed the stakes: stolen session tokens from uploaded files let attackers hijack live sessions at five customers including BeyondTrust.
• OIDC increasingly authenticates non-human identities and AI agents, which KPMG's latest reporting says outnumber human users by 80 to 1 and depend on short-lived federated tokens.

Quick Answer: What Is OIDC?

OIDC, or OpenID Connect, is an identity layer built on top of OAuth 2.0 that lets an application verify who a user or workload is by receiving a signed ID token from a trusted authorization server.

The essentials:

• OAuth 2.0 handles authorization: what an application is allowed to access.
• OIDC adds authentication: a verifiable identity in the form of a signed ID token.
• The ID token proves identity, the access token grants resource access, and both are bearer tokens.
• Because tokens are bearer credentials, protecting and short-cycling them is the core of OIDC security.

OAuth versus OIDC at a Glance

The two are often confused because OIDC is built on OAuth. The distinction is what each one answers.

Your single sign-on, your API access, and increasingly your AI agents all rely on the same protocol family to prove identity. OAuth 2.0 grants access, and OIDC sits on top of it to verify who is making the request. The tokens these protocols issue now authenticate far more machines than people: non-human identities outnumber human users by about 80 to 1, according to KPMG's 2026 cybersecurity reporting, and most of them authenticate with tokens defined by these standards.

How Does OIDC Work?

OpenID Connect is an authentication protocol that adds an identity layer to the OAuth 2.0 framework. As the OpenID Foundation describes it, OIDC lets a client verify a user identity based on authentication performed by an authorization server, and obtain basic profile information in a standard way. OAuth on its own handles delegated access but does not define how to communicate who the user is. OIDC fills that gap.

The mechanism is a signed token. After a user authenticates, the authorization server issues an ID token, a JSON Web Token containing claims about the user and signed by the provider. The client validates the signature and the claims to trust the identity. The OpenID Connect Core specification defines this ID token and the flows that produce it, all built on the authorization mechanics of RFC 6749.

Alongside the ID token, OIDC flows can return an access token for reaching APIs and a refresh token for obtaining new tokens. Among authorization protocols, this layering is what makes OIDC the common foundation for single sign-on, federated identity, and workload authentication.

What Is the Difference Between OAuth and OIDC?

The clearest way to hold the distinction: OAuth 2.0 is about authorization, and OIDC is about authentication. OAuth answers what an application is permitted to do with a resource. OIDC answers who the user or workload actually is. They are complementary, not competing, and OIDC cannot exist without OAuth underneath it.

The confusion in the OAuth versus OIDC question usually comes from token types. OAuth issues access tokens that grant resource access but say nothing reliable about identity. OIDC adds the ID token, which is specifically about identity and is meant to be validated by the client, not passed to an API. Treating an access token as proof of identity is a common and dangerous mistake, because access tokens were never designed to carry verifiable identity claims.

Why Are OIDC Tokens a Security Concern?

OIDC and OAuth tokens are bearer tokens. A bearer token works for whoever presents it, with no further proof required, exactly like cash. That property is what makes tokens convenient and also what makes them a prime target. A stolen token grants the access of the legitimate holder, and the request looks normal in the logs.

The 2023 Okta support breach is a precise illustration. According to Okta's own root cause analysis, an attacker accessed files uploaded to the support system that contained session tokens, then used those tokens to hijack the live sessions of five customers, including BeyondTrust and Cloudflare. The entry point was a service account stored in the support system. Stolen bearer tokens turned into account takeover, and multi-factor authentication did not help because the tokens represented already-completed authentication.

This is why token theft ranks so high in identity security. Stolen credentials remain the most common initial access vector in the Verizon Data Breach Investigations Report, and the OWASP Non-Human Identity Top 10 lists insecure authentication and long-lived secrets among its leading risks. A bearer token is only as safe as the controls around its issuance, lifetime, and storage.

How Do You Secure OIDC in Practice?

Validate Tokens Properly

The most common OIDC implementation flaw is trusting a token without fully validating it. Clients must verify the signature, the issuer, the audience, and the expiry of every ID token, and must not accept a token signed for a different purpose. The Storm-0558 class of attack, where a validation gap let one key sign tokens it should not have, shows what happens when validation is incomplete. The OpenID Connect Core specification is explicit about these checks for good reason.

Keep Token Lifetimes Short

A bearer token that lives for hours is a bigger prize than one that lives for minutes. Prefer short-lived credentials and rotate refresh tokens, so a stolen token expires before it is useful. The NIST Digital Identity Guidelines treat session and token lifetime as core security parameters, not afterthoughts.

Protect Tokens in Transit and at Rest

Tokens leak when they end up in logs, browser archives, URLs, or local storage. The Okta incident began with tokens sitting inside uploaded diagnostic files. Keep tokens out of places they can be harvested, transmit them only over TLS, and strip them from any artifact that gets shared or stored.

Govern the Identities Behind the Tokens

A token is only meaningful because of the identity it represents. In token-based systems, intent-based cybersecurity means the token-holder's access is tied to the task it is executing, not just the fact that the token is valid. If that identity, often a service account or workload, is over-permissioned, a stolen token inherits all of it. Scoping the underlying identity to least privilege limits what any leaked token can reach, which is the control that bounds the damage when token protection fails.

How Does OIDC Apply to AI Authentication?

OIDC is becoming central to AI authentication. Workload identity federation, used by GitHub Actions and the major clouds, relies on OIDC tokens so a workload can exchange a short-lived, verifiable token for access instead of holding a standing secret. AI agents are adopting the same pattern: an agent authenticates with an OIDC token scoped to its task rather than a long-lived key.

This matters because AI agents are machine identities with autonomy, and they are joining a population that already outnumbers humans by 80 to 1, according to KPMG's 2026 cybersecurity reporting. As agentic AI systems proliferate, the security of their OIDC tokens, how they are issued, validated, scoped, and expired, becomes the security of the agents themselves.

How Token Security Approaches Token-Based Identity Risk

The Challenge

Identity providers issue tokens correctly, but they do not show you, across your whole environment, every non-human identity that holds OIDC and OAuth tokens, which of those identities are over-permissioned, where their tokens might be exposed, or which belong to workloads that no longer exist. That cross-environment view of token-holding identities is where risk hides.

The Approach

Token Security is built for machine identities rather than retrofitted from human IAM. The platform discovers every non-human identity across cloud, SaaS, CI/CD, identity providers, secret vaults, Kubernetes, and AI tooling, then correlates each one to the tokens and credentials it holds, its permissions, its owner, and its behavior. The model is three steps:

• Discover: a live inventory of every identity that holds OIDC and OAuth tokens, including ones outside the identity provider view.
• Understand: entitlement mapping, blast-radius analysis, and behavioral baselines, so over-scoped token-holders and anomalous token use stand out.
• Enforce: automated remediation and lifecycle governance that scopes identities down, rotates credentials, and retires those no longer in use.

The Outcome

The identities behind OIDC tokens are governed, not just trusted. The token-holding members of the 80-to-1 majority get the scoping and monitoring that limits what any stolen token can reach.

How Security Teams Put This Into Practice

Finding Where Token-Based Risk Actually Lives

You cannot protect tokens you cannot see, and token-holding identities spread far beyond the identity provider. Lemonade described getting accurate visibility into machine identity risk where other tools fell short.

"Token Security has enhanced our security by providing us accurate and relevant visibility into machine identity risks, something I have yet to see from other vendors. It's the first service I've seen that delivers on the widely-made claim of finding machine identity risk. It provides us with the right amount of detail to mitigate issues without burdening us with tens of rows of useless alerts." — Jonathan Jaffe, CISO at Lemonade

For OIDC specifically, the lesson is that visibility into the identities holding tokens, with enough detail to act, is what turns abstract token risk into a fixable list.

Turning Visibility Into Prevention

Seeing token-based risk only helps if it leads to prevention. An over-permissioned identity whose token gets stolen is a breach waiting to happen unless the access is reduced first. SVCI framed this as risk prevention through stronger identity security.

"Token helps customers bolster the management of their non-human identity security challenges, by providing increased visibility, critical risk prevention, and overall stronger security measures. Their approach surpasses all existing identity security solutions." — Al Ghous, SVCI Co-Founder and CISO

Applied to OIDC, the point is that token security is ultimately identity security. Preventing the misuse of a stolen token comes from scoping and governing the identity behind it.

Why Identity Is the Control Plane for Agentic AI

OIDC is the protocol that proves who is behind a request, and OAuth is the protocol that grants what they can reach. Together they issue the bearer tokens that now authenticate far more machines than people. Understanding OIDC means understanding that its tokens are powerful, stealable credentials, and that securing them is inseparable from securing the identities they represent.

As AI agents adopt OIDC and workload federation, the identity layer becomes the place where control is possible. An agent token is only as safe as the identity it carries and the scope that identity holds. Governing those identities, applied to the 80-to-1 majority now authenticating with these protocols, is what makes identity the control plane for agentic AI.