What is OAuth2/OIDC, and how does Spring Boot support acting as a client or resource server?

OAuth2 is an authorization delegation framework: it lets a user grant a third-party application limited, scoped access to their data on another service (e.g., "let this app read your Google Calendar"), without ever handing that third-party application the user's actual Google password. Instead, the user authenticates directly with the trusted service (the authorization server), which then issues a short-lived, scope-limited access token the third-party app can present on the user's behalf.

OIDC (OpenID Connect) builds an identity/authentication layer on top of OAuth2's authorization mechanics — OAuth2 alone doesn't actually standardize "who is this user," only "what are they authorizing access to." OIDC adds a standardized ID token (itself a signed JWT) containing verified identity claims (user ID, email, name), which is what actually enables "Sign in with Google/Okta/etc." style authentication flows, rather than just delegated API access.

Spring Boot supports two distinct roles in this ecosystem, each with its own starter:

1. OAuth2/OIDC Client (spring-boot-starter-oauth2-client) — your application lets users log in via an external identity provider:

spring:
  security:
    oauth2:
      client:
        registration:
          google:
            client-id: ${GOOGLE_CLIENT_ID}
            client-secret: ${GOOGLE_CLIENT_SECRET}
            scope: openid, profile, email

http.oauth2Login(Customizer.withDefaults()); // "Sign in with Google" style flow, handled largely by Spring Security

2. OAuth2 Resource Server (spring-boot-starter-oauth2-resource-server) — your application accepts and validates access tokens issued by an external authorization server, protecting its own API endpoints:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://your-auth-server.com/

http.oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));
// Spring Security automatically fetches the issuer's public signing keys and validates incoming Bearer tokens

How these two roles typically fit together in a real system: a frontend or mobile app authenticates a user via an identity provider (getting back tokens), then calls your backend API with the resulting access token attached as a Bearer header; your backend, configured as a resource server, validates that token's signature/expiration/issuer/audience against the authorization server's published metadata, without needing to independently manage user credentials at all — a large part of the appeal of OAuth2/OIDC is that individual backend services never need to handle raw passwords or implement their own login/identity logic from scratch.