Course Introduction

OAuth 2.0 is foundational for securing modern architectures, yet it is often misunderstood. The purpose of this course is to equip you with the knowledge to implement secure, modern OAuth 2.0 patterns using Spring Security 7.x and Spring authorization server. Before we write a single line of Spring Security configuration, we must establish the fundamental mechanics of delegated authorization. A strong conceptual foundation prevents configuration errors later, when components interact across the network.

Why this course?

This course is for developers familiar with basic web services and Spring Boot who need a reliable, up-to-date guide to securing those services. The Spring ecosystem has evolved significantly, replacing legacy setups with modern, component-based security filter chains and a dedicated authorization server.

By the end of this course, you will understand how to orchestrate token issuance, configure resource servers, and securely manage client applications. We move away from legacy anti-patterns and focus exclusively on the secure defaults required by modern enterprise applications. To achieve this, we first need to rethink what OAuth 2.0 actually does.

Rethinking authorization with OAuth 2.0

It is common to mistakenly think of OAuth 2.0 as an access control list (ACL) or an authentication mechanism. OAuth 2.0 is strictly an industry-standard protocol for delegated authorization. It provides a way for a user to grant a third-party application limited access to their protected resources without ever sharing their actual credentials, such as a username and password.

Instead of credentials, OAuth 2.0 uses scoped tokens. A user delegates access to an application, and the application receives an access token that represents that specific, limited delegation. Furthermore, OAuth 2.0 does not perform authentication checks in its original form. While OAuth 2.0 issues tokens for access, we rely on OpenID Connect (OIDC) when we need to verify the user's identity. OIDC is an identity layer built directly on top of OAuth 2.0. To understand how these scoped tokens are negotiated and moved across the network, we need to meet the specific participants involved in the protocol.

The four core actors of OAuth 2.0

The OAuth 2.0 specification explicitly defines four roles. Understanding these actors is essential because core Spring Security classes and configuration properties map directly to these roles. The following table outlines the responsibilities of each participant in the authorization ecosystem.

Knowing the boundaries of these actors prevents confusion when configuring Spring Security. For example, a React frontend application acts as the client, while your Spring Boot backend might act as the resource server. With the actors defined, we can examine how they interact during a request life cycle.

Token issuance vs. token presentation

The entire OAuth 2.0 protocol can be mentally divided into two distinct phases: getting the token and using the token. We refer to these phases as token issuance and token presentation. The following diagram illustrates how the four actors participate in these two phases.

The strict separation of issuance and presentation is the core strength of OAuth 2.0. The client never sees the resource owner's password. The resource server never has to verify passwords or manage login sessions; it only inspects the cryptographic validity of the access token presented to it. This separation introduces a highly flexible architecture that solves several common engineering challenges.

Problems solved by modern OAuth 2.0

The primary purpose of OAuth 2.0 is to allow third-party applications to integrate safely with your services. However, it also serves as the backbone for modern first-party application architectures. By using scoped, token-based delegation, OAuth 2.0 allows us to completely decouple the frontend client from the backend REST APIs.

An authorization server centrally manages login state and consent, while any number of distributed resource servers simply validate the resulting tokens. This allows microservices to verify access safely across network boundaries without constantly calling a central database to check user roles. Let's test our understanding of these core definitions before moving forward.

We separated authorization (OAuth 2.0) from authentication (OIDC) and defined the clear boundaries between the resource owner, client, authorization server, and resource server. Understanding these actors prepares us to configure token flows and build our security architecture in the upcoming chapters.