OAuth 2.0 Introduction

OAuth 2.0 is an authorization framework that lets an application access resources on a user’s behalf without handling their password. Instead of “log in with your password here,” the user authenticates at a trusted authorization server and your app receives a short-lived access token. Spring Boot implements both sides of OAuth2 — acting as a client (social login) or a resource server (validating tokens). This page covers the concepts those pages build on.

The four roles

OAuth2 defines four actors. Keeping them straight is the key to understanding every flow:

Role	Who it is	Example
Resource owner	The user who owns the data	A person with a Google account
Client	The app wanting access	Your Spring Boot web app
Authorization server	Authenticates the user, issues tokens	Google, GitHub, Keycloak
Resource server	Hosts protected APIs, validates tokens	Your Spring Boot API

A single Spring Boot service is often both a client (it redirects users to Google) and a resource server (it protects its own /api/** with tokens).

The access token

The output of every OAuth2 flow is an access token — a credential the client attaches to API calls:

Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...

The token is usually a JWT signed by the authorization server. A resource server validates it by checking the signature (against the issuer’s public keys) and claims like exp, iss, and scope — no call back to the auth server needed per request. Tokens are deliberately short-lived; OAuth2 also defines refresh tokens to get new ones, mirroring the refresh token pattern.

Grant types

A grant type (or “flow”) is how the client obtains a token. Two matter most today.

Authorization Code with PKCE

The standard flow for any app where a human logs in (web apps, SPAs, mobile). PKCE (“pixy”, Proof Key for Code Exchange) protects the flow against intercepted authorization codes and is now recommended for all clients, not just public ones.

1. Client generates a random code_verifier and its SHA-256 code_challenge
2. Client redirects the user to the authorization server with the code_challenge
3. User authenticates and consents at the authorization server
4. Auth server redirects back with a one-time authorization code
5. Client POSTs the code + code_verifier to the token endpoint
6. Auth server verifies the verifier matches the challenge, returns an access token
7. Client calls the resource server with the access token

The user’s password never touches the client — only the authorization server sees it. The OAuth2 Social Login page wires this up with spring-boot-starter-oauth2-client.

Client Credentials

For machine-to-machine calls where there is no user — a backend service calling another service. The client authenticates with its own id and secret and receives a token representing itself.

1. Service authenticates with client_id + client_secret at the token endpoint
2. Auth server returns an access token (no user involved)
3. Service calls the downstream API with the token

curl -X POST https://auth.example.com/oauth2/token \
  -d 'grant_type=client_credentials' \
  -d 'client_id=reporting-service' \
  -d 'client_secret=...' \
  -d 'scope=reports:read'

Grant type	User present?	Use case
Authorization Code + PKCE	Yes	Web apps, SPAs, mobile login
Client Credentials	No	Service-to-service / cron jobs

Note: The older Implicit and Resource Owner Password Credentials grants are now discouraged by the OAuth 2.1 guidance. Prefer authorization code + PKCE for users and client credentials for services.

Scopes

A scope limits what a token can do — reports:read, profile, email. The client requests scopes; the authorization server decides which to grant; the resource server enforces them. In Spring Boot, scopes typically map to authorities like SCOPE_reports:read, which you can check with method security. The resource server page shows how to customize that mapping.

OpenID Connect vs OAuth2

OAuth2 is about authorization (“this app may read your calendar”). It says nothing standard about who the user is. OpenID Connect (OIDC) is a thin identity layer on top of OAuth2 that adds:

An ID token — a JWT with verified identity claims (sub, email, name).
A standard /userinfo endpoint.
The openid scope that triggers all of the above.

	OAuth 2.0	OpenID Connect
Purpose	Authorization (access to resources)	Authentication (who the user is)
Key token	Access token	ID token (+ access token)
Tells you the user’s identity	No (not standardized)	Yes, via verified ID token claims
”Log in with Google” uses	—	OIDC

Tip: Social login is really OpenID Connect. When you configure Google or GitHub in OAuth2 Social Login, Spring uses the OIDC ID token to establish the user’s identity, then maps it to a local account.

Where Spring Boot fits

As a client — spring-boot-starter-oauth2-client handles the authorization code + PKCE flow and OIDC login. See OAuth2 Social Login.
As a resource server — spring-boot-starter-oauth2-resource-server validates incoming JWTs against an issuer. See OAuth2 Resource Server.
With a full IdP — run Keycloak as the authorization server and point Spring Boot at it.