This blog is the last part of the blog series that I have developed on authentication and authorization security patterns. Here I have covered API gateway security patterns. But before delving deep, let’s understand API gateway in detail.
API Gateway
API gateway is considered as one of the most crucial components in microservice architecture. API gateway in a microservice deployment exposes the selected set of microservices as APIs to the outside world. It works as an entry point for the microservices deployment used to screen all the incoming messages for security. The API gateway is responsible for providing the following security aspects-
- Exposing a chosen set of microservices to the outside world
- Throttling
- Authentication & Authorization
Let me explain these security aspects one by one below.
Exposing a chosen set of microservices to the outside world
It is the fundamental requirement for an API gateway; all significant players like Zuul, Spring gateway, Kong, etc., serve the same purpose. Each tool has its way of exposing microservices to the public. The following configuration shows an example from the Zuul configuration to achieve the same.
zuul.routes.order.url=http://localhost:8080
It makes order processing service available at the endpoint.
Throttling
A typical microservices deployment gets exposed to diverse threats by letting multiple requests in within a specific time frame. Throttling such requests is a necessity.
Attackers trying to perform the DoS and DDoS on the systems can be prevented from doing so if you limit the number of requests, sending of requests, and prevent others from accessing the system. You can also reasonably set limits to offer a reasonable quota of the total traffic that the system can handle to your users. Following are the various types of throttling we can apply to our systems:
1. Quota-based throttling for applications: Let’s assume that our ‘Order Processing Service’ can handle 1,000 requests per second. We have various types of client applications that are web applications, desktop, or mobile applications, as shown below:
You can solve this problem by providing each application with a quota, for example, 200 requests per second, and then apply this quota at the API gateway. In this way, a given application or device will be able to cater to the other users in the system. Thus, it eliminates the chances of a single application producing a DoS or DDoS attack.
For this to work successfully, the API gateway must be able to identify the application from which each request originates. Each consumer application should have a unique client ID, and based on the assumptions, APIs on the API gateway must be secured using OAuth 2.0. Once an application sends a request with an access token to the API gateway, the gateway can introspect the access token. In this case, it can do it by talking to the OAuth 2.0 authorization server, and it can further retrieve the corresponding client ID. You can now use this client ID to identify the application in a unique manner from which the request originated. Next, the API gateway will count the total number of requests served within a time window of one second, which is against each unique client ID. You can check the same in the image given below. As soon as the client ID crosses 200 requests per second, the API gateway will avert further requests from that client ID to be sent to the target services until the time window passes.
2. Fair usage policy for users: In this section, I will explain how you can ensure that all users of applications are equivalent. None of us would like it if some users were denied access to service due to other users who might be consuming more chunks of the quota. There are various ways that I’ll discuss as part of authentication and authorization where the API gateway can determine the user context like OIDC’s had ID token; self-contained JWT token has ‘sub’ claim, basic authentication, etc. Here we need to maintain the track of requests per sec per user instead of client application as shown below.
Authentication & Authorization
On receiving the token as part of every request, the API gateway can now coordinate with auth server for validating the token. It can either use an opaque token or JWT with a signature to validate the token. Once the token is valid, it can append the user’s information and permission to the customer header, as shown in the above diagram. Downstream services can trust the info appended by the API gateway and make relevant decisions based on that.
Conclusion
I have explained all the security patterns in authentication, authorization, and API gateway microservice architecture in my blog series. You should try them all and share your experience in the comments section.
