Mutual TLS Client Authentication

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 mutual TLS and sometimes even called client TLS.

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 X509 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 to re-use the tokens.

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.

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.

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 act 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.

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.