Service-to-Service Auth (mTLS)
A transport-layer authentication mechanism where both client and server present X.509 certificates to mutually verify each other's identity, commonly used in service mesh architectures.
Description
Mutual TLS (mTLS) extends standard TLS by requiring both the server and the client to present X.509 certificates during the TLS handshake, enabling mutual authentication at the transport layer. In standard TLS, only the server proves its identity to the client. With mTLS, the client also presents a certificate that the server validates against a trusted Certificate Authority (CA), confirming the client's identity before any application data is exchanged. This provides strong, cryptographic identity verification for service-to-service communication.
mTLS is the gold standard for zero-trust network architectures and is a core component of service mesh implementations like Istio, Linkerd, and Consul Connect. In a service mesh, the sidecar proxy (e.g., Envoy) handles mTLS transparently -- each service receives a unique certificate (SPIFFE identity in Istio) automatically provisioned and rotated by the mesh's control plane. This eliminates the need for application-level changes while ensuring all inter-service communication is authenticated and encrypted.
Implementation outside a service mesh requires a Private Certificate Authority (CA) infrastructure to issue and manage client certificates. Use short-lived certificates (24-72 hours) with automatic rotation to minimize the impact of certificate compromise. Options include HashiCorp Vault's PKI secrets engine, AWS ACM Private CA, or cfssl. Configure the server's TLS context to require and verify client certificates (tls.Config{ClientAuth: tls.RequireAndVerifyClientCert} in Go, or the equivalent in your platform). Extract the client identity from the certificate's Subject Alternative Name (SAN) for authorization decisions. Implement certificate revocation checking via CRL or OCSP for handling compromised certificates before expiration.
Prompt Snippet
Implement mTLS for service-to-service authentication using a private CA (HashiCorp Vault PKI or step-ca). Issue short-lived client certificates (72-hour TTL) with SPIFFE-format SAN URIs (spiffe://trust-domain/service-name). Configure the server to require client certificates: in Node.js, use tls.createServer({requestCert: true, rejectUnauthorized: true, ca: [trustedCACert]}). Extract the service identity from the client cert's SAN in middleware and authorize against an allow-list of permitted callers per endpoint. Automate certificate rotation using a sidecar or init container that requests new certs before expiry. For Kubernetes, consider Istio's automatic mTLS or cert-manager for certificate lifecycle management.Tags
Related Terms
Client Credentials Grant
An OAuth 2.0 grant type for server-to-server authentication where the client authenticates directly with its own credentials, without a user context.
API Key Authentication
An authentication method where a unique key is issued to identify and authenticate API consumers, commonly used for server-to-server and third-party integrations.
Auth Middleware / Guards
Reusable middleware or guard components that intercept requests to enforce authentication and authorization policies before they reach route handlers.
Privilege Escalation Prevention
Security measures that prevent users from gaining unauthorized access to resources or functions beyond their assigned permissions, whether by elevating their own role or accessing other users' data.
Audit Logging for Auth Events
Comprehensive, tamper-evident logging of all authentication and authorization events to support security monitoring, incident investigation, and compliance requirements.