Co-author: Luo Zexuan, API7.ai technical expert, member of Apache APISIX PMC

Co-author: Zhao Shirui, API7.ai Technical Engineer, Apache APISIX Committer

Authentication is the process of granting a user access to a system and granting the necessary permissions to use the system. The service that provides this function is the identity authentication service.

In a traditional monolithic software application, all of this happens within the same application. But in a microservices architecture, where the system consists of multiple services, and in such an architecture, each microservice has its own tasks, implementing authorization and authentication processes separately for each microservice does not fully comply with this principle.

This article will discuss the difference between identity authentication methods under traditional service architecture and microservice architecture, and finally measure the advantages and disadvantages of various implementation methods of identity authentication services in microservice architecture.

Identity authentication service in traditional service architecture

In the early days of enterprise development services, all functions were implemented in the same application. We call this model “monolithic” to distinguish it from the current more mainstream “microservice” architecture.

A monolithic application consists of a single indivisible unit. It is usually developed independently by each business line, but put into the same environment when deployed. All of these are tightly integrated to provide all functionality in one unit. This unit has all the resources needed. The advantage of a monolithic application is that it is easy to deploy and iterate, and it is suitable for companies with fewer business lines and more independent companies.

As the businesses developed by enterprises become more and more complex, we will find that single services can no longer meet the needs of rapid iteration in real life. We need to split this single giant, and at the same time ensure that the calls between existing functions can be carried out normally. At this time, ESB (Enterprise Service Bus) came into being.

The so-called “enterprise service bus” is a pipeline connecting various enterprise services. The existence of ESB is to integrate different services based on different protocols. ESB has done the work of message conversion, interpretation and routing, so that different services can be interconnected. As you can tell from the name, its concept borrows from the communication model in the principle of computer composition – bus, all systems that need to communicate with external systems, all connected to ESB, you can use the existing system to build a new loosely coupled Heterogeneous distributed systems.

ESB has done the conversion, interpretation and routing of messages, so that different services can communicate with each other. The traditional ESB service invocation method is that every time the caller of the service wants to make a service interaction request to the service provider, it must be routed through the central ESB.

Next, according to these two situations, the realization of the corresponding identity authentication function will be described respectively.

Monolithic architecture

Under the monolithic architecture, user authentication and session management are relatively simple. Authentication and authorization occur within the same application, usually using a session-based authentication scheme. Once authenticated, a session is created and stored on the server, where it can be accessed by any component that requires it and used for notification and authorization of subsequent requests. The session ID is sent to the client and used for all subsequent requests by the application to associate the request with the current session.

ESB architecture

Under the ESB architecture, all processes between users and services, and between services are all processed through the ESB bus. Since the ESB architecture is split from the monolith, the identity authentication method has not changed compared with the monolith architecture.

Identity authentication service in microservice architecture

Migrating from a monolithic architecture to a microservice architecture has many advantages, but as a distributed architecture, the microservice architecture has a larger attack surface and it is more difficult to share user context. Therefore, under the microservice architecture, identity authentication services that are different from the traditional architecture are needed to respond to greater security challenges.

Currently, we can divide identity authentication services under the microservice architecture into the following three categories:

1. Authentication through each microservice;
2. Realize identity authentication through identity authentication services;
3. Authentication through the gateway. Of course, each approach has its own specific advantages and disadvantages.

Authentication through each microservice

Since the microservice architecture is split from the monolithic architecture, a more natural transition is for each microservice to implement identity authentication by itself.

Each microservice needs to implement its own independent security guarantees, enforced on each entry point. This approach empowers microservices teams to make autonomous decisions about how to implement their security solutions. However, this approach has several disadvantages:

• Security logic needs to be implemented repeatedly in each microservice, which leads to code duplication between services.
• It distracted the development team from focusing on their main service.
• Each microservice depends on user authentication data that it does not own.
• Difficult to maintain and monitor. One of the options to complement this solution is to use a shared authentication library loaded on each microservice. This operation prevents code duplication, and the development team will only focus on their business domain, but there are still shortcomings that this improvement cannot solve.

Because the shared authentication library still needs to have corresponding user identity data, and it is also necessary to ensure that each microservice uses the same version of the authentication library. To be honest, the shared authentication library is more like the result of poor service splitting.

Therefore, in summary, the advantages of this method are fast implementation and strong independence; but the disadvantages are also obvious, such as duplication of code between services, violation of the principle of single responsibility, and difficulty in maintenance.

Realize identity authentication through identity authentication service

Since it is difficult for each microservice to implement identity authentication by itself, and using a shared authentication library violates the original intention of microservice splitting, can the shared authentication library be upgraded to a dedicated identity authentication service?

In this case, all access is controlled through the same service, similar to the authentication function in a monolithic application. Each business service must send a separate authorization request to the access control module when performing an operation.

However, this approach slows down the service somewhat and increases the amount of interconnection between services. And each microservice will rely on this “single point” identity authentication service. If there is a problem with the unified identity authentication service, it will cause a chain reaction and cause secondary damage.

So in summary, although this method ensures that each microservice has a single responsibility, it makes the identity authentication function more centralized. But it will still cause a single point of dependence, which will increase the request delay.

Authentication through the gateway

When migrating to a microservices architecture, one of the questions that needs to be answered is how the microservices communicate with each other. The aforementioned ESB is one approach, but a more common choice is to employ an API gateway.

The API Gateway is a single endpoint entry point for all requests, and it provides flexibility by acting as a central interface for consuming these microservices. A microservice that needs to access other microservices (hereinafter referred to as a “client” to distinguish it from the microservice it accesses) does not have access to multiple services, but needs to request API Gateway sends the request.

Because the API Gateway is in the path of client access, it’s an excellent choice for enforcing authentication concerns. Using an API Gateway reduces latency (calling the authentication service) and ensures that the authentication process is consistent across the application.

For example, through APISIX’s jwt-auth plug-in, we can implement identity authentication on the gateway.

First, we need to plan several user identity information (name, key, etc.) and configure them on APISIX. Secondly, according to the given user key, initiate a signature request to APISIX to get the user’s JWT token. Then, when the client needs to access an upstream service, it brings the JWT token, and APISIX acts as the API gateway to proxy the access. Finally, APISIX will complete the identity authentication operation through the JWT token.

Of course, there are advantages and disadvantages in everything, and there is no technology selection that is completely without disadvantages. Using a gateway to complete identity authentication still brings a little single point of problem. Solving this problem on the gateway is less secure than completing authentication within each microservice. For example, after the API gateway is compromised, any microservice behind the gateway can be accessed. But the risk is relative. Compared with the unified identity authentication service, the single point problem of using API gateway is not so serious.

Therefore, this method has obvious advantages in operation. For example, it can effectively protect the back-end microservices, and the microservices do not need to deal with any authentication logic. But at the same time, there will still be a little single-point dependency.

Summarize

In different scenarios, we will need different authentication schemes. In a monolithic application, authentication happens within the same application, and the server holds all sessions. In the era of microservices, monolithic applications have evolved into distributed services, and the identity authentication methods in monolithic applications are not applicable to microservices. In the microservice architecture, we have the three authentication methods mentioned above to choose from. Each option has its own advantages and disadvantages, which need to be analyzed in detail according to the specific actual situation.