Summary

  • RFC 10027 explains a class of attacks in which the user completes genuine authentication but grants access to a consumption device controlled by an attacker. The missing proof is the context that joins the initiating device to the authorization decision.
  • A valid QR code, user code or push request can carry server-issued data over an unauthenticated channel. It may identify a pending flow without proving who placed it before the user, why it was initiated or where the resulting tokens will be exercised.
  • Daniel Fett is one of the RFC’s three authors, with Pieter Kasselman and Filip Skokan. Their guidance treats proximity, protocol choice, bounded tokens, interface context, detection and recovery as layered controls rather than a single security badge.

The uncomfortable feature of cross-device consent phishing is that the security log may look unusually clean. The user entered a real password. The second factor was satisfied. The authorization server displayed its genuine page. No credential had to be copied into a counterfeit form. The user pressed the real approval button.

The wrong party nevertheless obtained access.

RFC 10027, an IETF Best Current Practice published in August 2026, explains how that result is possible. Pieter Kasselman, Daniel Fett and Filip Skokan separate two devices that product interfaces often collapse into one friendly gesture. The consumption device asks for access: a television, kiosk, whiteboard, workstation or another endpoint. The authorization device is the phone or computer on which the user authenticates and decides. A QR code, short code or push request carries the flow between them.

That handoff is frequently an unauthenticated channel. The code can be perfectly valid while the story around it is false.

A genuine approval for an attacker’s request

Consider a shared display that asks a worker to scan a square code to open company files. In the benign flow, the display starts an authorization request, the phone presents the correct service and the worker grants a bounded scope back to that display. The convenience comes from moving the difficult authentication to a trusted personal device.

An attacker can reverse the ownership of the first step. The attacker initiates a request on a device under their control, obtains its QR or user code and sends that artifact to the worker inside a plausible help-desk message. The worker scans it, reaches the genuine authorization service, performs MFA and approves. The server has authenticated the worker. It may also have validated the pending code. Neither fact proves that the worker is standing in front of the device that initiated the request.

The attack therefore does not contradict MFA. It goes around a question MFA was never asked to answer.

RFC 10027 calls the authorization form Cross-Device Consent Phishing. In a related session-transfer form, the attacker persuades a user to forward a transfer code that moves an already authenticated session. The object stolen is not necessarily a password. It may be an access token, refresh token or usable session on the attacker’s endpoint. That distinction matters to incident response: a password reset may leave the grant, refresh path or active session untouched.

The code has evidence value, but it is narrow. It can show that an authorization server created a pending transaction, that its syntax is valid and perhaps that it has not expired. It does not by itself show who presented it, whether the devices are near each other, whether the user initiated the flow, what the user believes will happen, which endpoint receives the grant or whether the scope is proportionate.

Daniel Fett’s useful separation

Fett’s first-party website describes him as a security consultant specializing in identity and web-protocol security and as a contributor to OAuth and OpenID Connect work in the OpenID Foundation and IETF. The IETF record links him to RFCs on issuer identification, proof-of-possession tokens, OAuth security and selective disclosure as well as RFC 10027. Those credentials explain the continuity of the problem he studies; they do not make him the sole author of this BCP or the operator of any deployed system.

His relevance here is methodological. Formal protocol work refuses to let a successful cryptographic step stand in for an unmodeled relationship. RFC 10027 says formal analysis can uncover attacks and exclude attacks within a defined model, but also states the limit: a model abstracts implementation details, attacker capabilities and security goals. “Proved secure” has to finish the sentence by naming the model.

The same discipline applies to MFA. “Authenticated” has to name the subject, the relying party and the transaction. The person may be authenticated while the initiating device is not. The request may be authentic while its human explanation is not. A token may be sender-constrained while the sender is the attacker’s own endpoint. A user may intend to open files on the office display while the authorization record merely says that a client received access.

This is the control boundary running through the Article: identity, initiation, context, intent, grant, token and resource access are joined steps, not synonyms.

Why the obvious fixes remain partial

RFC 10027 does not answer the problem with a magical replacement code. It catalogues controls and prints the limitation beside each one.

Short-lived or one-time codes reduce replay and mass reuse, but an interactive attacker can wait until the victim responds before generating the code. Rate limits impede campaigns, not a patient targeted request. User education helps, but a carefully prepared malicious flow can be nearly indistinguishable from an ordinary one. A polished genuine authorization page can strengthen the attacker's story rather than expose it.

Proximity is stronger because it asks whether the two devices are physically or logically close. Bluetooth Low Energy, NFC, ultra-wideband, shared networks and location signals can raise the cost of remote substitution. Yet the authorization server cannot simply observe physical distance. VPNs, spoofed location, NAT, mobile data and legitimate remote approvers create false assumptions. Proximity is evidence, not intent.

Trusted devices and networks move the initiation right closer to an accountable operator. They can stop arbitrary endpoints from requesting codes. But trust labels require enrollment, attestation, patching and revocation; an attacker who controls a trusted endpoint may still initiate the flow. Limited scopes and short-lived tokens reduce blast radius after a bad grant without making the grant correct.

Sender-constrained tokens, including proof-of-possession designs, make a token harder to move to another machine. They do not prevent an attacker-controlled consumption device from exercising the key it legitimately generated for its own malicious request. The control solves token export more directly than consent substitution.

The RFC’s best advice is therefore architectural. Use FIDO cross-device authentication when capable devices can establish proximity and origin-bound authentication. Prefer CIBA over the device grant when the server has an established way to contact the user, while still controlling unsolicited requests. Use the OAuth Device Authorization Grant only when stronger options are not viable, and avoid it for sensitive, high-value or business-critical resources unless the additional controls match the risk.

The receipt the approval screen cannot provide alone

Heng Lu’s Running-Code Primacy supplies a useful test outside the narrow OAuth vocabulary: a declaration is not the operational result. Here the declaration is an “approved” event. The running result is which endpoint obtained which capability and what it did next.

A defensible cross-device receipt should preserve the identity and state of the initiating client; the authorization device and method; the exact scope and resource; the human-readable context shown on both devices; proximity or device-binding evidence; the user’s decision; the recipient and constraints of issued tokens; first use; anomaly signals; revocation; and recovery outcome. Privacy requires that these fields be minimized and access-controlled. Accountability requires that they exist somewhere more precise than a green checkmark.

This ledger also clarifies ownership. Product teams decide whether convenience justifies a cross-device flow. Identity teams choose protocols, clients, token lifetimes and scopes. Device and network teams own enrollment, proximity and endpoint state. Fraud teams detect suspicious initiation and consent patterns. Resource servers enforce token constraints. Support and incident teams revoke grants and verify recovery. The user cannot be made the sole authenticator of a channel the system chose not to authenticate.

RFC 10027 is valuable because it refuses the comforting conclusion that more factors automatically mean more context. MFA can prove the user was present. It cannot, without an additional binding, prove which machine deserved the result.

The square code begins a handoff. It is not the authority to finish the story.

Sources