Episode 15 · Module 4 · Transport Security

Service-to-Service Authentication

18 May 2026 · 9:42 · Security for Legal SaaS

9:42 9:42

Your API gateway authenticates external users — but what about the services behind it? Alice and Dan cover mutual TLS (mTLS), service mesh architectures (Istio, Linkerd), JWT service tokens, network segmentation for privileged legal data, and practical patterns for teams of every size — from shared secrets to Vault-managed certificates. The unifying principle: Zero Trust means no implicit trust based on network location.

Today’s Lesson

Security for Legal SaaS — Episode 15: Service-to-Service Authentication

Beyond the Perimeter: Internal Trust

Your API gateway authenticates external users. But what about the services behind it? When your document service calls your search index, when your billing service queries your matter database, when your AI inference service requests document content — how do these services prove their identity to each other? The “trusted network” assumption — that anything inside your VPC (Virtual Private Cloud — your isolated private network in the cloud) is legitimate — fails the moment an attacker gains internal access.

Key stat: CrowdStrike reports that lateral movement — attackers pivoting between internal services after initial compromise — is present in 70%+ of advanced threat campaigns. Internal service authentication is what stops initial access from becoming total compromise.

For legal SaaS, the internal services carry the most sensitive data — the privilege classification engine, the document store, the billing system with trust account details. If any internal service can impersonate another, a single compromised container means total data access.

Mutual TLS (mTLS)

Standard TLS authenticates the server to the client. Mutual TLS (mTLS) adds the reverse — the client also presents a certificate, and the server validates it. Both parties prove their identity cryptographically before any data flows.

How mTLS Works Between Services

Step	What Happens
1	Service A connects to Service B
2	Service B presents its certificate (standard TLS)
3	Service B requests Service A’s certificate
4	Service A presents its certificate
5	Service B validates A’s certificate against a trusted CA
6	Connection established — both identities verified

Certificate Management at Scale

Concern	Solution
Issuance	Internal CA (e.g., HashiCorp Vault PKI, cert-manager for Kubernetes)
Short-lived certificates	24-hour validity with automatic rotation
Revocation	Short lifetimes make revocation less critical; combine with OCSP stapling
Identity encoding	Service name in certificate SAN (e.g., `document-service.internal.lawfirm.app`)

Operational reality: Manual certificate management for mTLS at scale is unsustainable. HashiCorp Vault’s PKI engine or Kubernetes cert-manager automates issuance and rotation. Without automation, teams disable mTLS when certificates expire during incidents — creating permanent security gaps.

Service Mesh: mTLS Without Application Changes

A service mesh is an infrastructure layer that handles service-to-service communication — including mTLS — transparently. Your application code doesn’t change; the mesh’s sidecar proxies handle authentication, encryption, and authorization.

Istio and Linkerd

Feature	Istio	Linkerd
mTLS	Automatic between all meshed services	Automatic with zero-config
Authorization policies	Fine-grained (service A can call service B’s /api/documents but not /api/billing)	Service-level only (L4)
Certificate management	Built-in CA (istiod) or external CA integration	Built-in identity with short-lived certs
Complexity	High (Envoy proxies, complex config)	Lower (Rust proxy, simpler model)
Overhead	~2–5ms latency per hop	~1–2ms latency per hop

Authorization Policies (Istio Example)

mTLS proves identity. Authorization policies define what each identity can do:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: document-service-access
spec:
  selector:
    matchLabels:
      app: document-service
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/api-gateway"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/api/documents/*"]
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/ai-inference"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/api/documents/*/content"]

This says: the API gateway can GET any document endpoint. The AI inference service can only GET document content — nothing else. Istio’s security documentation covers the full policy model.

JWT Service Tokens

For services that don’t use a mesh — or for cross-cluster communication — JWT (JSON Web Token) service tokens provide request-level authentication. Each service has a signing key; tokens include claims about the calling service’s identity and permitted scopes.

JWT vs. mTLS

Dimension	mTLS	JWT Service Tokens
Authentication level	Connection (long-lived)	Per-request
Identity proof	Certificate from trusted CA	Signed token with claims
Scope/permissions	Requires separate authz layer	Encoded in token claims
Revocation	Certificate expiry/CRL	Short-lived tokens + token blacklist
Network dependency	Requires TLS termination per service	Works over any transport

Best Practice: Combine Both

Use mTLS for transport security (encryption + connection-level identity). Use JWTs for request-level authorization (scopes, permissions, audit trail). Google’s BeyondProd paper describes this layered approach:

mTLS ensures the network connection is between legitimate services
JWT ensures the specific request is authorized for the claimed operation
Short-lived tokens (5-minute validity) limit the window if a token leaks

Network Segmentation for Privileged Data

Not all internal services should talk to all other services. Network segmentation restricts communication paths so that compromise of one service doesn’t grant access to everything.

Segmentation for Legal SaaS

Zone	Services	Access Rules
Public	API gateway, static assets	Accepts external traffic
Application	Business logic services	Only reachable from gateway
Data	Document store, search index, database	Only reachable from application zone
Privileged	Privilege classification engine, audit log, encryption key service	Only reachable from specific application services with mTLS + authz policy

Critical rule: The privilege classification engine — which determines whether a document is attorney-client privileged — must be in the most restricted zone. If an attacker can call it directly, they can reclassify documents to non-privileged and access them through normal channels. Network segmentation + mTLS + authorization policy = defence in depth.

Practical Patterns for 3–5 Service Architectures

Not every legal SaaS team runs Kubernetes with a service mesh. For smaller deployments (3–5 services), practical options exist:

Option 1: Shared Secret + HMAC (Simplest)

Services share a secret and sign requests with HMAC-SHA256. Simple, no certificate infrastructure. Breaks down at scale — secret rotation requires coordinating all services simultaneously.

Option 2: JWT with Asymmetric Keys (Moderate)

Each service has a private key for signing. Other services have the public key for validation. Auth0’s service-to-service documentation describes the client credentials flow pattern. Scales better — adding a service means distributing one new public key.

Option 3: mTLS with Vault-Managed Certificates (Production)

HashiCorp Vault as internal CA. Each service requests short-lived certificates via the Vault API. Automatic rotation. No mesh overhead. Works with any HTTP framework that supports TLS client certificates.

Recommendation for legal SaaS startups: 3 services or fewer: JWT with asymmetric keys (client credentials flow). Use Auth0 or roll your own with short-lived tokens. 4–8 services: mTLS with Vault or cert-manager. Worth the infrastructure investment. 9+ services or Kubernetes: Full service mesh (Linkerd for simplicity, Istio for fine-grained authz).

Zero Trust: Never Trust the Network

The unifying principle is Zero Trust — no implicit trust based on network location. Every service call is authenticated and authorized, whether it crosses the internet or travels between containers on the same host.

Google’s BeyondCorp pioneered this model: “The network is always hostile. Every request must be authenticated, authorized, and encrypted.”

For legal SaaS, this means the document service doesn’t trust a request just because it came from within the VPC. It validates the caller’s identity (mTLS certificate or JWT), checks authorization (does this service have permission to read this client’s documents?), and logs the access for audit.

Conclusion

Internal services are not inherently trustworthy. A compromised container, a leaked service credential, or a misconfigured network policy can turn internal access into total data breach. Service-to-service authentication — whether through mTLS, JWTs, service mesh, or a combination — ensures that every internal call is identified, authorized, and auditable. For legal SaaS carrying privileged data across service boundaries, this isn’t architecture gold-plating — it’s the control that prevents lateral movement from becoming catastrophic disclosure.

Next episode: Email Security for SaaS — where we’ll cover SPF, DKIM, DMARC, and why your transactional emails might be landing in spam or getting spoofed.

Alice: Welcome back to Security for Legal SaaS. I’m Alice.

Dan: And I’m Dan. Episode 15 — Service-to-Service Authentication. Alice, we covered API gateways last time — authenticating external users at the edge. But what about everything behind the gateway? How do internal services prove who they are?

Alice: This is where most teams have a dangerous assumption baked in — “if it’s inside our network, it’s trusted.” Everything within the VPC — the Virtual Private Cloud, your isolated private network in the cloud — can talk to everything else. The document service can call the billing service. The search indexer can access the privilege classification engine. No authentication between them. The implicit model is: the network perimeter is the security boundary.

Dan: And that assumption breaks when?

Alice: When an attacker gets inside. Which they will, eventually. A compromised container. A leaked service credential. A supply chain attack in a dependency. Once they have a foothold on any internal service, the lack of service-to-service authentication means they can talk to every other service. CrowdStrike reports that lateral movement — attackers pivoting between internal services — is present in over 70% of advanced threat campaigns. The perimeter doesn’t hold forever. Internal authentication is what limits the damage when it doesn’t.

Dan: So what’s the solution? mTLS is the term I hear most often.

Alice: Mutual TLS. In standard TLS, only the server proves its identity — it shows a certificate, the client validates it. In mTLS, both sides present certificates. The client proves its identity to the server too. When your document service calls your search index, the search index knows it’s actually talking to the document service — not to an attacker who happened to gain network access to the same subnet.

Dan: How does that work in practice? Every service needs its own certificate?

Alice: Every service gets a certificate from your internal Certificate Authority. The certificate encodes the service’s identity in the Subject Alternative Name — something like document-service.internal.lawfirm.app. When two services connect, they each present their certificate, validate the other against the trusted CA, and only then establish the connection. Both sides cryptographically prove their identity.

Dan: That sounds like a lot of certificates to manage.

Alice: It is, and that’s the operational challenge. Manual certificate management at scale is unsustainable. Teams that try it end up with expired certificates causing outages, then they disable mTLS during incidents “temporarily” and it never comes back. The solution is automation — HashiCorp Vault’s PKI engine — PKI being Public Key Infrastructure, the system for managing digital certificates — or Kubernetes cert-manager. Kubernetes is the container orchestration platform most teams use to deploy and manage their services. Short-lived certificates — 24-hour validity — with automatic rotation. The certificate expires before an attacker can use a stolen one, and rotation happens without human intervention.

Dan: What about service mesh? Istio, Linkerd — how do those fit in?

Alice: A service mesh handles mTLS transparently. Your application code doesn’t change at all. The mesh deploys a sidecar proxy — a small helper process running alongside each service — in Istio it’s Envoy, in Linkerd it’s their Rust-based proxy. All service-to-service traffic goes through the sidecar, which handles mTLS automatically. You get encryption and authentication between every service with zero code changes.

Dan: And authorization? mTLS tells you who’s calling, but not whether they’re allowed to make that specific call.

Alice: mTLS is authentication — proving identity. Authorization is the next layer. Istio lets you write policies like: “the API gateway service can call GET on document endpoints, but the AI inference service can only call GET on document content — nothing else.” Fine-grained, per-path, per-method access control between services. If a compromised AI container tries to call the billing API, the policy blocks it even though mTLS succeeds — it’s a valid service, just not authorized for that operation.

Dan: What about JWT tokens for service authentication? I’ve seen that pattern too.

Alice: JWTs — JSON Web Tokens, which we covered in Episode 6 — work well for request-level authentication — especially for cross-cluster communication or when you don’t want the overhead of a mesh. Each service has a signing key and issues short-lived tokens with claims about what it’s authorized to do. The receiving service validates the signature and checks the claims. Five-minute token validity limits the window if one leaks. The best approach is actually combining both — mTLS for transport security and connection-level identity, JWTs for request-level authorization with specific scopes.

Dan: For a smaller team — say three to five services, no Kubernetes, no mesh — what’s practical?

Alice: Three tiers of complexity. Simplest — shared secrets with HMAC-signed requests. HMAC — Hash-based Message Authentication Code — is a way to stamp each request with a cryptographic fingerprint proving it came from someone who knows the shared secret. Each service pair shares a secret, signs requests with HMAC-SHA256. Works for three services. Breaks down at scale because rotating secrets requires coordinating all services simultaneously. Middle ground — JWT with asymmetric keys. Each service has a private key for signing, other services have the public keys for validation. Adding a service means distributing one new public key, not updating every secret everywhere. This is the client credentials flow — Auth0 documents it well.

Dan: And for production-grade?

Alice: mTLS with Vault-managed certificates. Vault acts as your internal CA. Each service requests a short-lived certificate via the Vault API using its own authentication — maybe a Kubernetes service account token, maybe an AppRole — Vault’s built-in method for machines to prove their identity. Certificates rotate automatically. No mesh overhead, no sidecar proxies, works with any HTTP framework that supports TLS client certificates. This is where most legal SaaS teams should land once they have four or more services.

Dan: Network segmentation comes into this too, right? Not every service needs to talk to every other service.

Alice: Critical. Even with mTLS, you want defence in depth. Divide your infrastructure into zones — public zone for the API gateway, application zone for business logic, data zone for databases and document stores, and a privileged zone for the most sensitive services. The privilege classification engine — which determines whether a document is attorney-client privileged — lives in the most restricted zone. Only specific application services, authenticated via mTLS with explicit authorization policies, can reach it. Network rules enforce this independently of the authentication layer.

Dan: The principle here is Zero Trust?

Alice: Exactly. Zero Trust means no implicit trust based on network location. Every request is authenticated, authorized, and encrypted — whether it crosses the internet or travels between containers on the same host. Google’s BeyondCorp pioneered this: the network is always hostile. For legal SaaS, this means your document service doesn’t trust a request just because it came from the same VPC. It validates the caller’s mTLS certificate, checks their JWT claims, verifies the authorization policy, and logs the access for audit.

Dan: What happens when teams don’t do this?

Alice: A single compromised service becomes total compromise. An attacker lands on the search indexer through a dependency vulnerability. The search indexer has unrestricted network access to the document store, the billing database, the privilege classification engine. No authentication between services means no access control. The attacker queries every document, every client record, every billing entry. With mTLS and authorization policies, they’re contained. The compromised indexer can only access what the indexer is authorized to access — search indices, nothing more.

Dan: Next episode — Email Security for SaaS. SPF, DKIM, DMARC — and why your transactional emails might be getting spoofed or landing in spam.

Alice: Until then, I’m Alice.

Dan: And I’m Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.