OpenID Connect

Definition

OpenID Connect is an identity authentication protocol built as a layer on top of OAuth 2.0 that lets an application verify a user's identity and obtain basic profile information from an identity provider, in addition to OAuth's original purpose of granting access to resources. It standardizes how a client application receives a signed identity token, called an ID token, after a user authenticates, giving developers a consistent way to add "sign in with" functionality across different identity providers such as Google, Microsoft, or an organization's own identity system.

Overview

OAuth 2.0 was designed to solve authorization, letting a user grant an application limited access to their data on another service without sharing a password, but it deliberately left authentication, proving who the user actually is, outside its scope. Many applications built on plain OAuth ended up misusing access tokens as a proxy for identity, which was insecure because access tokens are not designed to carry verified identity claims. OpenID Connect was created to formalize authentication as a standard extension of OAuth rather than leaving every implementer to invent an ad hoc solution. Mechanically, OpenID Connect adds a new token type, the ID token, which is a signed JSON Web Token containing claims about the authenticated user, such as their subject identifier, when they authenticated, and optionally their name or email if the client requested that scope. When a client initiates an OpenID Connect flow, it requests the openid scope alongside any OAuth scopes it needs, and after the user authenticates with the identity provider, the provider returns both an access token, for calling APIs, and an ID token, for establishing who the user is. The identity provider also publishes a discovery document and a set of public signing keys at well-known URLs, letting client applications verify the ID token's signature without needing to trust the network connection alone. OpenID Connect differs from SAML, an older federated identity standard, primarily in transport and audience: SAML exchanges XML assertions typically over browser redirects and is common in enterprise single sign-on, while OpenID Connect uses JSON and REST-style HTTP calls, making it a better fit for modern web and mobile applications and easier to implement in JavaScript and mobile SDKs. It layers on top of, rather than replaces, OAuth, so any system needing both delegated API access and login can use the two together instead of maintaining separate mechanisms. In practice, OpenID Connect underlies most consumer "sign in with Google," "sign in with Microsoft," and similar buttons, as well as enterprise single sign-on systems built with providers like Okta or Auth0. Developers rely on well-tested libraries rather than implementing the token verification logic themselves, since correctly validating signatures, expiration, and audience claims is easy to get subtly wrong. The main limitations are that OpenID Connect inherits OAuth's redirect-based flow complexity, which can be awkward in native mobile or embedded device contexts, and that its security depends entirely on correct token validation; a client that skips signature verification or fails to check the token's audience can be tricked into accepting a token meant for a different application.

Specification

• Adds a signed ID token containing verified user identity claims
• Layers directly on top of the OAuth 2.0 authorization framework
• Uses the openid scope to request authentication alongside authorization
• Publishes discovery documents and public keys for token verification
• Encodes claims as JSON Web Tokens rather than XML assertions
• Supports optional user profile scopes like name and email
• Enables consistent single sign-on across multiple identity providers
• Widely implemented via vetted client libraries and SDKs

Use Cases

Alternatives

Frequently Asked Questions

Related in DevOps