Ways to Secure Service-to-Service Communication

And its tradeoffs explained.

It’s a good day for us as engineers to see how the technology flourish, new apps launched every day, new servers deployed every hour.

But also at some point, think about some of that servers that unknowingly exposing critical and confidential information open to the public. Let’s be honest, may have done that by accident. We might have designed a system poorly that expose those resources to threats.

Making sure only authorized services can access your critical/confidential resources

You have a cron, called PayrollCron, that calculates each employee salary once every month.
It needs list of employees (which is managed by employeeMicroservice).
So once in a month, PayrollCron sends HTTP requests to employeeMicroservice.

Did employeeMicroservice checks whether it is really PayrollCron that asks?

The issue raises when someone unauthorized with malicious intent have access to your local network, knowing that some endpoints are unprotected. Or maybe they got shell access to one of your small server that hasn’t been maintained for some time.

There are several strategies that is commonly used, as follows:

Application Level: Setting up APIKey

Setting up APIKey as authentication for internal calls

This is the most common way I’ve seen. Well, it’s simple, does the job, and works wonderfully. The use of a single identifier is simple, and for some use cases, the best solution. For instance, if an API is limited specifically in functionality where “read” is the only possible command, an API Key can be an adequate solution. Without the need to edit, modify, or delete, security is a lower concern.

APIKey is transmitted freely in the network, and even some of us didn’t change them regularly. Because key has no expiration time.

Anyone who makes a request to a service, transmits their key and in theory, this key can be picked up just as easily as any network transmission. If any point in the entire network is insecure, the entire network is exposed.

Server Level: Token with Expiration

This is the advance solution from static API Key before. We define a schema that requires token to refresh after several period, and it is signed to ensure that the token is not compromised.

Token flows and pseudocode in application-level

You can also add an entity to issue and maintain the token (like separate service to authenticate your microservices), to unburden the server with the signing/verifying job.

Also the good point of this is, you can add payload to the token that could be useful for your development/audit/logging matters. It can gives you good context about who’s calling, and what process is it trying to do, and why.


No need for re architecture or design. It just need a simple library fitted into server’s middleware, create the keys and we are good to go.

Helps error tracing as we can fit useful information in the tokens(but do not put too much in the token or you will sacrifice network speed, since it’s more payload to carry in the network).

It’s flexible and easy to tune. With aud claim, and we can manage who can access what. We can extend this without any major changes to the system.


The keys need to be managed. It adds another complexity to the logic that needs to be maintained. The more keys it managed, harder the credential rotation will be.

Also it makes development a bit more painful. Yup, since we are dealing with services that requires us new tokens once in some period. Imagine your peer asking you everyday: hey Bob, what’s the token again? can you create the token for me? 😮‍💨

Architecture Level: Network Isolation/Segmentation

Network segmentation (often referred to as network isolation) is the concept of taking your network and creating silos within it called VLANs (virtual local area networks) that separates assets in the networked environment based on the function of the asset within the organization or some other schema you define to separate lower security levels from higher more restricted levels.

Illustration for Segmented Network (bottom left)

The common practice is that the VLAN defined and segmented between different functional areas — including completely different network, network virtualizations.

Several sources also mention the benefits of separating traffic between real user/end-user and non-end user traffic. The separation of traffic on a network prevents unwanted and unauthorized users and devices from traveling on a specific network, reducing threats and risks and protecting sensitive data.


When there’s too many servers need to be protected and there’s no time and room for error to maintain tokens, this solution comes handy since it provides flexibility and security.

The use of network isolation between different functional areas also limiting the reach of not only a hacker but also limiting the scope that authorized operations personnel have.

This also eliminates unnecessary complexity to the application, as now the resources are only accessible to whom it’s authorized to. No need further checking of the identity in the application level.


There are only 2 reasons this solution is unachievable:

  • the system is tightly coupled that it needs some work to make it ready to be segmented
  • Cannot bear the extra cost to implement private network/cloud


Before jumping to conclusions, it is better to examine the system first. Requirement gathering is needed to understand the risk, threat, countermeasures that coined to a clear security requirement.


Living to the fullest, one step at a time