What is the goal of the authentication?
- Is this for security? Start with a threat model. What are you defending against?
- Or is this just to enforce your architecture?
I'll assume you're doing this for security.
It is reasonable to try to protect your microservices from unauthorized access. One common approach is to design a network with a DMZ:
---LAN------ --DMZ-- #: router/firewall
| | | |
S S S G
All outside connections go through the gateway which can provide authentication.
The routers serve as a firewall and implement the following rules:
- The firewalls allow any outgoing connections.
- The inner firewall allows incoming connections to the services.
- The outer firewall allows incoming connections only to the gateway but not to the inner router.
This prevents any direct outside connections to the internal services. In order for an attacker to connect to the services, either the services need to initiate the connection, or the gateway/web server has to be compromised first, or the routers need to be compromised. If the gateway is compromised, the attacker can connect to the services but will not be on the same network, and would e.g. be unable to sniff or spoof packets on the LAN.
As such, this network design allows defense in depth, especially against attacks that target the lower levels of your stack (e.g. operating systems, web server). It is also advisable if you are publicly running high-risk software such as popular CMSes like Wordpress. With more complex network topologies you can exert more detailed control over possible connections, e.g. you can prevent two sets of services from connecting to each other by placing them into different networks, and not configuring a route between them. Even if the services are not on the same physical network, you can use techniques such as network bridges, VPNs, and VLANs to route traffic between them.
A variation of this pattern is the “run your web app on localhost and use Nginx as a reverse proxy” deployment style. By not listening on an external interface/IP address, the web app cannot be reached from the outside. The Nginx server is exposed on a public IP address, and can connect to the web app on the same computer. Instead of listening on localhost, Unix sockets are often used instead. Nginx can take care of some potential problems, such as rejecting malformed requests before they could trigger a bug in the web app.
As another layer you can add application-level security measures to prevent connections to arbitrary services by an attacker within your network. For example, create a private key for your deployment system. When a service is deployed it gets the corresponding public key, and JWT-style signed tokens that allow it to call other services. When a service receives a request, it checks the signature on the token and that the token allows this kind of request. But it is difficult to do this properly without e.g. allowing tokens to be reused by an attacker.