Microservice Authentication and Authorization: Problems, Common Schemes, and a Recommended Solution

Hello everyone, I am your friend Architecture Jun, an architect who writes code and poetry.

1. What problems does microservice authorization face

In a microservice architecture there are many services, each needing authentication and permission checks. The client request must propagate the user's authentication state to all services, handling multiple client types (browser, mobile, third‑party programs) and inter‑service calls. Session synchronization issues in a clustered environment make authorization extremely complex.

Session desynchronization problem is illustrated in the diagram below.

2. Common authentication schemes for microservices

2.1 CAS Single Sign‑On

CAS is a cookie‑based SSO solution originally from Yale University. It consists of a CAS server and CAS clients. The server handles login, while each client integrates with the server. The login flow for System A is:

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

Authentication service returns a login page; 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 and receives user information.

The flow for System B is similar, but the existing TGC allows the authentication service to issue a ticket without prompting the user again.

This approach forces every user‑facing service to interact with the authentication service, generating a lot of network traffic and is not ideal for mobile clients.

2.2 Distributed Session + Gateway

The gateway handles login and checks; session data is stored in Redis for distributed sharing. The gateway creates a token from the Redis key and returns it to the client. Subsequent requests carry the token, which the gateway validates against Redis before forwarding to downstream services.

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

2.3 Client Token + Gateway

Clients obtain a JWT‑style token that carries authentication and authorization information, enabling stateless communication. The token is stored by the client and sent with each request. The gateway validates the token and forwards it to backend services, which can extract user info directly from the token.

The advantage is statelessness; the drawback is increased network overhead due to larger token size.

2.4 Other schemes

Other options include Spring Session + Redis for session sharing, server‑side session synchronization, or using Nginx load‑balancing with consistent hashing. The key is to choose a solution that fits the project.

2.5 My chosen microservice authentication and authorization scheme

I recommend a Spring Cloud architecture that combines Spring Security, OAuth2, JWT and Zuul. The flow is:

Client (web, mobile, third‑party) requests authentication from the OAuth2 authorization service.

After successful authentication, the service issues a JWT token containing user and permission data.

Client stores the token and includes it in subsequent requests.

Requests first reach the Zuul gateway, which validates the token (or validation can be delegated to each resource service).

Resource services extract permissions from the token to authorize access and return data.

If a request spans multiple resource services, the token is propagated via request headers for downstream authorization.

An alternative without Zuul is a direct Spring Cloud + Spring Security + OAuth2 + JWT setup.

To this end, the article concludes.