No system can avoid authentication and authorization. The traditional approach to this issue is to either work out a solution within your own project, or delegate them to third-party libraries. Would it be any different if we used Service Mesh?
The main purpose of Service Mesh is to enable service-to-service communication by delegating non-business related functions to the infrastructure layer. This article will illustrate how to decouple authentication and authorization logic into an infrastructure layer by introducing/making use of a service mesh, resulting in more business-oriented microservices in our software architecture.
Let's look at an example.
Background
A business corporation wants to start their own basketball association. They expect their applicants to submit team-wise applications to a platform where their assigned application reviewers can review them.
To access the platform, whether you are an applicant or reviewer, it's required that you sign in with a Google account.
Mobile numbers are required for applicants and team members for mapping them to applications. When team members sign into the system as applicants, they can see the applications that their team members submitted on behalf of them.
System structure
We use Google as User Directory, so users can log in via Google. Also, functions like "Sign Up," "Reset Password" and "Send Verification Code" are delegated to Google.
An application service is needed to manage applications; an applicant service is needed to help applicants create applications in steps since an application is too big to be finished in one go.
There are users other than applicants, such as application reviewers from the business corporation, thus, we need a Domain Specific User Information service to record who users are and store the information that User Directory can’t provide.
Authentication
There are 2 user access levels in the system. To know what access level the requesting user belongs to, the system must know its user identification. Authentication, or “identifying the requesting user,” is the prerequisite for authorization.
There are 2 levels of authentication in the system. Both the system and microservices within the system can identify the requesting user.
System identifies users
Microservices within the system eventually handle requests from users. But we don't want every microservice to deal with the login process, so the system needs to identify the users before their requests reach our microservices.
Login
To use our system, users must first go to the login page, which directs users to log in with Google.
Accessing the system
When users finish the login, they can then send requests to the system. When the requests get into the system, internal tokens will be attached to them for subsystems to know where the requests are from.
Microservice identifies users
Users’ requests will eventually reach microservices in the system. To ensure that an authenticated user actually sends the request to microservices and isn't spoofed by other hijacked subsystems in the system, microservices still need to verify the identity of the requester. This is done by verifying the "internal token" in the request.
Before the requested microservice processes the request, it must verify the "internal token", i.e., the JWT (JSON Web Tokens) contained in the request. To verify the JWT, it needs to obtain the key with which we can check if the JWT has been modified. This process has nothing to do with the business of the microservice itself, but is an indispensable part of the microservice. In the traditional approach, this part of logic is placed in microservices as the authentication layer. Although the authentication layer is independent of the business layer, the responsibility of microservices has been expanded, in turn increasing their complexity. By delegating this part of the logic to a sidecar, our microservices can be cleaner, and developers can ignore this part when developing microservices.
In the next part, we’ll focus on the Authorization part of the process.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
