Summary

  • RFC 10027 shows how an attacker can initiate a legitimate cross-device flow, hand the genuine code or verification route to a victim, and receive a valid token after the victim authenticates on the real authorization service.
  • Authentication strength is not transaction context. Safe authority requires a retained binding among initiator, client, consumption device, resource, scope, action and consequence, followed by evidence that revocation reached every relying resource.

The attack does not need a counterfeit sign-in page. An attacker opens a legitimate client on a device they control and begins a cross-device authorization flow. The service returns a device code and a human-facing code or QR-like artifact. The attacker gives that artifact to a victim under a plausible story: activate the conference-room display, restore the help-desk session, approve the courier terminal. The victim follows a genuine verification route on a trusted phone, sees the genuine authorization server, completes MFA and presses approve. The server then releases authority to the device that began the flow—the attacker's.

Every cryptographic step can be valid while the human meaning is wrong.

RFC 10027, published as BCP 247 in August 2026, names the problem more precisely than “QR phishing.” It separates cross-device authorization from session transfer and describes cross-device cross-protocol and cross-device same-protocol attacks. Their common surface is an unauthenticated context channel between a Consumption Device, where a request originates, and an Authorization Device, where the user authenticates and consents.

The user code is a routing artifact, not proof of intent

RFC 8628 defines the OAuth device authorization grant for input-constrained devices. The client obtains a device code and user code, displays a verification location, and polls while the user completes authorization elsewhere. It is useful precisely because the first device cannot perform an ordinary browser ceremony.

That separation also divides the evidence. The authorization server can show that a named account authenticated and approved the request attached to a code. It does not follow that the human correctly identified the device that requested the code. A short-lived, one-time, unique code narrows replay and guessing. A live attacker can request it only after the victim has been primed and can use the first valid approval before the window closes.

OAuth 2.0 distinguishes clients, resource owners, authorization servers and resource servers. Cross-device risk appears when the user mentally binds those roles using a story delivered outside the protected transaction. PKCE can bind an authorization-code exchange to the client that created the verifier, but it does not prove that the user intended to empower that client. A technically perfect exchange can preserve the attacker's request with greater integrity.

Strong authentication can strengthen the wrong decision

Origin-bound credentials under WebAuthn Level 3 can resist credential phishing. The victim may therefore authenticate to the correct origin with a hardware-backed key and never disclose a password. That establishes an important fact: who performed the ceremony at which relying party. It does not establish what remote screen, requester, destination or business consequence the victim had in mind.

The distinction matters for executive dashboards. “MFA success” is not a positive risk signal when the disputed fact is request provenance. If a control score treats strong authentication as evidence that the Consumption Device was trusted, it silently joins two claims that the protocol keeps separate.

RFC 10027 therefore treats protocol selection as a first-order mitigation. Where platforms permit it, same-device authorization or FIDO cross-device authentication can remove or strengthen the transferable channel. It recommends the RFC 8628 device grant only when stronger alternatives are not viable because of device constraints, and advises against it for sensitive, high-value or business-critical resources.

Mitigations change different parts of the attack

RFC 10027 groups responses by prevention, disruption and recovery. No practical measure in its comparison covers all three.

Trusted or pre-registered Consumption Devices can stop arbitrary devices from initiating. Authenticate-then-initiate can make the user begin the request from an already authenticated context. Both are powerful when hardware and product architecture support them; neither is a universal property of televisions, terminals or command-line clients.

Proximity checks can raise cost, but location is not identity. Carrier routing and Wi-Fi topology can make adjacent devices look distant; VPNs, relays or spoofed signals can make remote devices look close. Collecting precise device and location information also spends privacy. A proximity failure should be retained with the method, precision and false-positive budget, not flattened into a red or green badge.

Request-initiation verification and out-of-band binding can present the requester, device, resource, scope and action. They become useful only if those facts are actually bound to the request and shown in a way the user can compare. An attacker who captures the second code or scripts the additional channel may reproduce the ceremony. The evidence must say which fact was independently verified, by whom, and against which request identifier.

Token controls cannot repair consent after the fact

DPoP sender-constrains tokens to a client-held key and makes a copied token less portable. If the attacker controls the authorized device and its key, DPoP can faithfully ensure that only the attacker's device exercises the mistakenly granted authority. OAuth 2.0 Security Best Current Practice strengthens the surrounding design, but no post-issuance property retroactively authenticates the user's mental model.

Backchannel designs alter the route. OpenID CIBA avoids asking the user to transfer a displayed code, making it less susceptible to this channel attack. Yet a requester that knows a user identifier may still generate an authorization prompt. Bulk prompts, approval fatigue and a fake-help-desk narrative remain governance problems. “No QR” is not “no context risk.”

Recovery is likewise distributed. Token introspection lets a resource server ask about token state. Token revocation lets a client signal invalidation. Continuous Access Evaluation Profile defines security-event exchange. A successful revocation call or emitted event is evidence that recovery began, not that cached authorization, access tokens, refresh families and downstream sessions all ended.

Build the context ledger before asking for approval

For each flow, preserve the request ID and initiation time; initiator and client ID; client software version; Consumption Device identity, registration and trust state; Authorization Device and authentication method; a hash of the human-facing artifact and its lifetime; the transfer channel; proximity method and result; and the exact requester, device, resource, scope, action, destination and irreversible consequence displayed to the user.

After approval, bind the issued token family and confirmation key to resource-server use. Record anomalies, declines, revocation and introspection times, CAEP delivery and acknowledgement, and positive termination evidence from each relying resource. Keep these states separate:

  • a real user authenticated to a real authorization server;
  • a user approved the request associated with a code;
  • the requester and Consumption Device were identified and trusted;
  • the user saw the material resource, scope and consequence;
  • only the intended device exercised the grant;
  • every dependent session ended during recovery.

Heng Lu's running-code principle applies directly: policy assertions do not outweigh the device and resource-server behavior that actually conveyed access. His account of minimum initial specification and localized future decision supports a narrow common contract for context evidence while leaving products free to choose proximity, device trust or same-device ceremonies. His distinction between formal and practical data control identifies the authority boundary. The authorization server may issue the formal grant; the client key, resource server and surviving session determine who holds practical power.

The phone can prove who approved. Only bound context and downstream execution evidence can prove whose request received authority.