Software security itself is a very complex issue. Since each service in a microservice system has to deal with security issues, it will be more complicated in a microservice scenario. David Borsos gave a talk at the recent Microservices Conference in London and evaluated four authentication schemes for microservices systems.
In a traditional monolithic architecture, a single service holds all user data, can verify users, and create HTTP sessions after successful authentication. In a microservices architecture, users are interacting with a collection of services, and each service may need to know who the requesting user is. A naive solution is to apply the same pattern in the microservice system as in the monolithic system, but the problem is how to make all the services access the user's data. There are roughly two ideas to solve this problem: if you use a shared user database, updating database tables will become a problem, because all services must be upgraded at the same time to be able to connect to the modified table structure; if the same data is distributed to all services, when A user has been authenticated, and how to make each service aware of this status is a problem.
Borsos pointed out that a single sign-on (SSO) scheme might seem like a good idea, but it means that every user-facing service has to interact with an authentication service, which generates a lot of very trivial network traffic, while the scheme is implemented Also quite complicated. In other respects, opting for SSO scheme security would be good, the user login status is opaque, preventing attackers from deducing any useful information from the status.
The principle of the distributed session scheme is mainly to store the information about user authentication in the shared storage, and usually use the user session as the key to realize a simple distributed hash map. When users access microservices, user data can be fetched from shared storage. Another advantage of this solution is that the user login state is opaque. It is also a highly available and scalable solution when using a distributed database. The disadvantage of this solution is that the shared storage needs a certain protection mechanism, so it needs to be accessed through a secure link, and the implementation of the solution is usually quite complex.
Client-side token scheme, this token is generated on the client side, signed by the authentication service, and must contain enough information so that user identity can be established across all microservices. A token is attached to each request, providing user authentication for the microservice. The security of this solution is relatively good, but authentication logout is a big problem, and ways to mitigate this can be to use short-lived tokens and frequent checks of the authentication service, etc. For the encoding scheme of client-side tokens, Borsos prefers to use JSON Web Tokens (JWT), which is simple enough and well supported by libraries.
The client token is combined with the API gateway , and this scheme means that all requests go through the gateway, effectively hiding the microservice. On request, the gateway converts the original user token into an internal session ID token. In this case logout is not a problem because the gateway can revoke the user's token on logout. Although this solution is well supported by the library, it may be complicated to implement.
Borsos recommends using a combination of client-side tokens (using JWT) and API Gateway, as this is usually easier to use and has good performance. Although the SSO solution can meet the needs, he believes that it should be avoided. This solution is also interesting if the related technologies required by the distributed session solution are already applied to your scenario. He also stressed the importance of deregistration when choosing a solution.