📺 Device-code phishing defense
RFC 8628 device sign-in (the "enter this code on your phone" flow) has a phishing gap: an attacker can start the request and just ask YOU to type their code. Showing you where it started — and requiring you to say "yes, I started this" — is what closes it.
This is a SELF-CONTAINED SANDBOX simulation — it never touches the Lab's real device-flow (which mints real, hashed device/user codes and issues real tokens). Here you play both sides: the attacker panel starts a sandbox device-authorization request and gets a real-looking user_code to "send" you; the victim panel is the approval screen you'd see after typing that code — a SANDBOX request grants no real access no matter what you decide.
🎯 Attacker
phish thisStart a device authorization on YOUR "device" (a script, not the real thing) — the whole point is that it names itself and its location. Try the phishing preset, then send the code to the victim panel below.
🛡️ Victim — the approval screen
defend thisYou were sent a code and asked to "enter it to sign in". Type it below — the transparent screen shows WHAT and WHERE before you decide anything.
Look up a code above to see the approval screen.
Your sandbox requests
Two defenses, both real
- Verification transparency — the approval screen shows the client AND where the request actually started, BEFORE you decide anything. A naive "enter this code to sign in" prompt hides exactly the information that would tip you off.
- Explicit confirmation — approving requires affirmatively ticking "I started this" — a blind tap-through is refused server-side (400 confirmation_required), never silently accepted.
X-ray
🩻 X-ray — what actually happened
Your own insert-only audit trail — the real server events, sanitized (never a secret), each linked to the lesson that explains it.