One of the newest methods for securing API communications is OAuth mTLS, combining OAuth 2.0’s authorization capabilities with mTLS’s authentication capabilities. In previous posts we have discussed how OAuth mTLS works and some potential challenges to its adoption. This post, the final in this series, will outline the advantages that OAuth mTLS offers over standard TLS implementations, and how it does more than mTLS by itself.

Simplified Verification

Standard TLS has supplanted SSL as the gold standard for authenticating servers because of its effectiveness in providing a secure channel between servers and clients. But what about situations where it’s important to verify the client’s identity as well as that of the server? An example could be a legal document where it’s important to verify that both parties have signed it and that those signatures are valid.

That’s where mTLS comes in. With mTLS, both the client and the server send digital certificates to prove their identity. Using mTLS provides a simple, straightforward verification process, especially when both certificates are issued by trusted authorities such as Let’s Encrypt or DigiCert.

Additional Identity Check

While mTLS is great for authentication, it has no mechanism for establishing authorization; i.e., that the client actually has the access that it is asking for. OAuth 2.0 handles the authorization step by attaching access tokens to the authentication certificates exchanged in mTLS. These tokens are only valid over a TLS connection with the associated certificate, so the tokens cannot simply be hijacked and used elsewhere, as can happen with regular access tokens. An analogy is the process of boarding an airplane flight, where you typically have to show identification (authentication), as well as your boarding pass (authorization).

Attack Resistance

Even with the encrypted channel that mTLS provides, a clever attacker could still potentially compromise the traffic coming from either the server or the client. In most cases the client is compromised, but some attacks work on servers, too. Examples of attacks that can still be effective over encrypted channels include SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and server-side request forgery (SSRF). One could even go as far as to say attacks like these are built for abusing the trust that methods working at the transport layer such as mTLS provide.

However, requiring multiple forms of identification, especially when they work at different system levels, can make a system less vulnerable to such attacks. With OAuth mTLS an attacker would not only have to compromise one of the machines, but they would also have to somehow obtain valid access tokens for every API request. This would be very difficult to achieve.
OAuth mTLS offers stronger security than either mTLS or OAuth can offer on their own. This is why it is trusted for applications with high-security needs, like service meshes and Open Banking. The effort to implement OAuth mTLS is significant, but when the cost of failure is high, it can be the right solution.