Demo type · 13

Flowchart diagram (step-through)

Use this when you need to explain a multi-step or branching process — where the path forks on a yes/no question and the reader needs to follow one route at a time.

This is a copyable exemplar. Lift the <section id="demo-flowchart"> block — its CSS, SVG, and JS — into a lesson built from assets/lesson-template.html. The design tokens here are copied verbatim from that template; don't restyle them.

1

The big idea


When a request arrives, the server doesn't just trust it. It asks a short series of yes/no questions, and the very first "no" ends the conversation. Get through all of them and you're allowed in; trip on any one and you're denied.

Think of it like… a bouncer at a door. Do you have a wristband? Is it the real one, not a fake? Has it expired? Each "no" turns you away on the spot — only a clean run of "yes" gets you inside.

What each question really is

The "wristband" is a bearer token sent in the Authorization: Bearer <jwt> header. Present? checks the header exists and is well-formed. Valid? verifies the token's signature against the server's public key, so a forged or tampered token fails here. Not expired? compares the token's exp claim to the current clock. Each check is a guard clause: the first failure short-circuits with a 401 and the rest never run.

2

Walk the decision, one step at a time


Pick a request, then press Next to highlight each decision in turn. Watch where a "no" peels off toward Deny and a clean run lands on Allow.

Trace request:
yes yes yes no no no Request arrives Token present? Token valid? Not expired? ✓ Allow — 200 OK ✕ Deny — 401
Read top → bottom. Each diamond is a yes/no gate; a "no" branches right to Deny, a clean run reaches Allow.
Step 0 of 4

Start here

A request lands at the server

Press Next to follow the valid token request through each check. Switch the request above to see how a different token gets stopped.

The same flow as guard clauses

In code, the flowchart is a chain of early returns. The order matters: cheap structural checks run before the expensive cryptographic verification, and every failure returns the same 401 so an attacker can't tell why they were rejected.

function authenticate(req) {
  const token = req.headers.authorization?.replace('Bearer ', '');
  if (!token) return deny(401);            // present?  → no
  const claims = verify(token, PUBLIC_KEY); // throws on a bad signature
  if (!claims) return deny(401);           // valid?    → no
  if (claims.exp < now()) return deny(401); // expired?  → yes (so: no)
  return allow(claims);                     // all clear → 200 OK
}