When building secure APIs, TLS (Transport Layer Security) is a must. But not all TLS setups are created equal. If you’ve ever wondered what exactly two-way TLS is — or when to use it — you’re in the right place.

Let’s break it down in a simple way.

🔐 One-Way TLS (Standard TLS)

We all use it every day.

Every time you log in to your bank account or shop online, you’re using one-way TLS. Your browser verifies the identity of the server via a certificate, usually signed by a trusted Certificate Authority (CA).

  • ✅ Server proves it’s legit
  • ❌ Client doesn’t prove anything

In the API world, this means:

  • Your server (API) presents a TLS certificate
  • Clients connect securely but are not identified by certificate
  • Clients typically authenticate via tokens or credentials

Example:

You expose an API at https://api.company.com, and anyone with a valid access token can call it.

🤝 Two-Way TLS (Mutual TLS)

Sometimes, that’s not secure enough.

Imagine your API should only be called by a trusted partner (like Salesforce, SAP, or internal apps). Even if someone gets the token — without the right certificate, they’re blocked.

That’s where mutual TLS comes in:

  • ✅ Server presents a TLS certificate
  • ✅ Client also presents its own certificate

This creates a mutual trust. Both sides prove who they are — no credentials or tokens needed.

Example:

You configure your Dedicated Load Balancer to trust only Salesforce’s certificate. Any other client is rejected during the TLS handshake.

Two-way TLS diagram

🔍 When to Use Two-Way TLS?

Use it when:

  • You need to guarantee the client identity
  • You want to reduce dependency on access tokens
  • Your APIs are internal or for trusted partners only

Common in:

  • Banking and financial APIs
  • System-to-system integrations
  • Internal microservices in zero-trust networks

🧰 Where Do Certificates Live? Keystore vs. Truststore

To make TLS work, both the client and the server need to store certificates securely.

  • A keystore holds the identity certificate and private key of the system (used to prove who it is).
  • A truststore holds certificates from others that the system should trust.

In one-way TLS, only the server uses a keystore.
In two-way TLS, both client and server use:

  • a keystore (to present their certificate),
  • and a truststore (to verify the other’s certificate).

Think of it like having your passport (keystore) and a list of people you’re willing to trust (truststore).

📌 We’ll go deeper into this and show how to configure both in Anypoint Platform in the next article →.

✅ Summary

Feature One-Way TLS Two-Way TLS
Server certificate ✅ Required ✅ Required
Client certificate ❌ Not used ✅ Required
Trust direction Client trusts server Both trust each other
Used for Public APIs, web Secure internal APIs

Two-way TLS gives you an extra layer of protection, especially when you care about who is calling your API, not just how.

🚀 Ready to implement it?

In the next article →, we walk through how to configure two-way TLS step by step using MuleSoft’s Dedicated Load Balancer.

📘 Enjoying the article?

I'm building IntegrationTrails.io — a platform where you can go beyond reading and truly boost your skills through hands-on learning.

Whether you're a developer, architect, or integration enthusiast, you'll find practical guides, projects, and step-by-step experiences designed to deepen your expertise.

🚀 Check it out → Here