TLS 1.3 & OAuth 2.0

[!WARNING] The Old Model: “Hard outer shell, soft gooey center.” (Firewall protects everything). The New Model (Zero Trust): “Trust no one. Authenticate every request.”

In a modern distributed system, the network is hostile. An attacker might be inside your VPC. You must encrypt traffic in transit (TLS) and verify identity for every single call (mTLS/OAuth).


1. TLS 1.3: The Speed of Security

Transport Layer Security (TLS) encrypts data between Client and Server. Old versions (SSL, TLS 1.0, 1.1) are dead. TLS 1.2 is standard. TLS 1.3 is the future.

1.1 Why TLS 1.3?

  1. Faster Handshake: 1-RTT (Round Trip Time) instead of 2-RTT.
    • The client sends its key shares immediately in the first message (“Client Hello”).
  2. Forward Secrecy: If an attacker steals your server’s private key today, they cannot decrypt traffic captured yesterday.
    • Keys are ephemeral (generated per session via Ephemeral Diffie-Hellman).
  3. 0-RTT Resumption: If you talked to the server recently, you can send data immediately (0-RTT).
    • Risk: Vulnerable to Replay Attacks (Attacker captures the packet and resends it). Use only for idempotent requests (GET).

Interactive Visualizer: TLS 1.3 Handshake

Watch the packets fly. See how the keys are exchanged.

[!TIP] Try it yourself: Click “Start Handshake” to see the 1-RTT exchange. Notice how the Client sends the Key Share immediately.

TLS 1.3 Handshake Simulator

Phase: Idle

💻
Client
🔑 Share A
☁️
Server
🔑 Share B
> Ready to connect.

2. mTLS: Zero Trust for Microservices

We trust the server (via its Certificate). But does the server trust the client? In Mutual TLS (mTLS), both sides present a certificate.

  • Service A (Order) has cert_A.
  • Service B (Payment) has cert_B.
  • If Order calls Payment, Payment verifies cert_A.
  • If a Hacker calls Payment (no cert), the connection is dropped at the TCP layer.

[!TIP] Implementation: Use a Service Mesh (Istio/Linkerd). They handle mTLS automatically (sidecar proxy) so your application code doesn’t have to deal with certificates.


3. OAuth 2.0 & OIDC

Authentication (AuthN): “Who are you?” (User ID). Handled by OIDC (OpenID Connect). Authorization (AuthZ): “What can you do?” (Scopes: read:email, write:order). Handled by OAuth 2.0.

3.1 The Analogy: The Valet Key

You give a Valet your car key.

  • Master Key: Can open trunk, glovebox, drive anywhere. (Password)
  • Valet Key: Can only start the engine and drive 5 miles. (Access Token)

OAuth 2.0 issues Valet Keys (Access Tokens). You never give your Master Key (Password) to a 3rd party app.

3.2 JWT (JSON Web Token)

A Stateless token. It contains the data (Claims) signed by the server. Structure: Header.Payload.Signature.

  • HS256: Symmetric. Same secret key to sign and verify. (Fast, but you must trust the verifier).
  • RS256: Asymmetric. Sign with Private Key, verify with Public Key. (Slower, but safer for public APIs).

Interactive Visualizer: JWT Decoder

Explore the anatomy of a Token. Try to forge a token by changing the payload!

[!TIP] Try it yourself: Click “Simulate Tampering” to change the payload. Notice how the Signature becomes invalid because the hash doesn’t match.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1XzEyMyIsIm5hbWUiOiJKb2huIERvZSIsImFkbWluIjp0cnVlfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
1. Header
{
  "alg": "HS256",
  "typ": "JWT"
}
          
2. Payload
{
  "sub": "u_123",
  "name": "John Doe",
  "admin": true
}
          
3. Signature

HMACSHA256( base64(header) + "." + base64(payload), secret)

Signature Valid ✅

4. Summary

Protocol Purpose Key Feature
TLS 1.3 Encryption in Transit 1-RTT Handshake. Forward Secrecy.
mTLS Service-to-Service Auth Both sides verify certificates. Zero Trust.
OAuth 2.0 Authorization Delegated access (Valet Key).
OIDC Authentication Adds Identity Layer (ID Token) on top of OAuth.
JWT Stateless Token Self-contained. Verify signature to trust data.