OpenID Connect - Identity Layer on OAuth 2.0

About 2 min read

OpenID Connect (OIDC) is a protocol that adds an authentication layer on top of the OAuth 2.0 authorization framework. Established by the OpenID Foundation in 2014, it has become widely adopted as the technical foundation for social login such as "Sign in with Google" and "Sign in with Apple." Whereas OAuth 2.0 handles "what can be accessed (authorization)," the defining characteristic of OIDC is that it standardizes "who you are (authentication)."

The Difference Between OAuth 2.0 (Authorization) and OIDC (Authentication)

OAuth 2.0 and OIDC are easily confused, but the problems they solve are fundamentally different. OAuth 2.0 is an authorization mechanism, such as "grant this app access to my photo folder," and it has no capability to prove who the user is. OIDC fills this gap by adding authentication information called an ID token to the OAuth 2.0 flow.

Our article on OAuth permission risks explains in detail the security problems that arise when authorization and authentication are confused.

The Role of the ID Token (JWT)

The heart of OIDC is the ID token. It is issued in the JWT (JSON Web Token) format and contains claims such as the user's identifier (subject), the issuer, the expiration, and the authentication time. The SP (Relying Party) verifies the signature of the ID token to confirm that the token has not been tampered with and that it was issued by a trusted IdP.

The Discovery Endpoint

An OIDC provider publishes its configuration information at a standardized URL called <code>.well-known/openid-configuration</code>. This endpoint describes, in JSON format, the authorization endpoint, the token endpoint, the location for obtaining public keys (the JWKS URI), the supported scopes, and more. By automatically retrieving this information, an SP can integrate with the IdP without any manual configuration.

Use in Google and Apple Login

"Sign in with Google" and "Sign in with Apple" are representative implementations of OIDC. Users simply authenticate with their Google or Apple account, with no need to create a new password for each service. In Apple's case, the "Hide My Email" option also provides a feature to protect privacy. Our article on SNS account protection explains security measures for using social login.

Comparison with SAML

SAML is an enterprise-oriented authentication protocol that was established before OIDC. Both solve the same problem (federated authentication), but their technical approaches differ significantly.

Common Misconceptions

There is a misconception that "OIDC replaces OAuth 2.0," but OIDC does not replace OAuth 2.0; it is an extension built on top of it. OAuth 2.0 access tokens continue to be used for resource access, while OIDC ID tokens are used only for authentication. The two are complementary, and many implementations use OAuth 2.0 and OIDC together. Also see our privacy settings guide for managing privacy when integrating services using OIDC.OAuth and authentication books on Amazon are also a helpful reference.

Real-World Use Cases

"We migrated our SaaS authentication infrastructure from an in-house implementation to OIDC. By supporting Google and Microsoft IdPs, we greatly lowered the adoption barrier for enterprise customers, and our trial-to-contract conversion rate improved by 1.5x. I really feel that SSO support has become an essential requirement for B2B SaaS."