OAuth oauth.net

Best Current Practice for Security of Cross-Device Flows

Cross-device flows let a user start on one device and approve on another, for example by scanning a QR code on a TV with their phone, typing in a short code, or accepting a push notification. This Best Current Practice describes how attackers exploit these flows and what implementers can do about it.

When to use this Read this if you implement or deploy the Device Authorization Grant, CIBA, or any other flow where the user carries a code or approval between two devices. It requires a risk assessment before deploying a cross-device flow, and says to avoid these flows when the risks can't be mitigated well enough.

In a cross-device flow, the two devices have no way to authenticate each other. The QR code, user code or push notification travels over an unauthenticated channel, and it is left to the user to judge whether the request in front of them is the one they started. Attackers exploit this with phishing techniques: they start a flow themselves, then persuade the user to scan the code or approve the request. The document calls this Cross-Device Consent Phishing. Because the attacker never needs the user's credentials, these attacks work even when multi-factor authentication is in use.

The same weakness applies to flows that move an existing session to a second device, such as onboarding a mobile app from a logged-in browser. There the attacker tricks the user into handing over the session transfer code, which the document calls Cross-Device Session Phishing.

Best practices

  • Perform a risk assessment before implementing a cross-device flow, weighing the phishing risk against the benefit to users.
  • Avoid cross-device flows if the risks cannot be sufficiently mitigated.
  • Follow the protocol selection guidance. The Device Authorization Grant is the most exposed and should be used only when device constraints rule out the alternatives, and not for sensitive or high-value resources. CIBA is less susceptible, and FIDO2/WebAuthn cross-device authentication proves proximity between the devices.
  • Select mitigations that address the risks identified, such as short-lived and one-time codes, limited scopes, short-lived or sender-constrained tokens, rate limits, trusted devices and networks, and clear user experience.
  • Include proximity between the two devices as one of the mitigations where possible.

The guidance applies to the Device Authorization Grant as well as CIBA, Self-Issued OpenID Provider v2, OpenID for Verifiable Presentations, the Pre-Authorized Code Flow in OpenID for Verifiable Credential Issuance, and other protocols that rely on the user to authenticate the channel between devices. The document also summarizes the results of formal analysis of these protocols.

Related specs