OAuth 2.0 and OIDC Authentication
Prerequisites
Before reading this article, you need to learn:
In the article Deep Dive Into OAuth 2.0 Authorization Framework, we talked about an important issue: Standard OAuth 2.0 can only do authorization, not authentication.
OAuth 2.0 allows third-party apps (like ExampleNote) to get access to user resources (like Google Drive), but it cannot securely prove user identity, because authorization codes might be stolen and hackers can pretend to be the user.
So, how can we safely allow "Login with Google" for third-party apps? The answer is OpenID Connect (OIDC).
Not Just Third-Party Login
Third-party login is a typical scenario of cross-organization authentication (ExampleNote uses Google’s authentication service for user login).
But OIDC can be used inside one organization, too. For example, Google has many internal apps, such as Gmail, Google Drive, Google Docs, and so on. They can all use Google's authentication for unified sign-in.
This is the Single Sign-On (SSO) scenario, providing safe and flexible unified login for many company services. Modern SSO is also based on OIDC. You can learn more in Understanding Single Sign-On (SSO).
Terminology
Here are some key terms in OIDC:
- OP (OpenID Provider): The authentication server; it checks user identity (same as Authorization Server in OAuth 2.0).
- RP (Relying Party): The applications (same as Client in OAuth 2.0).
- ID Token: A JWT token storing user identity information.
The Relationship Between OIDC and OAuth 2.0
OIDC is an authentication layer built on top of OAuth 2.0. It adds authentication to the OAuth 2.0 authorization flow, solving the problem that OAuth 2.0 cannot be used for login.
OIDC reuses the authorization code flow, access token, and other core concepts from OAuth 2.0, so the general process is the same.
The difference is that OIDC adds a nonce parameter and the ID Token on top of OAuth 2.0, which help prevent replay attacks and prove user identity.
Here is the sequence diagram for the OIDC authorization code flow:
In terms of the flow, the main difference is that in the OAuth 2.0 Authorization Flow, when you redirect to Google's authorization page, the URL parameters are different.