TLS Handshakes and OAuth Flows Are Easier to Learn by Clicking Through Them

There are two security flows every backend developer is supposed to know cold and almost everyone half-remembers: the TLS handshake and the OAuth authorization code flow. Both are sequences of messages between parties. Both are usually taught as static diagrams with numbered arrows. And both produce the same failure in practice: you recognize the diagram but cannot reconstruct it, which matters exactly when a certificate error or a token bug drags you into the details.

Sequences are easier to learn by stepping through them than by staring at them. Below are two free browser simulators, one per flow, and the specific things to do inside each so the sequences stick. Disclosure: I help build these; both are free, no signup.

The TLS handshake, message by message

The SSL/TLS Handshake Simulator plays the handshake as an exchange you advance step by step, message by message, with a toggle between the classic and modern flavors:

• A simplified TLS 1.2 sequence: ClientHello, ServerHello, Certificate, ServerKeyExchange, ServerHelloDone, then ClientKeyExchange, ChangeCipherSpec, Finished (the real protocol sends some of these as separate flights from each side; the simulator collapses them to keep the story readable).
• The TLS 1.3 sequence, where everything after ServerHello is already encrypted (the simulator groups EncryptedExtensions and the certificate messages into one step) and the negotiation lands in a single round trip.

Switching between the two answers a question that diagrams rarely make click: what did TLS 1.3 actually remove? A round trip, plus it encrypts handshake content after ServerHello that 1.2 sent in the clear. The 1-RTT badge on the modern flow is not a detail, it is the reason your handshake latency dropped.

The part worth the most time is the certificate chain panel: Root CA, Intermediate CA, server certificate. The simulator presents verification as a chain walk, which sets up the failure scenarios. Instead of only the happy path, you can run the handshake against:

• an expired certificate
• a hostname mismatch (certificate for the wrong domain)
• an untrusted CA (the chain does not reach a root your client trusts)
• a weak cipher negotiation

Each scenario interrupts the handshake where the real failure would surface, and that mapping is what you need when production throws SSL_ERROR at 2 a.m. Certificate expired and hostname mismatch look identical in a user's browser; once you have watched both fail at the certificate step for different stated reasons, openssl s_client -connect host:443 output stops being noise.

OAuth and OIDC, as a flow you drive

OAuth's authorization code flow with PKCE is longer than the TLS handshake and has more parties: your app, the user, the authorization server, the API. The OAuth/OIDC Flow Simulator puts you in the driver's seat of all of them: you build the authorization request, redirect to login, grant consent, receive the code on the callback, exchange it for tokens, validate the ID token, call the userinfo endpoint, and store the session. Each step shows what actually moves across the wire.

Walking it beats reading it for one big reason: you see which secret exists where. In this server-side flow the authorization code passes through the browser; the tokens do not. The PKCE verifier stays out of the browser-facing authorization request entirely; only its hashed challenge rides along, and the verifier itself appears just once, in the back-channel token exchange. Half of OAuth security is exactly this choreography of what is exposed in which channel, and clicking through it makes the point physically.

The simulator then goes where most OAuth tutorials stop, the unhappy paths:

• Token expiry and refresh: the access token dies, the refresh token gets a new one, and the lifecycle stops being abstract: expiry is a normal event your code handles, not an error.
• Scope mistakes: request too broad a scope, see it flagged, then fix the request down to least privilege. This is the difference between "we ask for everything" and an app users trust.
• The redirect URI lesson: a bad redirect URI is the classic OAuth vulnerability, and the simulator has you send one, watch it get rejected, and fix it, which is the fastest way to understand why exact-match redirect registration is a rule and not a suggestion.

The ID token validation step deserves a special mention because it is the OIDC detail interviews poke at: the ID token is a claim about who logged in (verify it, check issuer, audience, expiry), while the access token is a key to the API. Confusing the two is a recurring class of security bug; the simulator keeps them visibly separate.

How to use the pair

Fifteen minutes each, three passes:

1. Guided pass: step through the happy path once, reading each message.
2. Failure pass: run every failure scenario and note which step it breaks. This is the pass that pays off in production.
3. Reconstruction pass: close the simulator and write the sequence from memory, then check. Recall is the goal; recognition is the trap.

After that, the diagrams in the RFCs and blog posts turn from things you nod at into things you can check for errors.

Both simulators are part of 50+ free DevOps games and simulators. For depth beyond them: the Illustrated TLS 1.3 Connection shows every real byte of a handshake and is the best companion piece on the TLS side, and PortSwigger's free Web Security Academy has hands-on OAuth labs where you exploit the misconfigurations you just learned to avoid.