What is the difference between OAuth 2.0 and OIDC?

OAuth 2.0 is about authorization: letting an app act on resources with the user consent. OIDC extends it with authentication: proving who the user is via a signed ID token. If you need login, you need OIDC, not raw OAuth.

An ID token is a signed JSON Web Token issued by the identity provider after authentication. It carries claims about the user, such as a unique identifier, name, and email, plus details about when and how they authenticated. The application validates its signature, issuer, audience, and expiry before trusting it.

Why is PKCE important?

PKCE (Proof Key for Code Exchange) protects the authorization code from interception by binding it to a one-time secret generated by the client. It was designed for mobile and single-page apps that cannot store a client secret, and current best practice recommends it for all OIDC clients.

OpenID Connect (OIDC)

What is OpenID Connect (OIDC)?

OIDC is a modern identity layer on top of OAuth 2.0 that lets applications verify who a user is via signed JSON tokens from an identity provider.

Last updated: 13 July 2026

How OIDC works

OAuth 2.0 by itself handles delegated authorization, granting an application access to resources, but says nothing about who the user is. OpenID Connect adds that missing identity layer. The application, called the relying party, redirects the user to the identity provider. After authentication, the provider issues an ID token, a signed JSON Web Token (JWT) containing claims such as the user identifier, name, email, and authentication time.

The recommended flow is the authorization code flow with PKCE, which protects the token exchange even for mobile apps and single-page applications that cannot hold a client secret. OIDC also standardizes discovery documents and a UserInfo endpoint, so integrations are largely self-configuring compared to older protocols.

Why OIDC matters

OIDC has become the default identity protocol for modern software. Its JSON and REST foundations fit naturally into web APIs, mobile apps, and microservices, where SAML XML processing is heavy and awkward. Every major platform and social login button is built on it, and developer tooling is abundant in every language.

For organizations, OIDC means new applications can be connected to central identity quickly and securely, with the same SSO and MFA policies that cover the rest of the estate. Standardized flows and libraries also reduce the risk of homegrown authentication mistakes, which remain a common source of vulnerabilities.

OIDC in practice

Connecting an application over OIDC involves registering a client with the identity provider, receiving a client ID, and configuring redirect URIs. The provider publishes a discovery document at a well-known URL, from which most libraries configure endpoints and signing keys automatically. Choosing the right flow matters: authorization code with PKCE for user-facing apps, client credentials for pure machine-to-machine traffic.

Common pitfalls include validating tokens incompletely, skipping signature or audience checks, and setting token lifetimes too long. Sticking to certified libraries avoids most of these issues. Monosign provides OIDC and OAuth 2.0 with PKCE support alongside SAML and WS-Fed, so both modern and legacy applications share one identity backbone.

Frequently asked questions

What is the difference between OAuth 2.0 and OIDC?: OAuth 2.0 is about authorization: letting an app act on resources with the user consent. OIDC extends it with authentication: proving who the user is via a signed ID token. If you need login, you need OIDC, not raw OAuth.
What is an ID token?: An ID token is a signed JSON Web Token issued by the identity provider after authentication. It carries claims about the user, such as a unique identifier, name, and email, plus details about when and how they authenticated. The application validates its signature, issuer, audience, and expiry before trusting it.
Why is PKCE important?: PKCE (Proof Key for Code Exchange) protects the authorization code from interception by binding it to a one-time secret generated by the client. It was designed for mobile and single-page apps that cannot store a client secret, and current best practice recommends it for all OIDC clients.