Chapter 13: What are OAuth 2 and OpenID Connect?
The introduction explains why applications may separate authentication from their own responsibilities and let users reuse credentials across apps.
After this chapter you will be able to
- Shared authentication across apps. Explain why an organization might use a separate app for authentication instead of making every tool manage its own credentials and login.
- OAuth 2 actor responsibilities. Describe the user, client, authorization server, and resource server, including why a system might have no user.
- Client access token flow. Trace how a client obtains an access token and uses it to make a request that the resource server authorizes, then returns the result to the user. State that OAuth 2 calls its different ways of obtaining a token grant types.
- Access token purpose and limits. Explain what an access token lets a client demonstrate, how a backend may obtain user or client details through it, and why its short lifetime matters.
- Tokens as access cards. Explain how a client uses a token when requesting access to a resource server and what the token helps the backend establish.
- Opaque and non-opaque tokens. Distinguish opaque from non-opaque tokens by where the resource server gets the data it needs for authorization, including the role of introspection and JWTs.
- Opaque token introspection. Explain why a resource server cannot use an opaque token alone to identify a user or client or apply authorization rules, and describe how token introspection supplies what it needs.
- Non-opaque tokens and JWT structure. Describe what non-opaque tokens carry and explain the roles of a JWT’s header, body, and signature.
- Token format selection tradeoffs. Explain why the section recommends considering non-opaque tokens first and when opaque tokens may be a better choice.
- Grant type meaning. Explain that a grant type is a process by which a client obtains a token from an authorization server, and that applications can use different approaches.
- Authorization code grant flow. Trace how an unauthenticated user is redirected to the authorization server to log in, how the client receives an authorization code, and how it exchanges that code for an access token to call the resource server.
- Code exchange security rationale. Explain why the authorization server returns a code rather than an access token in the redirect, and what additional requirement protects the subsequent token request.
- PKCE challenge and verifier exchange. Trace how the client creates a verifier and its hashed challenge, sends the challenge with the user login, and later sends the verifier when requesting an access token.
- Client credentials grant flow. Explain why an app uses the client credentials grant when no user is involved, and trace how it obtains an access token and uses it to call a resource server.
- Refresh token renewal flow. Trace how a client uses a refresh token to obtain a new access token, and explain why this is useful when a grant type requires user login.
- OIDC and OAuth 2 relationship. Explain that OpenID Connect (OIDC) is a protocol built on the OAuth 2 specification and that two OAuth 2 implementations may still need adaptation if they do not follow the same protocol.
- OIDC scopes and ID token. Describe the specific scope values and extra ID token this section identifies as major OIDC changes, including what identity details the ID token stores.
- Common OAuth 2 vulnerabilities. Describe how an OAuth 2 application can be vulnerable to client-side CSRF, stolen client credentials, replayed access tokens, and hijacked tokens, including refresh tokens.
- Framework versus implementation risks. Explain why the section attributes these vulnerabilities to insecure functionality built over OAuth 2 rather than treating OAuth 2 as bulletproof, and describe Spring Security's role in mitigating them.
What it builds on
- How CSRF protection works in Spring Security (chapter 9) · Introduces CSRF protection.
Section by section
Introduction
The introduction explains why applications may separate authentication from their own responsibilities and let users reuse credentials across apps.
- Shared authentication across apps: Explain why an organization might use a separate app for authentication instead of making every tool manage its own credentials and login.
Why it matters: This explains the problem the chapter’s OAuth 2 discussion is intended to address. - Existing credentials for public apps: Describe why a public app might let users sign in with an existing social-platform account rather than require new credentials.
Why it matters: The public-app example shows why credential reuse is useful beyond an organization’s internal tools.
Key terms: OAuth 2, authentication, credentials, authenticate, social media platforms
13.1 The big picture of OAuth 2 and OpenID Connect
This section introduces the actors in an OAuth 2 system and shows how a client obtains and uses an access token to access a resource server.
- OAuth 2 actor responsibilities: Describe the user, client, authorization server, and resource server, including why a system might have no user.
Why it matters: Keeping these roles separate makes the token flow easier to follow. - Client access token flow: Trace how a client obtains an access token and uses it to make a request that the resource server authorizes, then returns the result to the user. State that OAuth 2 calls its different ways of obtaining a token grant types.
Why it matters: This sequence shows where the client gets authorization and where its request is ultimately handled. - Access token purpose and limits: Explain what an access token lets a client demonstrate, how a backend may obtain user or client details through it, and why its short lifetime matters.
Why it matters: A token is more than a login label: it supports authorized requests while limiting how long a lost token remains usable.
Key terms: user, client, resource server, authorization server, access token, grant types, non-opaque tokens, opaque tokens, expires
13.2 Using various token implementations
This section explains what OAuth 2 tokens do and distinguishes token types by how a resource server obtains authorization data.
- Tokens as access cards: Explain how a client uses a token when requesting access to a resource server and what the token helps the backend establish.
Why it matters: This is the role tokens play before the resource server decides what access to allow. - Opaque and non-opaque tokens: Distinguish opaque from non-opaque tokens by where the resource server gets the data it needs for authorization, including the role of introspection and JWTs.
Why it matters: The token type determines whether the resource server can use data in the token or usually needs to request details elsewhere.
Key terms: token, client, resource server, authorization, opaque token, non-opaque token, introspection call, JSON Web Token (JWT)
13.2.1 Using opaque tokens
Explains why an opaque token requires the resource server to ask the authorization server for validation and details before applying authorization rules.
- Opaque token introspection: Explain why a resource server cannot use an opaque token alone to identify a user or client or apply authorization rules, and describe how token introspection supplies what it needs.
Why it matters: This explains why receiving an opaque token is not enough for a resource server to make an authorization decision.
Key terms: opaque token, resource server, authorization server, token introspection, authorization constraints
13.2.2 Using non-opaque tokens
This subsection explains how non-opaque tokens carry information, how a JWT is structured, and when an opaque token may be preferable.
- Non-opaque tokens and JWT structure: Describe what non-opaque tokens carry and explain the roles of a JWT’s header, body, and signature.
Why it matters: A JWT’s contents and signature explain how a resource server can use it without treating it as an unreadable token. - Token format selection tradeoffs: Explain why the section recommends considering non-opaque tokens first and when opaque tokens may be a better choice.
Why it matters: Choosing a token format requires balancing validation convenience against how much data the token exposes and carries.
Key terms: non-opaque tokens, JWT, header, body, signature, Base64, opaque tokens, introspection
13.3 Obtaining tokens through various grant types
Introduces grant types as ways for clients to obtain tokens and warns against two deprecated grant types.
- Grant type meaning: Explain that a grant type is a process by which a client obtains a token from an authorization server, and that applications can use different approaches.
Why it matters: This definition gives you a basis for distinguishing the token-obtaining approaches discussed next. - Deprecated grant type warning: Explain why the section advises against using the implicit and password grant types.
Why it matters: It prevents you from treating every grant type you encounter in an existing app as a recommended choice.
Key terms: grant type, client, token, authorization server, implicit grant type, password grant type, deprecated
13.3.1 Getting a token using the authorization code grant type
Explains how the authorization code grant obtains an access token after user login and why exchanging a code is safer than returning a token in a browser redirect.
- Authorization code grant flow: Trace how an unauthenticated user is redirected to the authorization server to log in, how the client receives an authorization code, and how it exchanges that code for an access token to call the resource server.
Why it matters: Keeping the code exchange distinct from the backend request makes the grant flow easier to follow. - Code exchange security rationale: Explain why the authorization server returns a code rather than an access token in the redirect, and what additional requirement protects the subsequent token request.
Why it matters: This explains the security purpose of the extra code-for-token request.
Key terms: authorization code grant type, client, authorization server, authorization code, access token, resource server, redirect, client credentials, implicit grant type
13.3.2 Applying PKCE protection to the authorization code grant type
This section explains how PKCE adds a verifier and challenge to the authorization code grant to protect the token exchange.
- PKCE challenge and verifier exchange: Trace how the client creates a verifier and its hashed challenge, sends the challenge with the user login, and later sends the verifier when requesting an access token.
Why it matters: The challenge and verifier let the authorization server check that the token request comes from the client that began the login. - Protection against stolen authorization codes: Explain why an intercepted authorization code is insufficient to obtain an access token when PKCE is used.
Why it matters: It explains what extra proof PKCE requires beyond possession of the authorization code.
Key terms: PKCE, verifier, challenge, authorization code grant type, authorization code, hash function
13.3.3 Getting a token with the client credentials grant type
This section explains when an app uses the client credentials grant and how it obtains and uses an access token without a user.
- Client credentials grant flow: Explain why an app uses the client credentials grant when no user is involved, and trace how it obtains an access token and uses it to call a resource server.
Why it matters: It explains how a service can make an authorized call when no user is there to sign in.
Key terms: client credentials grant type, authorization server, access token, resource server
13.3.4 Using refresh tokens to get new access tokens
Explains why access tokens expire and how a client uses a refresh token to obtain a new access token without asking the user to log in again.
- Access token expiration: Explain why tokens have relatively short lifespans and what happens when an access token expires.
Why it matters: Expiration explains why a client needs a way to obtain a new access token. - Refresh token renewal flow: Trace how a client uses a refresh token to obtain a new access token, and explain why this is useful when a grant type requires user login.
Why it matters: Refresh tokens let an app continue serving a user without repeatedly interrupting them to log in.
Key terms: tokens, access token, resource server, refresh token, authorization server, authorization code grant type
13.4 What OpenID Connect brings to OAuth 2
This section explains how OpenID Connect builds on OAuth 2 by narrowing its flexibility and adding conventions for scopes, identity information, and terminology.
- OIDC and OAuth 2 relationship: Explain that OpenID Connect (OIDC) is a protocol built on the OAuth 2 specification and that two OAuth 2 implementations may still need adaptation if they do not follow the same protocol.
Why it matters: It explains why understanding OAuth 2 helps with OIDC without treating the two as identical. - OIDC scopes and ID token: Describe the specific scope values and extra ID token this section identifies as major OIDC changes, including what identity details the ID token stores.
Why it matters: These are the concrete OIDC additions the section highlights. - OIDC terminology equivalents: State the terminology this section commonly uses when discussing OAuth 2 concepts in OIDC terms.
Why it matters: Recognizing the alternate names helps a reader follow OIDC discussions without mistaking them for entirely new components.
Key terms: OpenID Connect, OIDC, OAuth 2, specification, protocol, scopes, profile, openid, ID token, grant type
13.5 The sins of OAuth 2
This section identifies common vulnerabilities in OAuth 2 applications and explains why secure implementation and configuration matter.
- Common OAuth 2 vulnerabilities: Describe how an OAuth 2 application can be vulnerable to client-side CSRF, stolen client credentials, replayed access tokens, and hijacked tokens, including refresh tokens.
Why it matters: Recognizing these failure modes helps you avoid exposing an application's clients and tokens. - Framework versus implementation risks: Explain why the section attributes these vulnerabilities to insecure functionality built over OAuth 2 rather than treating OAuth 2 as bulletproof, and describe Spring Security's role in mitigating them.
Why it matters: Using a security framework helps, but it does not remove the need to configure the application responsibly.
Key terms: cross-site request forgery (CSRF), client credentials, replaying tokens, token hijacking, refresh tokens, OAuth 2, framework, Spring Security, configurations, flow
13.6 Summary
Where this is used later
- Implementing authentication with a common provider (chapter 16) · OAuth 2 login with a common provider applies the existing-account sign-in scenario.
- (chapter intro) (chapter 14) · Provides the authorization-server role used in the chapter’s implementations.
- (chapter intro) (chapter 15) · Provides the resource-server role used in the chapter’s configurations.
- (chapter intro) (chapter 16) · Provides the client role used in the chapter’s implementations.
- Running the authorization code grant type (chapter 14) · Uses the basic token-obtaining flow when running an authorization code grant.
- Configuring JWT validation (chapter 15) · Builds on the idea of a resource server receiving a token with a request.
- Using opaque tokens and introspection (chapter 14) · Provides the concept behind using opaque tokens and introspection.
- Configuring token validation through introspection (chapter 15) · Provides the reason for configuring token validation through introspection.
Concepts explained in this chapter
- authorization serverAn authorization server is the OAuth 2 component that issues tokens after processing an authorization grant and may provide identity-provider functions in OpenID Connect.
- resource serverA resource server is an OAuth server that hosts protected resources and accepts valid access tokens for authorized requests.
- clientAn OAuth client is an application that requests authorization and accesses protected resources on behalf of a resource owner.
- opaque tokenAn opaque token is an access token whose contents do not reveal claims or other usable information to the resource server, which must obtain its validity and associated details from the authorization server.
- Spring Security UserUser is a Spring Security class representing an authenticated user's username, password, and authorities.
- JSON Web TokenA JSON Web Token is a compact token format that represents claims as a digitally signed or otherwise protected JSON-based value.
- grant typeA grant type is an OAuth 2 protocol flow by which a client obtains a token from an authorization server.
- authorization code flowThe authorization code grant type is an OAuth flow in which a client obtains a token through an authorization code, commonly after user authentication.
- Proof Key for Code ExchangeProof key for code exchange is an OAuth extension that binds an authorization-code exchange to a client-generated secret to mitigate code interception.
- OAuthOAuth 2 is an authorization framework specification for delegated access to protected resources using access tokens.
- openid connectoidc is a configuration method that enables OpenID Connect support in an authorization server.
- token introspectionToken introspection is an OAuth protocol operation in which a resource server asks an authorization server whether a token is valid and requests its associated metadata.
- client credentials grant typeThe client credentials grant type is an OAuth 2 grant in which a client obtains an access token using its own credentials without user involvement.
- scopeAn OAuth scope is a named permission value that limits the access or identity information requested by a client.
- client credentialA client credential is secret or otherwise verifiable information that identifies an OAuth client to an authorization system.
- Base64Base64 encoding represents arbitrary binary data as characters from a fixed 64-symbol alphabet and provides no confidentiality.
← Chapter 12: Implementing filtering at the method level
Chapter 14: Implementing an OAuth 2 authorization server →
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.