Skip to content
H

JWT Auth Learning Demo

This lab makes the hidden pieces visible: registration, cookie issuance, claim decoding, refresh rotation, and protected-route enforcement are all shown in one place.

What to notice

JWT auth feels abstract until you can see the request loop. This page keeps the control surface on the left and the server evidence on the right so each action shows both the user-facing outcome and the underlying token/session changes.

The auth store is local-first, the cookies are httpOnly, and the refresh token rotates every time it is used. That makes it a better teaching setup than a single localStorage token because it shows the actual coordination work a server does.

Best-practice themes

  • Access tokens stay short-lived and are used only for authorization checks.
  • Refresh tokens stay in an httpOnly cookie and rotate on every refresh request.
  • Protected UI and protected APIs each do their own server-side auth read instead of trusting the client.

Direction: cookies + server validation + refresh rotation

Control Surface

Operate the JWT flow

Create a local user

This writes a hashed password and a refresh session into the SQLite auth store.

Session actions

Trigger the same operations a production app would run after the first login.

Phase: idle

Open Protected Page

Auth State

Signed out

User

No active user

Server Time

1/1/1970, 12:00:00 AM

What Changed

Timeline

  • Run an auth action to start the timeline.

Inspector

Latest Request / Response

No request yet.

Inspector

Decoded Access Claims

No access token has been issued yet.

Inspector

Refresh Session Record

No refresh session is stored yet.

Inspector

Protected API Payload

Fetch the protected API to see a server-only payload.

Cookie Policy

Why the cookies are split

  • Access cookie: `httpOnly`, `SameSite=Lax`, short TTL of about 15 minutes for request authorization.
  • Refresh cookie: `httpOnly`, `SameSite=Strict`, longer TTL of about 7 days so rotation can happen without storing tokens in local storage.
  • The browser never receives raw cookie contents in JavaScript. The server returns only masked, decoded metadata so you can inspect the flow safely.

Protected Route

Route preview

`/hobby/auth/protected`

Middleware checks for the access cookie first, then the page performs a real server-side auth read.

Guarded

Middleware

Redirects obvious signed-out visits.

Server Page

Re-reads the cookie header and verifies the session.

Protected API

Returns a payload only for a valid access token.

Compare With WebSocketCompare With SSEBack to Hobbies