What happened
OAuth.net presents RFC 10027, “Best Current Practice for Security of Cross-Device Flows,” as guidance for developers and operators using the Device Authorization Grant, CIBA, or other flows in which a user carries a code or approval from one device to another. Examples include scanning a QR code on a TV with a phone, entering a short code, or accepting a push notification.
The core risk is that the two devices have no way to authenticate each other. A QR code, user code, or push approval moves through an unauthenticated channel, leaving the user to decide whether the request shown is the one they initiated. An attacker can start an authorization flow and persuade the user to scan or approve it. RFC 10027 calls this Cross-Device Consent Phishing. Since the attacker does not need the user's credentials, the attack can succeed even when multi-factor authentication is enabled.
The guidance identifies a related risk when an existing session moves to a second device, such as onboarding a mobile app from a browser where the user is already logged in. If an attacker persuades the user to reveal the session-transfer code, the document calls that Cross-Device Session Phishing. OAuth.net says the same underlying weakness applies across protocols that depend on users to authenticate the channel between devices, including the Device Authorization Grant, CIBA, Self-Issued OpenID Provider v2, OpenID for Verifiable Presentations, and the Pre-Authorized Code Flow in OpenID for Verifiable Credential Issuance.
RFC 10027 recommends a risk assessment before deployment and says to avoid cross-device flows if the risks cannot be mitigated sufficiently. Its protocol guidance describes the Device Authorization Grant as the most exposed option, to be used only when device constraints rule out alternatives and not for sensitive or high-value resources. CIBA is described as less susceptible, while FIDO2/WebAuthn cross-device authentication can prove proximity between devices. Mitigations listed include short-lived, one-time codes; limited scopes; short-lived or sender-constrained tokens; rate limits; trusted devices and networks; clear user experience; and, where possible, proof of proximity.
The choice of mitigation is not presented as a checklist that makes every design acceptable. OAuth.net says teams should select controls that address the risks found in their own assessment. Limiting scopes can reduce the authority attached to a mistaken approval, while one-time and short-lived codes narrow the time available to exploit one. Sender-constrained tokens can limit the utility of a token if it is taken out of its intended context. Clear approval interfaces matter because the user remains part of the channel’s authentication mechanism.
OAuth.net also says RFC 10027 summarizes formal analysis of the relevant protocols. Its practical message is therefore broader than a warning about QR codes: any product that asks a person to bridge two devices must account for the fact that visual or numeric handoff data alone does not establish that the devices, requests, and people involved belong together.
What the archive adds
New Runtime’s earlier coverage on 2026-10-22 explained that browser-based OAuth security depends on treating the browser as an exposed public-client environment, not as a place for confidential credentials (OAuth 2.0 for Browser-Based Apps). RFC 10027 is a new fact on the broader OAuth security thread: it addresses trust between devices and the phishing risk in flows that bridge them.
Trend signal
This strengthens the assumption that OAuth-based delegation will become a dominant authentication method for agents: delegation is only useful if the authorization path is resistant to deception. The assumption remains a forecast, not a demonstrated outcome. As agents increasingly trigger or assist access approvals, the identity and context presented at that approval boundary become operational concerns.
Why it matters
Cross-device login is often treated as a convenience feature, but the guidance makes clear that it can transfer authority without transferring credentials. For teams building agent-connected products, that distinction matters wherever a user approves access on a phone, pairs a device with a browser session, or authorizes a workflow through a code. MFA alone does not close the gap if a user is tricked into approving the attacker’s request.
This is especially relevant when an authorization request can unlock data, invoke a service, or establish a durable session. The implementation question is not only whether the code is hard to guess. It is whether the person receiving a code, QR prompt, or push approval can distinguish the intended transaction from an attacker-created one, and whether a mistaken approval grants more authority than necessary.
The practical consequence is to choose the least exposed flow that fits the device constraints, limit what an approval grants, and make approval context legible enough for users to catch mismatches. Security review should include the handoff between devices as a separate trust boundary. A short-lived token, constrained scope, or proximity check can reduce impact, but none replaces assessing whether the flow is appropriate for the resource at all.
Limits and uncertainty
OAuth.net’s page summarizes RFC 10027 but does not provide deployment data, attack rates, or comparative measurements of the listed mitigations. The guidance describes relative exposure among protocols, not a guarantee that CIBA or proximity-capable authentication is safe in every implementation. It also does not quantify usability costs or explain how much risk remains after combining mitigations.
The recommended controls have different operational properties: device support, identity-provider behavior, network assumptions, and user-interface design can all affect an implementation. Teams need to evaluate their own threat models and verify the behavior of their chosen identity provider and client implementation rather than treating a protocol label as a complete security outcome.
Skill to build now
Map one cross-device approval journey this week. Record where the initiating device creates the request, what the approving device shows, what proves or fails to prove proximity, the granted scopes, token lifetime, and whether the code can be reused. Then test the flow with an attacker-created request and a user who has not initiated it. If the user cannot reliably identify the mismatch, reduce authority or select a different flow.
Reader takeaway
Cross-device authorization creates a phishing surface because the devices cannot inherently verify each other. Treat the handoff as a security boundary: assess the risk, choose the least exposed suitable protocol, constrain approvals, and avoid the flow for sensitive resources when safeguards are inadequate.