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.

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.

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.

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

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.