In my previous blog, I talked about various security reasons for achieving security in micro-service architecture. Apart from this, I also discussed the authentication security patterns that the users should know. To explain patterns around authentication and authorization, I quoted an example of an e-commerce microservices application that you can check here to understand more.
This blog is the continuation of the blog series that I have developed. In this article, I will extensively talk about the various authorization patterns in microservice architecture. So, let us begin with it.
What Are Authorization Patterns?
These are security mechanisms that you can use to decide your client’s privileges related to system resources. These system resources could be files, services, data, and application features built on your client’s identity. One such is OAuth2.0, it is related to the access delegation, you can understand more about it in relation to OpenID Connect here.
Check out how OAuth 2.0 is important in authorization patterns as given below.
OAuth 2.0 for user access delegation
Let us imagine a situation where you want a third-party application to read your status messages on your Facebook wall. So, you would like to delegate a third-party application to have access to your Facebook wall. One of the ways to give access is via sharing your Facebook credentials with a third-party application that can directly access your Facebook wall. It is termed access delegation by sharing the credentials.
Although it tends to solve the problem of access delegation, once the credentials are shared with the third-party application, it can be utilized to carry out any action, thus creating security problems.
OAuth 2.0 solves the problem of access delegation. It does not allow users to share credentials with third-party applications, but you can share a temporary time-bound token that serves a definite purpose. It defines the following four grant types:
- Authorization code grant type
- Implicit grant type
- Resource owner password credentials grant type
- Client credentials grant type
I will not be going through each grant type in this blog but will focus on patterns.
1. Scattered data and scattered logic pattern
In this pattern, the data required to make authorization decisions get scattered across the different microservices. In addition to data, the logic behind deciding whether access is to be given to the requestor or not is spread across the service.
The pattern given above works for a small number of microservices, but problems start appearing when the number of services increases. The call to get data for making authorization decisions is putting an unnecessary load on underline services, as shown in the above diagram.
2. Centralized data and logic patterns
We can try putting all the authorization data and logic in one place as a solution. We can then separate it from services that require authorization. We can implement this pattern by following a common way of building a dedicated authorization service. Another option could be to use an off-the-shelf solution like Keycloak or Open Policy agent. Whenever services have to perform permission checks, they turn around and ask for the authorization service.
Having a single system in charge of authorization is quite appealing. But you should consider some essential points before finalizing the pattern as mentioned below:
- The entire authorization data is in a single place now. There could be one possibility: either the authorization service turns into the data’s single source of truth, or you can copy and synchronize the data from your applications to a central place.
- The authorization data should understand the entire data model underlying permissions related to groups, shares, folders, guests, and projects. The system can become a bottleneck for new development if the models are constantly changing. Any change in any microservice can ask for an update to the authorization service. Thus, breaking the separation of concerns.
- A single service that has the responsibility for securing every type of request needs high availability as well as low latency. Every request gets denied if the system goes down, and every request gets slow if the system starts responding to the queries slowly.
I have observed that this pattern is used widely. The advantage of this pattern is its architectural simplicity, and it gives them the freedom to developers to not be concerned about the roles data or org data origin. You can get the authorization data quickly on request, and you can also perform a permission check instantly without any additional roundtrips.
One of the caveats of adding data in request as the header is that it opens a new path of attack. You should fully be aware that malicious clients cannot inject their headers. To avoid this, you can add your user’s role or other data related to access control in their authentication token, called JWT (JSON Web Token).
Conclusion
Thus, after discussing the authorization security patterns, I hope you have some idea about these security patterns in the microservice architecture. In my next blog, I will take you through the necessary security patterns in the API (Application Programming Interface) gateway. Try to analyze these security patterns in your microservice architecture and share your thoughts on them in the comments section.
