One of the most important aspects of service-oriented architectures (or microservice architectures) is cross-service communication.
Such architectures may comprise of very different services— written in different programming languages, deployed in different regions, on different cloud providers, and on entirely different deployment models (think IaaS, PaaS, SaaS).
<aside> <img src="/icons/info-alternate_blue.svg" alt="/icons/info-alternate_blue.svg" width="40px" />
If you’re familiar with security in the cloud and cryptography, you may want to go to the Condensed version of this article before you get bored.
</aside>
Some standards have been developed to underpin communication between services. gRPC is a common choice, as it’s language-agnostic and can be implemented on many platforms. When services are talking to each other, they must authenticate each other.
We can think of this in two parts— when Service A makes a request to Service B:
Service A needs to confirm the authenticity of Service B (Upstream authentication)
So it can be sure it is sending request data to Service B, and not an impostor (i.e. a Man-in-the-Middle attack).
Service B needs to confirm the authenticity of Service A (Downstream authentication)
So it can be sure that a request is legitimate and coming from a trusted service. Allowing untrusted parties to make requests can create vulnerabilities such as a confused deputy problem.
<aside> 💡
Why are upstream and downstream this way around?
Authentication flows in the opposite direction to a request.
E.g. if Service A makes a request to Service B, we say that Service B authenticates itself to Service A (upstream).
When looking at these two flows, HTTPS might come to mind. HTTPS is based on the Transport Layer Security (TLS) protocol— we’ll go into this a bit more later.
HTTPS helps with upstream authentication. In the scenario above, it allows Service A (the caller) to confirm the authenticity of Service B. Here, Service A wants to build a chain of trust— a bit like asking Service B, “who can vouch for you?"
To prove its identity, Service B provides evidence of its origin/authority in the form of a certificate. This certificate is in X.509 format and will be cryptographically signed by a certificate authority.
<aside> ⚠️
This only shows, conceptually, how identity is verified. This is not a representation of the TLS handshake (which involves many more steps).
</aside>
When HTTPS is used by your browser, it checks that a server’s certificate is signed by a reputable certificate authority (there’s a list of trusted authorities on your computer that it matches against).
In a microservice architecture, however, we will already have a specific trusted authority in mind— usually, our organisation’s own Private Certificate Authority. So, when A is making an HTTPS request to B, we can configure it to trust Service B’s certificate only if it has been signed by our own CA.
<aside> <img src="/icons/info-alternate_gray.svg" alt="/icons/info-alternate_gray.svg" width="40px" />
This practice of requiring a signature by a specific party/CA is called certificate pinning.
</aside>
And while HTTPS does help with upstream authentication, it doesn’t allow the party receiving a request to verify the identity of the sender (downstream authentication). There are many approaches you can take to handle the downstream flow— a common idea is to use some sort of a password or secret (like a Bearer token or JWT).
If managed properly, this approach can be secure enough. If, however, the bearer token is obtained by an attacker, they can carry out replay attacks until the token is changed.
An alternative (and generally more secure) approach is mTLS. Mutual TLS (sometimes called Client Certificate Authentication) requires both parties to present certificates in order to establish a connection. This way, both parties can verify each other’s authenticity.