IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
The device flow — signing in on a TV
Maya's new TV wants her streaming account. Typing a password with a TV remote is slow. So the TV shows a short code, and her phone does the real sign-in. Your goal: follow the device flow and spot a fake code request.
- The device flow is for gadgets with a screen but no good keyboard.
- The TV gets two codes. The long one is for the TV. The short one is for Maya.
- Maya signs in on her phone. Her password never touches the TV.
- The TV polls until she approves. It must obey the wait rules.
- Never type a device code you did not just see on your own screen.
Two codes, two jobs
The device authorization grant (RFC 8628) is made for TVs, game consoles, printers and smart speakers. A gadget is not a safe place for a password. So the flow hands the hard part to a device Maya trusts: her phone.
When the TV starts, the IdP gives it two codes:
🎟️ device_code
The TV's secret ticket for polling. It is long, and Maya never sees it. The TV sends it to the IdP again and again, asking, "Is she done yet?"
🔤 user_code
The short code, such as BQXT-KDZM. The TV shows it with a web address. Maya types it into her phone. That is its only job.
paying by UPI at a shop. The shop shows a QR code. You approve in your own phone app with your own PIN. The shop never sees your PIN. It only waits until it hears "payment done". Scammers use the same trick: "Scan this to get your refund." You approve, and you are the one who pays.
The polling rules
While Maya finds her phone, the TV asks the token endpoint again and again. A TV that asks too fast acts like an attack. The IdP's answers tell the TV what to do:
| What the TV hears | What it means | What the TV does |
|---|---|---|
authorization_pending | Maya has not finished yet. | Wait, then poll again after the interval (5 seconds if none is given). |
slow_down | You are asking too fast. | Add 5 seconds to the interval, then go on. |
access_denied | Maya said no. | Stop. Show a message. |
expired_token | The codes timed out (often 10 to 30 minutes). | Stop. Start over with new codes. |
200 + tokens | Maya approved. 🎉 | Stop polling. You are signed in. |
Why this is safer
A TV is a low-trust device. It is shared, rarely updated, and people can read it over your shoulder. The device flow keeps Maya's password off it. She enters her credential only on her phone, which can hold a passkey. The TV talks to the token endpoint over TLS. The consent screen on her phone names the device, such as "a Smart TV wants access to your playlists". So Maya can spot a request she never started.
Device-code phishing
Attackers love the device flow. A fraudster starts a device login on their own machine. Then they send you the user_code in a message: "Verify your account, enter this code." This is phishing. If you type the code and approve, you sign their device into your account.
Never enter a device code unless you just saw it on your own screen.
Go deeper: defenses and related flows
RFC 8628 asks the IdP to show which device is asking. It also asks the IdP to rate-limit code guesses.
For the opposite case, where a trusted app hands a session to the web, see native-to-web SSO. For the phishing-proof login her phone should use, see passkeys and WebAuthn.
Now play it. The lab shows the TV login step by step and breaks it three ways. After that, you play the TV and the phone yourself.
🧪 Interactive lab — enable JavaScript to play with this one.
See what a real login response contains. Decode and grade an ID token with ID Token Check. Rank the scopes a device asks for with Consent Check.