Microservice Authentication and Authorization Solutions with Spring Cloud, Spring Security, OAuth2, and JWT

Introduction

Previously we discussed the basics of Spring Security; now we explore how to integrate Spring Cloud with Spring Security and OAuth to implement authentication and authorization for microservices.

Common Authentication Schemes for Distributed Projects

1. Problems Faced by Microservice Authorization

In a microservice architecture, many services need authentication and permission checks. The client request must propagate the user's authentication state to all services, which is complicated when requests come from browsers, mobile apps, or third‑party programs. Additionally, local session synchronization issues arise in clustered environments, making authorization very complex.

Session synchronization problems are illustrated in the following diagram:

2. Common Authentication Schemes

2.1 CAS Single Sign‑On

CAS is a cookie‑based SSO solution originally created by Yale University. It consists of a CAS Server and CAS Clients. The server handles login, while clients integrate with their applications. The login flow is as follows:

System A access flow:

Browser requests System A; System A redirects to the authentication service with a service parameter.

The authentication service returns a login page; the user submits credentials.

After successful login, the service generates a ticket (ST) and a TGC, storing the TGC in the browser cookie.

The service redirects back to System A with the ticket.

System A validates the ticket with the authentication service.

The authentication service returns user information.

System B access flow:

Browser (same session) accesses System B; System B redirects to the authentication service.

The authentication service finds the existing TGC, creates a new ticket, and redirects to System B.

System B validates the ticket and receives user information.

This approach requires every user‑facing service to interact with the authentication service, generating a lot of network traffic, especially when dozens of micro‑applications are involved, and it is not ideal for mobile clients.

2.2 Distributed Session + Gateway

The gateway handles login and session checks, storing session data in Redis. Backend services retrieve authentication information from the shared Redis store, often using a token derived from the Redis key.

Client sends request; gateway logs in, stores session in Redis, and creates a token.

Token is returned to the browser and stored.

Subsequent requests carry the token; the gateway validates it against Redis and forwards it to downstream services.

Downstream services can retrieve authentication info from Redis using the token.

This scheme requires careful protection of the shared session store and has implementation complexity.

2.3 Client Token + Gateway

Clients obtain a JWT or similar token that carries user information, enabling stateless authentication. The token is encrypted for security.

Client authenticates, receives a securely generated token (e.g., JWT).

Client stores the token and includes it in subsequent requests.

Gateway validates the token; if valid, it forwards the request to backend services.

Backend services extract user information from the token; optionally, Redis can be used for additional storage.

The advantage is statelessness, but long tokens increase network overhead.

2.4 Other Schemes

Other options include Spring Session + Redis for shared sessions, server‑to‑server session synchronization, or using Nginx load‑balancing with URL‑hash consistency.

2.5 The Author's Chosen Solution

For a Spring Cloud microservice architecture, the recommended stack is Spring Cloud + Spring Security + OAuth2 + JWT + Zuul, which essentially combines client‑side token authentication with a unified Zuul gateway.

Explanation:

Client: web, mobile, or third‑party applications.

Authentication Service (OAuth2): handles login and token issuance.

Gateway (Zuul): performs token validation.

Resource Service: checks permissions and returns data.

Typical Flow:

Client requests authentication from the authentication service.

Upon successful login, the service issues a token containing authentication and authorization data.

Client stores the token and includes it in requests to resource services.

Requests first reach the Zuul gateway, where the token can be validated (or validation can be deferred to each resource service).

If validation succeeds, the resource service uses the token’s permission information to authorize access and returns the requested data.

When multiple resource services are involved, the token is passed along in request headers to downstream services for further authorization.

An alternative without Zuul is a direct Spring Cloud + Spring Security + OAuth2 + JWT setup, as shown below: