Approve on a separate browser

The browser talks to the server; the device learns the result by polling.

• The device communicates user_code and verification_uri. The user navigates to that URI on a secondary device and authenticates in a TLS-protected session with the authorization server (§3.3). The device does not receive the user’s password in this flow.
• Servers MUST implement an interaction starting with navigation to verification_uri and supplying user_code at some stage. The exact login, code entry, sign-up and additional-check order is server-defined. The first three illustrated states are one possible sequence, not a mandated UI ordering (§3.3).
• The server should explain the action and offer approval or denial. When the interaction is complete, it tells the user to return to the device. Approval changes server-side authorization state; it is not a browser-to-TV callback or immediate access-token delivery (§§3.3–3.5).
• The fourth state is a separate optional shortcut, not a new step after approval. A client MAY convey verification_uri_complete using QR, NFC or another method opening the browser. It is RECOMMENDED to retain the textual verification_uri fallback, and clients MUST still display user_code (§3.3.1). The drawing is a labeled shortcut symbol, not a scannable QR code.
• The server SHOULD show user_code and ask the user to check that it matches the device. The user still gets an approve/deny choice; prefilled codes do not establish possession or trust. A code from an unsolicited message could belong to an attacker’s device (§§3.3.1,5.4).