The solution is project dependent but sometimes both are used. For example, on Azure, you can use a private network and managed identities to lock away the microservices. It depends on how much security you need/want.

When I’ve done this it’s generally done with JWTs where each micro service is configured with a trusted public key that is used to authenticate the JWT. The JWT can be sent to the client when they log in, and used to authenticate all API requests (forwarding the JWT as necessary for service-to-service requests). It’s also possible to have a gateway mint JWTs after using some other means to authenticate client requests.

Sometimes service-to-service requests don’t have a client request in context to pull a JWT from. In those cases you need another authentication mechanism, like a different signed token, or a shared secret.

However, what is stopping a malicious actor from bypassing the API gateway and communicating directly to the micro services ? Do we solve this problem using a firewall, so only trusted traffic reaches the micro services ?

Kind of - sort of

With this kind of setup, usually you’d put all your micro services inside a VPC. The micro services wouldn’t even be directly accessible from the internet. So it wouldn’t really be a “firewall” - but a nat gateway.

Though conceptually a little bit the same. The API gateway is kind of acting as a firewall

You hand out a token, often a json web token, to an authenticated user, which is then validated for each request. A token is basically a hall pass which is signed by your central authority. Depending on how “instant” removal of users needs to be, you sync with a central identity provider each time or you rely on short lived tokens.

This is obviously overkill for most infras, but in a previous position, because we had granular rights, we would forward JWT tokens from the API Gateway to the microservice (and from one microservice to another) so that every µService could validate the token and ask the Rights µService whether it had the required rights for the operation.

I mean, both sound valid. I’d say the first option is likely the most common: some kinda firewall or private network that keeps your microservices isolated from the public internet. In a practical sense, odds are all of this stuff is physically co-located anyway, so it could even be that the networks are physically isolated as well.

Modelling how you want to handle trust in your architecture doesn’t have a best answer really. Many ways to pet a cat, and all that jazz. Some prefer to trust only end to end, meaning not just establishing trust at the API entry, but all the way to the backend. There are arguments to be made for doing it either way. As long as your services behind the API gateway are in a private network, it is maybe okay to establish complete trust here and you could even terminate TLS and use clear communications. Another more secure pattern is to authenticate the call to the API, authorize which backends can be called, then verify the source caller in the backend as well.

Both of those are common. If you’re thinking of using keys also read up on OAuth Client Credentials Flow, rather than reinvent the wheel.

mTLS is another way, where the client also sends a TLS certificate to the server so they both know each other are who they say they are.

Without considering any other security measures:

• The client authenticates with the identity provider and receives a signed JWT
• When the request hits the API Gateway, the gateway checks the signature with the auth service to make sure it hasn’t been tampered with (whether this is internal or external — imagine if one of your servers was compromised, you still don’t want it to be able to forge a JWT with any rights beyond what the service is supposed to have)
• If the JWT is valid, the gateway forwards the request to the service and the service can trust it without validation (I think. We haven’t gotten to this part yet.)
• Requests with invalid JWTs are dropped
• The API Gateway can also handle refresh tokens invisibly.
• A compromised API gateway obviously could then forge JWTs so if you want you can have each service check signatures on their own, but the advantage of the gateway is that you have a single point of vulnerability to harden rather than trust each service developer to correctly validate the token on their own.

So you can write the validation part once. I happen to be tech lead on a project to write this mechanism, so it’s pretty fresh in my head.

https://en.wikipedia.org/wiki/Service_mesh