Microservices to do user authentication and authorization has always been a difficult point, with the OAuth2.0 password mode was invalidated, it is even more difficult.This article will share some ideas.
Two ways of thinking
There are usually two ways of thinking about authentication and authorization for microservices.
- All authentication authorization is handled by an independent user authentication authorization server, which is only responsible for issuing Token, and then the gateway is only responsible for forwarding requests to each microservice module, and each module of the microservice performs the verification process of Token by itself.
- The other one is that the gateway not only takes on the traffic forwarding role, but also takes on the authentication authorization process, and the authentication information of the current request is relayed from the gateway to the downstream server.
The first one is very simple, and I have designed it this way in several microservices projects. If you have never designed one before, I actually recommend doing it along these lines. You only need to get a server responsible for managing user and role permissions, and all other microservice modules act as resource servers to interact with this user authorization server on their own, plus the three household model system is sufficient for various scenarios.
The second one combines the OAuth2 system, where the gateway not only takes on the traffic forwarding function, but also the authentication authorization is handled at the gateway layer, and the token is relayed to the downstream service. This model requires building a UAA (User Account And Authentication) service. It is very flexible in that it can manage users or let trusted clients manage users themselves, and it is only responsible for authenticating clients (as distinct from user authentication) and authorizing them. This approach is currently used by those who use OAuth2 to build security systems for microservices.
Next, I’ll share my results on the second idea.
Spring Cloud Gateway combined with OAuth2 to provide UAA services
The technologies used are.
- Spring Cloud Gateway
- Spring Authorization Server
- Spring Security 5.0 OAuth2 Client
- OIDC 1.0
general idea
The UAA server is naturally taken care of by the Spring Authorization Server. It is responsible for the overall user management, but of course you can also separate a dedicated user server, except that UAA needs to communicate with the user service via Spring Cloud OpenFeign; in addition it is also an OAuth2 authorization server that manages OAuth2 clients and handles OAuth2 authorization. Here’s the kicker, the gateway Gateway needs to be registered to the UAA server as an OAuth2 client and act as an OAuth2 client.
When User Agent (browser, APP) requests resources through the gateway:
The above performs a standard OAuth2 authorization code process, where Spring Cloud Gateway directs the user to the UAA server login interface to log in.
End-user login for authorization confirmation, see link in browser console.
After the user checks the authorization and confirms it, the resource is successfully accessed. Look at the link of the call.
After the authorization confirmation is submitted, it redirects again to the OAuth2 authorization code login process and finally gets the resource.
We look at the details of the final /res/foo request, and we actually get all the user’s permissions without carrying a Token.
This is all thanks to the gateway Token Relay, the front-end application is well shielded from JWT tokens.
If there are multiple Gateway nodes and UAA nodes, you may want to combine Spring Session to implement distributed Session and distributed management of some client information, user information.