Introduction
Microservice architecture consists of a suite of independently deployable, small, modular, and compassable (composable) services. Each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.
In addition to modular services, the API gateway and other elements are integral parts of microservice architecture.
What and Why of API Gateways
Basically, the API Gateway is a reverse proxy to microservices and acts as a single-entry point into the system. It is similar to a Facade pattern from object-oriented design and similar to the notion of an “Anti-Corruption Layer” in Domain Driven Design.
With a single-entry point into the system (references), it becomes easy (and manageable) to enforce runtime governance such as common security requirements, common design decisions (e.g. every consumer of the service should have X-Correlation-ID header), and real-time policies such as monitoring, auditing and measuring API usage, and throttling.
Security
Authentication and Authorization
Federated identity is the preferred solution for implementing authentication and authorization in microservice architecture. Each microservice does not necessarily need to obtain and store users’ credentials in order to authenticate them. Instead, microservices can use an identity management system that is already storing a user’s identity to authenticate the user. This approach allows the decoupling of the authentication and authorization functions. It also makes it easier to centralize these two functions, to avoid a situation where every service must manage a set of credentials for every user.
There are three major protocols for federated identity: OpenID, SAML, and OAuth.
Every API request is authenticated at the gateway layer.
On behalf of the end user, the application client first grabs an access token from the authentication server by presenting credentials. This access token is then passed along with the API request in Authorization HTTP header. The API Gateway then validates the access token with the authorization server. The JWT token, which contains the claims for the user, is then passed to backend microservices. Backend microservices then use the information inside the JWT token for authorization purpose. The same JWT token is passed along when one microservice communicates with another microservice.
| Note |
|---|
Ideally, every microservice should authenticate the token as received from its caller (gateway or microservice). There is a trade-off between security and performance. |