mTLS (mutual TLS)
TLS where the client shows a certificate too, so both services prove their identity before any request is accepted.
What it is
Ordinary TLS proves the server's identity to the client. Mutual TLS, or mTLS, adds the reverse check: the client also presents an X.509 certificate, and the server accepts the connection only if that certificate chains to a trusted authority. Both identities are proved during the TLS handshake before an HTTP request reaches the app.
Reach for it between controlled services, partner APIs, and zero-trust networks where a copied bearer token should not be enough. SPIFFE builds on this shape by putting workload identities in certificate URI SANs and rotating short-lived certificates automatically, and Istio does it for you: istiod issues the workload certificates and the sidecars negotiate mTLS without the application code knowing.
mTLS authenticates a connection, not what that identity may do. Map the certificate identity to application permissions, rotate certificates before expiry, and plan how trust roots change. If a load balancer terminates mTLS, the app must trust client identity only through a protected channel from that proxy, never from a header public callers can forge.
Ask AI for it
Configure mutual TLS between these services with TLS 1.3 and an internal CA. Issue separate short-lived X.509 certificates with the serverAuth or clientAuth extended key usage and a SPIFFE ID in the URI SAN, then configure Envoy require_client_certificate: true with explicit trusted CA bundles on both sides. Authorize the caller from the verified URI SAN, never the Common Name. Automate certificate renewal before expiry, support overlapping trust bundles during CA rotation, fail closed on validation errors, and ensure any proxy forwarding client identity can reach the app only over an authenticated private hop.