Why S2S auth is different from user auth
Service-to-service authentication is about proving workload identity (a running process) rather than a human’s identity. The main failure mode is not “weak passwords,” but overpowered credentials that get copied into images, logs, CI systems, or shared config and then live far longer than the workload that used them.
Core goals: identity, integrity, and intent
A solid S2S design answers three questions: Who is calling (identity), has the message been altered (integrity), and is the caller allowed to do this (authorization). Many incidents happen when teams only solve the first question (authentication) and assume the other two will follow automatically.
Common patterns (and where they fit)
The most common S2S patterns are: (1) mTLS with workload certificates for strong transport identity, (2) JWT bearer tokens for application-layer claims, and (3) HMAC/API keys (usually as a legacy bridge). mTLS tends to be best for east-west traffic inside controlled networks, while tokens can be better for cross-domain calls, async workflows, and event-driven systems.
mTLS: strong baseline with good automation
Mutual TLS provides cryptographic identity at the connection layer, but the hard part is certificate issuance, rotation, and trust distribution. If you adopt mTLS, plan the operational system first (CA hierarchy, rotation cadence, revocation strategy) rather than treating certificates as static files.
Token-based S2S: useful when you need claims and delegation
Tokens allow you to carry claims like audience, scopes, and expiry, and they can be exchanged or downscoped for different hops. If you’re doing token-based S2S, pair it with a clear model for token exchange and audience restriction; otherwise tokens become “portable super-credentials.” (See Workload OAuth and Token Exchange.)
Service identity standards: SPIFFE/SPIRE and beyond
SPIFFE defines a portable identity document (SVID) that can be used for mTLS and signing, and SPIRE implements issuance and rotation. If you want to avoid bespoke identity formats per platform, SPIFFE is the most common “glue” that works across Kubernetes, VMs, and hybrid environments. (See SPIFFE and SPIRE Architecture.)
Authorization: don’t stop at “the cert is valid”
A valid certificate or token should be the start of authorization, not the end. Map identities to permissions using policy (RBAC/ABAC) and keep the policy close to enforcement (service mesh, API gateway, or in-service libraries), with auditability.
Observability and forensics: make identity visible
S2S auth only helps incident response if identity is consistently logged and traceable. Standardize on logging fields (caller identity, audience, scopes, cert fingerprint, token jti) and propagate identity into traces so you can answer “what called what” quickly.
Practical rollout strategy
Start by picking one “spine” interaction (e.g., a core API) and enforce authentication + authorization there, then expand outward. Use temporary compatibility modes (accept both old API keys and new mTLS/tokens) with hard deadlines, and track progress per service.