OAuth 2.0 and OpenID Connect

"Sign in with Google" feels obvious to users, and it is a lasting source of confusion for developers. The reason is simple: OAuth 2.0 is not an authentication protocol. It is an authorization delegation protocol, designed so that an application can obtain access to a resource on behalf of a user without knowing their password. The question "who is this user?" is not part of it.

OpenID Connect was created precisely to fill that gap: it is an identity layer on top of OAuth 2.0 that adds a verifiable identity token and a standard format for user information. Using OAuth 2.0 alone to authenticate, on the assumption that a valid access token proves an identity, is a well-documented mistake that has produced real vulnerabilities. An access token proves a right of access, not the identity of its bearer.

This lesson therefore carefully distinguishes the two, introduces the four actors, and presents the flow to use today: the authorization code flow with PKCE, the others being obsolete or reserved for special cases. You will then configure the two roles that Spring Security can play: the client, which delegates login to a provider, and the resource server, which verifies the tokens presented to it.