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
Device-code phishing
Sam's phone buzzes: "IT here. Enter this code at the login page to finish your setup." There is no fake website and no strange link. If Sam types the code, an attacker gets into his account. This phishing hides in plain sight. Your goal: know the one rule that stops it.
- The attacker starts a real device sign-in, then sends you its code.
- You approve at the real provider, so the address check shows no warning.
- Rule: never enter a code you did not start yourself, just now.
- Providers can name the requester, expire codes fast and switch the grant off.
The message looked helpful. It had a short code like BQXT-KDZM. Sam opened his provider's real login page, padlock and all. He got as far as the code box. Then he stopped. He had never started any setup, so where did the code come from? That one question is the whole defense.
A login made for devices with no keyboard
First meet the honest flow. The device authorization grant signs in a gadget with no real keyboard, like a smart TV. The gadget shows a short user code and a web address. You open that address on your phone, type the code and approve. Meanwhile the gadget keeps polling the provider, asking "approved yet?". When you say yes, it gets its tokens. See The device flow.
The design assumes one thing. The person typing the code is standing at the device that asked for it. If that is false, the flow turns against you.
The twist: whose login is it?
Anyone can start a device flow. The provider gives them a user code, and their session sits there polling. The attacker sends that code to a victim with a believable story, like "IT setup" or "approve to keep access".
The victim types and approves the code at the real provider. The approval attaches to the attacker's session. The provider sends fresh tokens to the attacker. No fake page was built, so "check the web address" gives no warning.
a stranger who hands you a bank form they filled in and says, "Please sign here to finish my setup." The form is real and the bank is real. But your signature approves their request.
The golden rule and the defenses
Never enter or approve a device code unless you started it yourself, just now, on a device in front of you. A code that arrives in a message, an email or a phone call was started by someone else. Refuse it, every time. Providers and admins add more:
🔎 Name the requester
A good approval screen names the app that asks for access. It warns: "Only continue if you started this on your own device." A blank "approve?" becomes "wait, what is that?"
🌍 Check place and speed
The polling device may sit in one country and the approver in another. The provider can flag that mismatch. This is the context thinking of Zero trust.
⏱️ Short code lifetimes
User codes should expire in minutes. Then a stolen code goes stale before a victim can be talked into using it.
🚫 Turn the grant off
Allow the device grant only for apps that need it. A grant that is off cannot be abused.
The tell is always the same: a code you did not start, from a route you did not expect, with urgency. A real device shows you its own code. Nobody needs to send you one. The reverse is also true. Never read out a code your own device shows to a caller. If it does not add up, refuse and report it, as When things go wrong teaches.
Go deeper: What the standard says
The device authorization grant is RFC 8628. Section 5.4 calls this attack "remote phishing". It says the server should show details of the device. It asks for a code lifetime short enough to limit phishing. The attack is a cousin of the redirect tricks in Native-to-web SSO.
Go deeper: A real campaign
In February 2025, Microsoft Threat Intelligence reported a group it called Storm-2372. The group built trust with targets on messaging apps. Then it sent fake meeting invitations that asked the target to sign in with a code the attacker had made. Entering it at the real sign-in page gave the attacker a valid session.
Microsoft advised blocking the device-code flow where possible. Where it is needed, allow it only through access policies. It also advised phishing-resistant MFA, and revoking refresh tokens if you suspect an attack. Source: Microsoft Security blog, 13 February 2025 (later updated).
🧪 Interactive lab — enable JavaScript to play with this one.
See how well a provider's sign-out and revocation would contain a stolen session with Logout Check. Then see which grants a domain exposes with Well-Known Scan.