Secure Microservice Auth with Spring Cloud Gateway & OAuth2

Microservice authentication and authorization have always been challenging, especially after the OAuth2 password grant was deprecated. A recent issue encountered by a colleague prompted a sharing of ideas.

Two Approaches

Typically there are two approaches for authentication and authorization in microservices:

All authentication and authorization are handled by an independent auth server that issues tokens; the gateway only forwards requests, and each microservice validates the token itself.

The gateway not only forwards traffic but also handles the authentication and authorization flow, relaying the authentication information to downstream services.

The first approach is simple and has been used in many projects. If you have never designed it, I recommend this approach: a dedicated server manages users, roles, and permissions, while other services act as resource servers interacting with the auth server, combined with a three‑tenant model to cover various scenarios.

The second approach incorporates the OAuth2 system; the gateway handles both traffic forwarding and authentication/authorization, relaying the token to downstream services. This requires building a UAA (User Account and Authentication) service, which can manage users, allow trusted clients to manage users, and handle client authentication and authorization. Most OAuth2‑based microservice security implementations use this method.

Below is the implementation of the second approach.

Spring Cloud Gateway with OAuth2 Providing UAA Service

Technologies used:

Spring Cloud Gateway

Spring Authorization Server

Spring Security 5.0 OAuth2 Client

OIDC 1.0

Overall Idea

The UAA server is naturally implemented by Spring Authorization Server. It manages users, and can optionally communicate with a separate user service via Spring Cloud OpenFeign. It also acts as an OAuth2 authorization server, managing OAuth2 clients and handling OAuth2 authorizations. The gateway must register as an OAuth2 client with the UAA and act as an OAuth2 client itself.

When a User Agent (browser or app) requests a resource through the gateway:

The flow follows the standard OAuth2 authorization code process. Spring Cloud Gateway redirects the user to the UAA login interface.

After the user logs in and confirms authorization, the request reaches the resource. The request details for /res/foo show that no token is sent yet the user’s permissions are obtained, thanks to token relay performed by the gateway, which shields the frontend from the JWT token.

If multiple Gateway and UAA nodes are deployed, consider using Spring Session to achieve distributed session management and share client and user information across nodes.

Conclusion

With the described process, developers familiar with hands‑on implementation should be able to build the related functionality.