Why You Need an OAuth2 Resource Server for Microservice Security

There are few tutorials that focus solely on what a resource server is and how to use it; this article introduces the concept to lay a foundation for later practical use.

Traditional security approach shortcomings

In the Spring Security series we learned to protect applications using usernames and passwords (or captchas) to obtain credentials such as JWTs, which are then sent with requests to access resources. This model works well for most monolithic applications because it is simple and convenient.

However, when a project grows and needs to be transformed into microservices, this approach becomes heavyweight, as each service must handle authentication and authorization, prompting the need for a new paradigm.

Authentication and authorization can be loosely coupled

Authentication and resource access control can be separated. For example, when buying an airline ticket you can purchase it either directly from the airline or through a third‑party ticketing center; the flight later validates the ticket without caring about the purchase channel. This mirrors how services can delegate authentication while each service only checks whether a request has the right to access a resource.

In a microservice environment, each service only needs to verify that a request possesses the appropriate permission. The access‑control logic can be abstracted into a shared model and implemented in code, aligning with the decentralized nature of microservices. This is the fundamental purpose of a resource server.

Resource Server

The full name is OAuth2 Resource Server , a component of the OAuth 2.0 protocol that typically uses JSON Web Tokens (JWT) – though opaque tokens are also possible – to verify whether a client is authorized to access a resource.

When a monolithic application is refactored into microservices, it is still advisable to keep the authorization server centralized to issue tokens. Each individual service then acts as a resource server, validating tokens. The guiding principle is to encapsulate common functionality into a library (jar) while keeping service‑specific settings in configuration.

This setup lets the authorization server focus solely on token issuance, while each resource server validates tokens. Adding a new service only requires adding the appropriate resource‑server dependency and configuration, making migration straightforward.

There is also a centralized approach where the gateway handles authentication for all services, but unless you have prior experience it can be hard to adopt and introduces cross‑service security context challenges; beginners are strongly advised to use the model described above.

The author has implemented a preliminary version of this model and will discuss how to realize a resource server with Spring Security in microservices in the next article.