The separation of concerns between API Gateway and microservice
One concern that I have heard raised many times is that there is a need for using the API Gateway not only as a customer directed API proxy service, but also to define the API gateway as the gateway into your inner security and privacy perimeter that protects your microservices from unwanted external access. The core idea is that you then can keep your microservices clean from anything, but business logic while your API Gateway takes care of anything that not is directly concerned with the core of your business.
I have learned two things from the discussions I have had concerning this idea.
- Concerns that at first looks to be purely technical and peripheral, may, in fact, be both front and center to your business.
- Security and Privacy architecture are better modeled as an onion than as an egg.
It’s very tempting to talk about concerns like security and privacy as barriers that you need to traverse to get to your services. It’s an idea that people understand. The outer protective shell that protects my services. Customers don’t usually talk to us about security and privacy. They just want it to be secure.
A typical high-level architectural approach can often look like the following drawing.
The problem with this architectural choice is that the world just isn’t that simple. Privacy and security are not concerns that you add-on to your services as inner and outer barriers, they are supposed to be implemented as integral parts in your system design. In Europe, if that doesn’t happen, you could be in breach of GDPR that states that:
the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default. Recital 78
That doesn’t mean that you can’t model your security and privacy architecture in layers, it just means that it can get awkward if you do simplify it. The world just isn’t that simple. A typical example of this awkwardness gets apparent when you start looking at frameworks for authorization. Just take the next drawing as an example.
This is a typical OAuth2 architecture when you are building microservices. Notice the API Gateway or “proxy resource server” in the lower right corner. That is not considered a standard part of OAuth2 architecture. There is no such thing as a “proxy resource server” or PRS if you will. In OAuth2, the architecture looks like this:
In API Gateway applications like Zuul or Spring Cloud Gateway, you forward the request to your microservice without doing any authorization in the API Gateway. We like to say that the API Gateway is an application proxy, but it doesn’t do any authorization itself. And for good reasons. Because authorization is, in fact, a business concern. What certain applications and user roles are allowed to do to your data is governed by business rules. So is Privacy and Schema validation. The concrete implementation might look technical in detail, but the concern is not. Therefore, traditionally, it’s not solved by the API Gateway. There are concerns, however, that fits well within the boundary of the API Gateway itself. Take API Compositioning and mTLS termination f.ex. These are typical concerns that can be solved in the API Gateways because it’s the purpose for which they were conceived. There are edge cases of course. Like authorizing requests based on information in the mTLS client certificate or composing a response based on a business rule, but understanding where you place those later concerns becomes easy once you know how an API Gateway is meant to be used. The problem I see is that many try to force the API Gateway into doing something it wasn’t meant for. It might be possible, but it’s very awkward and it might even be destructive.
My advice is: “Keep your Gateways dumb and your services smart”. That way, you're at least not doing anything wrong.
