If you've worked with OAuth 2.0, you've almost certainly encountered OpenID Connect. It may have been mentioned in passing, or perhaps bundled into "login" features discussions, and sometimes treated as an optional extra. That can make it unclear where OAuth ends and where OpenID Connect begins, and why both are often used together.
OpenID Connect (often abbreviated as OIDC) exists to solve a specific problem that OAuth intentionally does not solve: standardized user authentication. While OAuth provides a framework for delegated authorization, meaning it determines what a client application is allowed to access, OIDC adds a standardized method for identifying and authenticating users.
This article explains what OIDC is, why it exists, and how it helps developers build modern applications without reinventing authentication. The goal is understanding OIDC and when it makes sense to use it, rather than how to implement it. Throughout this article, all mentions of OAuth refer to OAuth 2.0.
What Is OpenID Connect?
OIDC is an open and standardized identity layer built on top of OAuth 2.0. It defines how applications can authenticate users and receive verified information about their identity in a consistent and interoperable way.
Rather than replacing OAuth, OIDC extends it. It uses OAuth's existing flows and token issuance mechanisms, and adds a small but critical set of identity-specific conventions. These conventions allow applications to answer questions such as "Who is the user?" and "How do I know that an identity can be trusted?" OAuth alone does not formally address these questions.
In practice, OIDC builds on OAuth by standardizing how users authenticate and how applications receive verified identity information, replacing a variety of ad-hoc approaches that previously filled the authentication gap in OAuth-based login flows.
OIDC enables applications to authenticate users without handling credentials directly, while staying within the OAuth model.
What OpenID Connect Standardizes
At a high level, OIDC adds a well-defined authentication layer on top of OAuth. More importantly for developers, it standardizes several areas that were previously left to interpretation when OAuth-based flows were used for login.
First, OIDC defines a consistent way to represent the result of authenticating a user. Rather than inferring user identity indirectly from authorization tokens or custom API calls, applications receive a clearly defined authentication result that represents who the user is and how they authenticated.
OIDC also standardizes how core identity information is expressed and validated. User attributes such as subject identifiers and profile claims follow agreed-upon formats, which allow applications to rely on them without inventing proprietary means to do so, or hardcoding identity logic in application code.
Another important area of standardization is trust and verification. OIDC specifies how clients can verify that authentication information was issued by a trusted provider and has not been tampered with. This removes the need for custom validation rules that often vary between implementations.
Finally, OIDC defines discovery and metadata conventions that allow a client and an identity provider (IdP) to integrate predictably, typically via a well-known discovery document that advertises endpoints, capabilities, and keys. This is instead of relying on hard-coded configuration or documentation-specific behavior.
Taken together, these standardizations reduce guesswork, limit the need for custom authentication logic, and make authentication behavior easier to understand.
How OpenID Connect Helps Developers in Practice
By standardizing the core pieces of authentication, OIDC changes how developers approach login and identity-related concerns in real applications. Rather than designing authentication functionality from scratch, developers can focus on how authentication fits into their systems.
In practice, this leads to many benefits for developers:
- Single sign-on (SSO) becomes standard rather than custom: Because authentication results and identity information follow a common format, users can authenticate once with an IdP and interact with multiple applications without repeated sign-ins. Developers no longer need to coordinate custom session-sharing mechanisms or reconcile different interpretations of "logged in."
- Identity behaves more consistently across application types: Whether building a traditional server-based web app, a single-page application (SPA), or a mobile client, developers work with identity in a uniform way. This reduces custom coding and makes it easier to understand authentication across different platforms.
- Less custom authentication infrastructure is required: With authentication behavior clearly defined, applications can delegate credential handling, authentication flows, and identity verification to an OIDC–compliant IdP. This reduces the need to build and maintain custom login systems and lowers the risk of subtle security mistakes.
- Applications remain loosely coupled to IdPs: Because OIDC defines shared expectations between clients and providers, applications are less dependent on vendor-specific behavior. This makes it easier to integrate identity services that are self-hosted, hosted by a third party, or even hosted by enterprise providers, all without reinventing the wheel.
Identity vs. Access: How OpenID Connect Separates the Two
One of OIDC's most important contributions is its clear separation between identity and access. This is a distinction that's easy to blur in OAuth-based systems if not made explicit.
In an OIDC flow, identity is conveyed through an ID token, typically a JSON Web Token that contains claims about the authentication of a specific end-user.
Access to APIs and protected resources, by contrast, is governed by access tokens which describe the permissions granted to a client on behalf of the user. Although both token types are issued as part of OAuth-based exchanges, they serve fundamentally different purposes and are intended to be used in different contexts.
- An ID token answers questions such as: Who is the user? How was that identity authenticated?
- An access token answers a different question: What actions is this client authorized to perform?
Keeping these concerns separate reduces a common source of confusion and misuse: inferring identity from API access tokens or overloading access control with authentication identity information.
By formalizing this distinction, OIDC allows applications to deal with authentication and authorization independently, even though the two often appear together in real-world systems.
What OpenID Connect Is Not
Understanding OIDC also means understanding its boundaries. Many of the problems OIDC was designed to solve came from applying OAuth in ways it was never intended to support. Clarifying what OIDC does not do helps prevent similar confusion and keeps authentication architectures focused and maintainable.
OIDC is not a replacement for OAuth. OAuth remains the mechanism for authorization and delegated access, particularly when protecting APIs. OIDC builds on OAuth rather than replacing it, adding a standardized way to represent authenticated user identity alongside OAuth.
OIDC is not an API authorization system by itself. While it provides reliable identity information, it does not define what a client is allowed to do with protected resources. Authorization decisions — such as which APIs can be accessed and under what conditions — remain the responsibility of OAuth scopes, policies, or application-specific access control logic.
OIDC is not required for machine-to-machine or service-to-service communication. OIDC is defined around authenticating end-users, so in scenarios with only applications and no users, OAuth 2.0 client credentials and related patterns are typically sufficient.
Finally, OIDC is not a vendor product or an identity store. It is a standard that defines how authentication information is exchanged and verified. IdPs, authorization servers, and platforms implement OIDC, but OIDC itself does not manage users, credentials, or directories.
Keeping within these boundaries leads to systems that behave correctly and are simpler, clearer, and easier to manage over time.
Final Thoughts
OIDC has become a leading standard for user authentication because it addresses a long-standing gap in OAuth-based systems: identifying users without treating authorization as a login system.
By building on OAuth and defining a standardized identity layer, OIDC provides developers a consistent way to authenticate users and obtain verified identity information across various applications and platforms. Instead of relying on ad-hoc conventions, applications can depend on standardized authentication results, identity claims, and verification behavior.
Just as importantly, OIDC makes its boundaries clear. It complements OAuth and focuses on authentication rather than authorization or access control. Understanding where OpenID Connect fits — and where it doesn't — helps teams design systems that are simpler, more secure, and easier to maintain over time.
Standards-compliant identity platforms, such as Duende Software's IdentityServer, implement OAuth 2.0 authorization server and OpenID Provider roles together, allowing teams to use proven standards instead of rolling their own authentication.