The OAuth device-code flow solves a genuine problem. A television, console or printer displays a short code, and the user completes sign-in from a browser that is easier to use. Trouble starts when that code belongs to somebody else’s device.
- Pretextmeeting, document or fake support
- Codegenerated for the attacker’s device
- Real pagethe target signs in to the genuine service
- Tokensissued to the attacker’s client
The domain can be completely genuine
In this attack, the adversary starts an authorisation flow and sends the resulting code to the target. The user then opens the identity provider’s real page, enters the code and uses their normal authentication method. The protocol works, and the service identifies the user correctly.
That authentication does not establish who owns the device asking for access. The beneficiary is the client started by the attacker. Advice about checking the padlock therefore answers only part of the problem.
RFC 8628, which defines the flow, already discusses the risk of remote phishing. The code links a browser interaction to a request. It does not prove that the user understands the request in the same way as the client that created it.
A meeting invitation may be enough
In February 2025, Microsoft described a campaign tracked as Storm-2372. Initial contact took place through messaging platforms and moved to fake meeting invitations. The device code was presented as a routine step for joining the meeting. Once the user approved it, the attackers received tokens that could reach account data, including email.
Microsoft’s geopolitical attribution does not change the technical lesson. The interesting sequence is a plausible reason to sign in, an official page and an authorisation granted to the wrong client.
Scaling the technique in 2026
A Microsoft analysis from April 2026 describes a more automated campaign. Messages were tailored to professional roles, and fresh codes were generated only when a target interacted with the lure. This avoided wasting the fifteen-minute validity window before the user arrived.
The expiry mechanism was still working. The attackers simply started the clock at the most useful moment. Automation then monitored the authorisation and checked the tokens it received. Microsoft observed some follow-on activity involving mailbox rules, Microsoft Graph reconnaissance and searches for accounts with financial responsibilities.
Three questions hidden in one screen
The flow brings together three separate decisions:
- has the person proved their identity?
- do they intend to grant access?
- do they recognise the application or device receiving that access?
A strong authenticator mainly deals with the first question. The authorisation policy and interface still have to make the other two understandable. This is why a passkey or FIDO key, valuable as it is, does not settle every form of OAuth abuse.
Remove the path where it is not needed
If an organisation does not use device-code authorisation, blocking the flow removes this route. If the flow is necessary, access can be limited to known populations, clients and resources. Unusual requests and newly issued tokens can then be monitored.
The human guidance can stay short: enter a device code only for a sign-in you have just started on a device you recognise. That rule works much better when the screen clearly names the receiving application and the response team can revoke tokens quickly after a mistake.