Is there a way to ensure that serviceA is called only by serviceB(or a set of whitelisted services)? All the services are independent and do not go through a service gateway as they are completely independent.

Are there any good microservice patterns to follow up on this?

  • 2
    Must ServiceB be available on the public internet, or can you keep it inside a private network? That aspect of the architecture greatly affects the types of answers that are appropriate.
    – John Wu
    Nov 13, 2019 at 21:19

4 Answers 4


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

          inner   outer
+---+---+---#---+---#--- internet
|   |   |       |
S   S   S       G

 services     gateway,
             web server

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.


Why would you do such a thing?

Technically, it is possible simply by restricting the usage of a service A to the user X which corresponds to the service B. Any other user trying to access the service won't be able to authenticate, i.e. will receive HTTP 401 Unauthorized in response.

Whitelisting IP addresses would be a nightmare to maintain, since service B would possibly be deployed on multiple instances, and may be decommissioned on old machines which would then be reused for other services. Don't do that.


Service to service authentication is a super important. Microservice architectures typically depend on each service being responsible for it's own security just in case things like network security fail. There's even a well known framework for it called SPIFFE https://spiffe.io/, and it's used by the nice folks at Istio.

We did an episode of Mobycast where we talked in detail about this: https://mobycast.fm/episode/service-to-service-authentication-for-microservice-apis/


One obvious way to do this would be to issue API keys for Service A only to authorized callers, such as Service B. Then, the endpoints on Service A would verify that all requests have a valid API Key header that corresponds to an authorized caller. You can even specify the API Key requirements in your Open API spec if you're building a REST service.

It should be noted that API Keys are not a complete solution for your microservice security, and are only one piece of a larger puzzle. You can read up on what API keys can and can't do for you in articles such as this: https://nordicapis.com/why-api-keys-are-not-enough/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.