OAuth 2.0 Actors, Endpoints, and Token Types

Understanding the abstract roles of OAuth 2.0 is only the first step in building a secure architecture. To write practical code, we need to map those theoretical actors to concrete system components and understand exactly how they communicate. In a modern Spring ecosystem, misidentifying a components role can lead to importing the wrong starter dependencies or misconfiguring security filter chains. We will map the core actors to specific Spring libraries, map their communication paths to standard network endpoints, and define the exact tokens they exchange.

Translating actors into system components

In the previous lesson, we defined the resource owner, client, authorization server, and resource server. When we transition from architecture diagrams to a Spring Boot project, these actors map directly to specific Spring Security modules.

The following table maps each conceptual OAuth 2.0 actor to the corresponding Spring Security dependency that implements its behavior.

By aligning our architecture with these specific starters, we ensure that each service in our distributed system handles only its designated responsibilities. The client requests access, the authorization server grants it, and the resource server enforces it. To perform these duties, these components must communicate across standardized network endpoints.

Standard OAuth 2.0 communication endpoints

OAuth 2.0 relies on a specific set of URIs to facilitate the issuance and presentation of tokens. The two most prominent endpoints provided by the authorization server are the authorization endpoint and the token endpoint.

The authorization endpoint handles front-channel communication. The client redirects the users browser there so the authorization server can authenticate the resource owner and obtain consent. Conversely, the token endpoint handles back-channel communication. Once consent is granted, the client communicates directly and securely with the token endpoint to exchange authorization grants for tokens.

The following sequence diagram illustrates the flow of a request through these endpoints.

This endpoint separation prevents sensitive tokens from being leaked in browser history or intercepted via front-channel redirection. The token endpoint securely returns the tokens directly to the clients backend. To handle the response effectively, we must understand the specific types of tokens returned.

Decoding the token taxonomy

Modern authentication flows involve up to three distinct types of tokens, each designed for a specific actor and purpose. Confusing their intended audience is a common source of security vulnerabilities.

The access token is proof of delegated authorization intended strictly for the resource server. From the clients perspective, the access token is an opaque string, meaning the client should never attempt to parse it or read its contents. The refresh token is a long-lived credential intended only for the authorization server. The client uses it at the token endpoint to obtain new access tokens without forcing the user to log in again. Finally, the ID token is an artifact of OpenID Connect (OIDC). Unlike the access token, the ID token is intended specifically for the client to parse, allowing it to verify the users identity and extract profile information.

The following tree visualizes this taxonomy and the protocols that govern it.

Understanding that the client reads the ID token, the resource server reads the access token, and the authorization server reads the refresh token ensures that we configure our token decoders and validation filters in the correct services. The presence of an ID token depends entirely on crossing the boundary into OpenID Connect.

The OpenID Connect boundary

OAuth 2.0 is solely an authorization protocol. If a client requests standard OAuth 2.0 scopes (such as read:messages or write:documents), the authorization server issues an access token that grants those specific permissions. However, the client learns nothing about the users underlying identity.

To bridge this gap, we rely on OpenID Connect. OIDC is activated by requesting a specific, reserved scope: openid. When the client includes openid in its request to the authorization endpoint, it signals to the authorization server that it needs authentication data. The authorization server responds by including an ID token alongside the access token during the back-channel token exchange.

Lets test our understanding of these endpoints and token boundaries.

We have successfully mapped the abstract concepts of OAuth 2.0 to tangible Spring Security modules, network endpoints, and specific token types. By clearly separating the responsibilities of the authorization endpoint from the token endpoint, and by recognizing the boundary where OAuth 2.0 authorization becomes OIDC authentication, we now have the architectural blueprint needed to implement secure grants.