Mutual TLS Client Authentication
On this page
What is Mutual TLS?
The Transport Layer Security (TLS) is a protocol designed to provide secure communication over the Internet and includes authentication, confidentiality and integrity. When a TLS connection is established the server provides a certificate that the client validates before trusting the server's identity. The server can also request the client to authenticate itself through a client certificate. The latter is referred to as mutual TLS and sometimes even called client TLS or mutual authentication.
Mutual TLS client authentication is a powerful and secure method for verifying both the client and server identities during a TLS handshake. Unlike standard TLS, which only verifies the server, mutual authentication ensures that both ends of the communication are trusted. This method is widely used in API security, OAuth 2.0 flows, and enterprise authentication architectures, where certificate-based client authentication is required.
Certificate-Based Authentication
Certificates are a convenient and widely adopted basis for authentication since no shared secret is required prior to initiating secure communication. A certificate is basically a public key and its related metadata that has been verified and signed by a trusted authority. Its format is defined by the X.509 standard and includes, among others, information about the owner of the certificate (identified by the subject distinguished name or subject alternative name). As the name suggests the public key (and thereby the certificate) is public and can be transmitted over unprotected channels, whereas the corresponding private key is securely stored by the owner. To verify its identity and establish a mutual TLS connection, the client must prove ownership of the private key (proof-of-possession).
Client Authentication with Mutual TLS
Since mutual TLS requires the client to be able to securely store the private key, the authentication mechanism is only suitable for confidential clients. When obtaining the access token at the token endpoint, the authorization server typically requires the client to authenticate before returning the token. In its core specification, the OAuth 2.0 protocol defines a shared-secret method of client authentication but opens up for other authentication methods as well. OAuth 2.0 Mutual-TLS client authentication is an example of an additional method for client authentication. When using mutual TLS, the access token provided by the authorization server can be bound to the client's certificate. Mutual TLS certificate-bound access tokens prevent other (unauthorized) clients from reusing the tokens.
This method is sometimes referred to as X.509 client authentication and is commonly used in secure B2B API integrations where client credentials must be non-repudiable.
There are two distinct methods using mutual TLS client authentication:
- PKI Mutual TLS Method
- Self-Signed Certificate Mutual TLS Method
For OAuth 2.0 Mutual TLS Client Authentication to work, the underlying connection between the client and the authorization server must be protected with mutual TLS, meaning that the TLS handshake performed by the client and the server included the Client Certificate and CertificateVerify messages. This connection is reused by the authorization server for client authentication. As part of the TLS protocol and establishing a mutual TLS session, the server can validate the client's possession of the private key.
When using OAuth 2.0 Mutual TLS Client Authentication, the client must include the client_id in the requests to the authorization server. This is because the authorization server enforces a binding between client and certificate. The authorization server will return an OAuth 2.0 error response with an invalid_client error code in case the certificate presented as part of the mutual TLS connection does not match the one expected for the client_id.
PKI Mutual-TLS Method
This method assumes that the client certificate is part of a public key infrastructure (PKI) that the server trusts. Both parties share a trust anchor. The authorization server validates the certificate chain of the client certificate and optionally its revocation status. During authentication, the server also checks if the client certificate used in the TLS session carries the name that was configured or registered for that individual client. Since the server trusts the PKI, clients can rotate their certificates without having to update the authorization server about the change as long as the name and issuing CA remain the same. This enables scalable certificate rotation and supports strong identity binding for enterprise environments.
Self-Signed Certificate Mutual-TLS Method
If there is no PKI to trust, the client may register a single certificate with the authorization server. During authentication, the server checks if the client uses the same certificate for the TLS session as was configured or registered for that individual client. The server trusts the pinned certificate. The client's organization does not have to maintain any public key infrastructure and can simply use a self-signed certificate for authentication.
This approach is suitable for internal systems or non-production environments, where managing a full public key infrastructure (PKI) may be unnecessary.
Reverse Proxy and TLS Termination
When OAuth services are exposed to the Internet, a secure setup typically includes a reverse proxy in a Demilitarized Zoned (DMZ) that acts as the public facade of the authorization server. In this way, private keys and credentials used by the authorization server can be kept in a private network.
In addition, mutual TLS client authentication can be offloaded to the reverse proxy server. In this case, the reverse proxy will perform the TLS handshake and validate the client certificate. The TLS session is terminated at the reverse proxy, and as a consequence, the authorization server cannot rely on it for the client authentication.
In such architectures, maintaining end-to-end security requires careful handling of client identity propagation, since the mutual TLS session ends at the proxy. TLS handshake logs, HTTP header integrity, and TLS session binding mechanisms should be considered.
Curity Identity Server and Client Certificate Handling
The Curity Identity Server solves this problem by supporting HTTP headers for the transport of a client certificate. The proxy simply adds the client certificate in a configurable HTTP header where the Curity Identity Server can pick it up and check for the name. However, when using mutual TLS client authentication with TLS termination, all the certificate validation is done by the reverse proxy, and the Curity Identity Server solely relies on the data in the HTTP header. To mitigate the risks of attacks, the Curity Identity Server supports basic authentication and/or mutual TLS to authenticate the proxy.
Key Takeaways
In summary, Mutual TLS Client Authentication is a critical component of modern zero-trust architectures and secure API communication. Whether using PKI-based or self-signed certificate authentication, mutual TLS ensures a high degree of confidence in the identity of clients. When combined with OAuth 2.0 or integrated into reverse proxy architectures, it provides a flexible and scalable way to enforce strong client trust without shared secrets.
Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
