Recognize code theft and remote phishing

Verify the device and action; transport security alone does not establish possession.

• A guessed user_code can let an attacker approve the device using the attacker’s own account. That can link the device to the wrong account, with privacy or device-control consequences. It is not the same attack as stealing a victim’s bearer token. User codes SHOULD have enough entropy combined with rate limits and other mitigations (§5.1).
• device_code is machine-facing and should not be displayed to the user (§3.3); a very high entropy code SHOULD be used (§5.2). Guessing it can threaten the device’s eventual token result under the flow in §3.5. Reported technical erratum5840 identifies §5.2’s wording “authorization code”; it is not verified. This guide follows the actual access-token response in §3.5, not a separate authorization-code grant.
• An attacker can initiate a device flow on a device they own, then persuade a victim to enter its code. It is RECOMMENDED to explain that a device is being authorized and confirm possession; the server SHOULD show device information. Complete-URI shortcuts make possession confirmation particularly important (§5.4). TLS can protect a visit to the legitimate server while the user is authorizing the wrong device.
• A nearby observer can spy on the displayed user code and finish authorization first. Devices SHOULD consider the operating environment when communicating codes. Audio or other one-way channels are possible; close-proximity access is RECOMMENDED, not a guarantee of confidentiality or ownership (§§5.5,5.7).
• The browser’s approving-session signals are not automatically evidence of the client device’s trustworthiness. A malicious manufacturer/server can redirect trust to the wrong service. Device apps are generally public clients unless additional protection exists; hardcoded shared credentials alone do not prevent extraction or impersonation (§§5.3,5.6).