OAuth2 & OpenID Connect
Delegating authentication to a provider: the resource-server and client roles, and when to use them.
On this page
Issuing and managing your own passwords is a lot of responsibility - and often unnecessary. "Sign in with Google" exists because most apps shouldn't be in the password business at all. OAuth2 and OpenID Connect (OIDC) are the standards that make delegated authentication work, and Spring Security supports both roles.
The problem OAuth2 solves
OAuth2 lets a user grant an application limited access without sharing their password with it. Instead of handing over credentials, the app receives a scoped access token from a trusted authorization server (Google, GitHub, Okta, Keycloak…).
OpenID Connect is a thin layer on top of OAuth2 that adds identity - an ID token proving who the user is - which is what powers "Sign in with…".
When you check into a hotel, you don't get the manager's master key - you get a key card that opens only your room, only until checkout. You never learn the master key, and the hotel can revoke your card anytime. OAuth2 works the same way: an app gets a scoped, expiring access token (the key card) issued by the authorization server (the front desk), instead of the user's actual password (the master key).
The three roles - and where you fit
| Role | Who | Spring support |
|---|---|---|
| Authorization server | Issues tokens (Google, Keycloak, Okta) | Usually a product you use, not build |
| Resource server | An API that validates tokens to protect endpoints | spring-boot-starter-oauth2-resource-server |
| Client | An app that obtains tokens to call APIs / log users in | spring-boot-starter-oauth2-client |
Most of the time you write a resource server - exactly what BookVault's JWT setup already is. Pointing it at a real provider's keys is a small change:
spring:
security:
oauth2:
resourceserver:
jwt:
# fetch the provider's public keys to verify tokens — no shared secret
issuer-uri: https://accounts.google.comNow BookVault validates tokens issued by that provider, using the provider's published keys. If instead you want your app to log users in via Google, you add the client starter and configure the provider's client id/secret.
Don't build an auth server unless you must
Running a secure, standards-compliant authorization server (issuing tokens, managing consent, rotating keys) is a serious undertaking. Prefer a battle-tested provider - managed (Auth0, Okta, Cognito) or self-hosted (Keycloak) - and make your app a resource server and/or client. Reserve Spring Authorization Server for when you genuinely need your own.
For each, name the OAuth2 role BookVault (or a related app) plays:
- BookVault protects
/api/booksby validating access tokens issued by Keycloak. - A new BookVault web frontend logs users in with "Sign in with Google."
- You need something that actually issues and signs the tokens.
An API that validates OAuth2 access tokens to protect its own endpoints plays which role?
Key takeaways
- OAuth2 lets users grant apps limited, token-based access without sharing their password; OpenID Connect adds identity (the ID token) for 'Sign in with…'.
- Access tokens are scoped and expiring, issued by a trusted authorization server - like a hotel key card, not the master key.
- Three roles: authorization server (issues tokens), resource server (validates them), client (obtains and uses them).
- You'll usually build a resource server (like BookVault) and sometimes a client - rarely an authorization server.
- Prefer a proven provider (Keycloak, Okta, Auth0) over building your own auth server.