OpenID Connect is an identity layer built on OAuth 2.0. OAuth 2.0 answers, “What may this application access?” OIDC adds, “Who is the user?” This distinction lets applications delegate login to an identity provider (IdP) instead of storing usernames and passwords themselves. section 12.2 section 13.3.1
An OIDC-based sign-in separates responsibilities among the user, client application, IdP, and resource server. The client redirects the user to the IdP, which authenticates the user and returns tokens. The resource server then applies authorization to protected application data. section 12.2 section 12.5
The protocol’s main pieces provide distinct responsibilities:
- ID tokens authenticate users and carry standardized identity claims such as an identifier, email address, and other profile information. section 13.3.1
- Access tokens authorize access to protected resources; they are not substitutes for ID tokens when an application needs to establish user identity. section 12.5 section 13.3.1
- The UserInfo endpoint supplies additional profile data when the ID token does not contain everything the application needs. section 13.3 section 13.5
- Nonce and state strengthen the flow against replay and cross-site request forgery, while standardized session management and logout support consistent sign-in experiences. section 13.3
A practical authorization-code flow
A client first reads the IdP’s /.well-known/openid-configuration document to discover its authorization and token endpoints. It redirects the user to the authorization endpoint with response_type=code, client_id, redirect_uri, and scope=openid. After login, the IdP sends an authorization code to the registered redirect URI. The client exchanges that code at the token endpoint and receives an access token and, for OIDC, an ID token. Client registration restricts grant types, redirect URIs, and scopes; public clients should also use PKCE. section 12.3 section 13.0
Listing 12.1 The authorization code configuration
server:
port: 9000
spring:
security:
user: #1
name: user #1
password: password #1
oauth2: #1
authorizationserver: #1
client: #2
oidc-client:
registration:
client-id: "oidc-client" #3
client-secret: "{noop}secret"
client-authentication-methods: #4
- "client_secret_basic"
authorization-grant-types: #5
- "authorization_code" #5
redirect-uris: #6
- http://127.0.0.1:8080/login/oauth2/code
scopes: #7
- "openid" #7
Inspect a compact authorization-code client configuration showing client credentials, redirect URI, grant type, and the openid scope. section 12.3
OIDC is useful for employee SSO, customer-facing applications, and social login. It reduces password-handling responsibilities and works across modern SSO services, but libraries do not remove the need to understand protocol choices, trust boundaries, configuration, and secure maintenance. section 2.1.2 section 2.1.5
