Use mutual TLS when you can run certificate issuance and rotation well, and you want the transport to prove who is calling. Use signed tokens when you need caller claims at the application layer or when proxies break end to end TLS. Many systems use both. Whichever you pick, reject the call when validation cannot finish.
How OWASP frames the choice
The OWASP Microservices Security Cheat Sheet lists two ways for a service to authenticate to its peers.
Mutual TLS: each service holds a key pair and authenticates to peers. The listed challenges are key provisioning, trust bootstrap, revocation and rotation.
Token based: the caller obtains a signed token from a token service and attaches it to each request, and the receiver validates it. Validation is either online or local.
Online or local token validation
Online validation, such as OAuth introspection, adds latency and a dependency on the token service. If you cache results, revocation shows up late, so bound the cache time by how fresh the answer must be.
Local validation uses trusted issuer keys and the right token profile, and checking the signature alone is not enough. The sheet adds that local validation does not catch revocation before expiry unless you use short lifetimes or another revocation mechanism.
A comparison
- What it proves: mTLS proves possession of a key for a certificate. A token proves what the issuer says about the caller, which can include audience and scope.
- Where it runs: mTLS ends at whatever terminates TLS. A token travels in a header and survives proxies, but then needs TLS to protect it. The sheet says token authentication should run over TLS.
- Operations: mTLS needs a certificate authority and automatic rotation. Tokens need a token service, key distribution and short lifetimes.
- Failure mode: an expired certificate breaks connections loudly. A validation outage with tokens can quietly become fail-open if coded carelessly.
Choosing
- Many services, a mesh already in place: mTLS handled by the platform, with authorization by service identity. See service mesh mTLS configuration.
- Calls cross proxies, queues or third parties: tokens, with audience checks.
- High value internal APIs: both, so the transport proves the service and the token carries scope.
For the underlying mechanics read mutual TLS for service to service and OAuth and client credentials for service auth.
One rule for both
The sheet says to reject requests when the required token validation cannot be completed. The same goes for a failed certificate check. Never degrade to anonymous.
Safeguard can help here in a small way. Its SBOM and dependency scanning covers the broker client libraries and service frameworks your code pulls in, and reachability analysis shows which advisories your services actually call. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is mTLS enough on its own?
It authenticates the calling service. You still need authorization on the receiving side to decide what that service may do.
Do tokens need TLS?
Yes. OWASP says token authentication should run over TLS.
Sources
Last reviewed: 19 October 2026.
