RFC 10027
Best Current Practice for Security of Cross-Device Flows
RFC 10027: Best Current Practice for Security of Cross-Device Flows 💖
Okay bestie, this is an IETF document (the Internet Engineering Task Force, the crew that writes the Internet's rulebook 🌈). It's RFC 10027, filed as BCP 247, so its category is Best Current Practice. It's dated August 2026 and has ISSN 2070-1721. The authors are P. Kasselman from Defakto Security, D. Fett from Authlete, and F. Skokan from Okta. The header doesn't list any RFCs that it obsoletes or updates, so nothing gets replaced or patched here 🫶.
Abstract ✨
So this doc is all about the threats hitting cross-device flows, plus practical ways to shut them down 🔒. It also helps you pick the right protocol and sums up formal analysis results that matter for cross-device security. It's basically a security guide for system designers, architects, product managers, security specialists, fraud analysts, and engineers who are building cross-device flows, so if that's your job, this one's for you 💅.
Status of This Memo 📜
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it's been through public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on BCPs, check out Section 2 of RFC 7841.
Info about the current status of this document, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc10027 🦋.
Copyright Notice 🎀
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this document 🧐. Any Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, also as described in the Revised BSD License.
Table of Contents 📚
1. Introduction
1.1. Cross-Device Authorization
1.2. Cross-Device Session Transfer
1.3. Defending Against Cross-Device Attacks
1.4. Conventions and Terminology
2. Best Practices
3. Cross-Device Flow Patterns
3.1. Cross-Device Authorization
3.1.1. User-Transferred Session Data Pattern
3.1.2. Backchannel-Transferred Session Pattern
3.1.3. User-Transferred Authorization Data Pattern
3.2. Cross-Device Session Transfer
3.2.1. Cross-Device Session Transfer Pattern
3.3. Examples of Cross-Device Flows
3.3.1. Example A1: Authorize Access to a Video Streaming
Service (User-Transferred Session Data Pattern)
3.3.2. Example A2: Authorize Access to Productivity Services
(User-Transferred Session Data Pattern)
3.3.3. Example A3: Authorize Use of a Bike Sharing Scheme
(User-Transferred Session Data Pattern)
3.3.4. Example A4: Authorize a Financial Transaction
(Backchannel-Transferred Session Pattern)
3.3.5. Example A5: Add a Device to a Network (Cross-Device
Session Transfer Pattern)
3.3.6. Example A6: Remote Onboarding (User-Transferred Session
Data Pattern)
3.3.7. Example A7: Application Bootstrap (Cross-Device Session
Transfer Pattern)
3.3.8. Example A8: Access a Productivity Application
(User-Transferred Authorization Data Pattern)
3.3.9. Example A9: Administer a System
(Backchannel-Transferred Session Pattern)
4. Cross-Device Flow Exploits
4.1. Cross-Device Authorization Flow Exploits
4.1.1. User-Transferred Session Data Pattern Exploits
4.1.2. Backchannel-Transferred Session Pattern Exploits
4.1.3. User-Transferred Authorization Data Pattern Exploits
4.2. Cross-Device Session Transfer Exploits
4.3. Examples of Cross-Device Flow Exploits
4.3.1. Example B1: Illicit Access to a Video Streaming Service
(User-Transferred Session Data Pattern)
4.3.2. Example B2: Illicit Access to Productivity Services
(User-Transferred Session Data Pattern)
4.3.3. Example B3: Illicit Access to Physical Assets
(User-Transferred Session Data Pattern)
4.3.4. Example B4: Illicit Transaction Authorization
(Backchannel-Transferred Session Pattern)
4.3.5. Example B5: Illicit Network Join (Cross-Device Session
Transfer Pattern)
4.3.6. Example B6: Illicit Onboarding (User-Transferred
Session Data Pattern)
4.3.7. Example B7: Illicit Application Bootstrap (Cross-Device
Session Transfer Pattern)
4.3.8. Example B8: Account Takeover (User-Transferred
Authorization Data Pattern)
4.3.9. Example B9: Illicit Access to Administration
Capabilities Through Consent Request Overload
(Backchannel-Transferred Session Pattern)
4.3.10. Out of Scope
5. Cross-Device Protocols and Standards
6. Mitigating Against Cross-Device Flow Attacks
6.1. Practical Mitigations
6.1.1. Establish Proximity
6.1.2. Short-Lived/Time-Bound QR or User Codes
6.1.3. One-Time or Limited-Use Codes
6.1.4. Unique Codes
6.1.5. Content Filtering
6.1.6. Detect and Remediate
6.1.7. Trusted Devices
6.1.8. Trusted Networks
6.1.9. Limited Scopes
6.1.10. Short-Lived Tokens
6.1.11. Rate Limits
6.1.12. Sender-Constrained Tokens
6.1.13. User Education
6.1.14. User Experience
6.1.15. Authenticate then Initiate
6.1.16. Request Initiation Verification
6.1.17. Request Binding with Out-of-Band Data
6.1.18. Practical Mitigation Summary
6.2. Protocol Selection
6.2.1. IETF OAuth 2.0 Device Authorization Grant
6.2.2. OpenID Foundation Client-Initiated Backchannel
Authentication (CIBA)
6.2.3. FIDO2/WebAuthn
6.2.4. Protocol Selection Summary
6.3. Foundational Pillars
7. Security Considerations
8. IANA Considerations
9. Conclusion
10. References
10.1. Normative References
10.2. Informative References
Contributors
Authors' Addresses1. Introduction ✨
Multi-device flows, where one protocol flow stretches across several end-user devices, are everywhere right now 📱💻. People call them cross-device flows. A classic example: you whip out your phone, scan a QR code on your smart TV, and suddenly the TV's app can get into your video streaming account 📺. QR codes aren't the only option, either. You might also type a PIN code into one device, or approve a push notification on a mobile app.
Here's the tea 🫖. In every case, the user is the one who decides whether to grant authorization. But the QR code or PIN travels over an unauthenticated channel, so it's on you to figure out whether the request is legit. Attackers can totally exploit that gap to get into a user's resources without permission 😬.
To deal with all the different flavours of cross-device flows, this document splits them into two buckets. The first is cross-device authorization flows, where the goal is to authorize access to a resource. The second is cross-device session transfer flows, where the goal is to move an existing session from one device to another 🦋.
1.1. Cross-Device Authorization 🌸
Cross-device authorization flows let a user start an authorization flow on one device (the Consumption Device). Then they use a second device they personally trust (the Authorization Device) to authorize the Consumption Device to access a resource, like a service 🔑. The device authorization grant [RFC8628] and Client-Initiated Backchannel Authentication (CIBA) [CIBA] are two popular examples of these flows.
Now the lowkey problematic part 🙈. In these flows, the Consumption Device and the Authorization Device aren't directly connected, and there's no technical mechanism for the two to set up mutual authentication. So it's up to the user to decide whether the Consumption Device, which is where the authorization request came from, is trustworthy before they scan a QR code, type in a user code, or accept a request pushed to their Authorization Device. The authorization request and its context get passed between the two devices over an unauthenticated channel. The user's judgment is the only thing protecting that channel, and that's it 💀.
Cross-Device Consent Phishing (CDCP) attacks take advantage of that unauthenticated channel between the Consumption Device and the Authorization Device. They use the same social engineering tricks as regular phishing to get into a user's data 🎣.
Lots of public write-ups ([ARTDCPHISH], [DCFLOWPHISH], [NEWDCPHISH], [DEFCON29], [DCATTACK], and [SQPHISH]) show how that unauthenticated channel can be abused with phishing-style social engineering. Here's what makes it different from normal phishing 👀: these attacks don't steal credentials. They skip that step entirely and just convince users to grant authorization from their Authorization Devices. Iconic villain move, honestly 😤.
Once a user grants authorization, the attacker can get into their resources, and sometimes they can grab access and refresh tokens too. With those tokens, the attacker can move laterally to get more access, or sell them for cash 💸. These attacks still work even when multi-factor authentication is turned on, because the attacker isn't trying to capture and replay credentials. They're just persuading the user to hit "approve" 🫠. Periodt, that's why this is such a big deal 💅.
Stay tuned, because the next part is where we keep going 🎀✨
1.2. Cross-Device Session Transfer 🦋
okay so session transfer is when you move your access to a service or network from a device you're already logged into over to a second device, like your phone 📱✨. In this flow, you authenticate and then approve the transfer on one device, which the spec calls the Authorization Device (think a personal computer, web portal, or app 💻). Then the session gets moved over to the device where you'll actually keep using it, the Consumption Device (like a mobile phone or other portable device 🌸).
The session can be handed over by showing you a session transfer code on the Authorization Device, which you then type into the Consumption Device. It gets even smoother if that code is shown as a QR code on the Authorization Device and the Consumption Device scans it 🫶.
Session transfer keeps the state info, including your authentication state, on the second device, so you don't have to set everything up all over again. It's a whole vibe for the user experience 💅. People use these flows to add new devices to a network, onboard customers into a mobile app, or provision new credentials (for example, as described in [OpenID.SIOPv2]) 🧚.
In these cross-device session transfer flows, the channel between the Authorization Device and the Consumption Device is unauthenticated. That's a big deal 🙈.
Cross-Device Session Phishing (CDSP) attacks take advantage of that unauthenticated channel between the Authorization Device and the Consumption Device. The attackers use social engineering to trick the user into sending the session transfer code to them 😭. These attacks borrow techniques from regular phishing, but instead of grabbing passwords, the attackers collect session transfer codes and other artifacts that let them set up a session and then use it to get into a user's data 💀.
1.3. Defending Against Cross-Device Attacks 🌈
This document is a guide for implementers (system designers, architects, product managers, security specialists, fraud analysts, and engineers) building cross-device flows. It helps them defend against CDCP and CDSP attacks. The guidance includes:
- Practical mitigations for susceptible protocols (Section 6.1).
- Protocol selection guidance to avoid using susceptible protocols (Section 6.2).
- Results from formal analysis of susceptible protocols (Section 6.3).
1.4. Conventions and Terminology 💜
Quick vibe check on the all-caps words 🔥: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, just like they do right here.
This spec borrows a bunch of terms from "The OAuth 2.0 Authorization Framework" [RFC6749] 🎀: "access token", "refresh token", "authorization server", "resource server", "authorization request", and "client".
When this document says "social engineering" and "phishing", it means them the way the NIST Computer Security Resource Center Glossary [NISTGlossary] describes them 🧚.
2. Best Practices ✨
This section is the security toolkit 🧰 for keeping cross-device protocols safe from CDCP and CDSP attacks. These are the mechanisms and measures the OAuth Working Group considers best practices at the time this specification was written 👑.
- Implementers MUST do a risk assessment before building cross-device flows, weighing the risks from CDCP and CDSP attacks against the benefits for users.
- Implementers SHOULD avoid cross-device flows if the risks can't be sufficiently mitigated 🙈.
- Implementers SHOULD follow the protocol selection guidance in Section 6.2.
- Implementers MUST pick appropriate mitigations from Section 6.1 to tackle the risks found in their risk assessment.
- Implementers SHOULD include proximity as one of their chosen mitigations, as defined in Section 6.1.1, if it's possible 🌸.
These best practices cover the device authorization grant [RFC8628] too, plus other cross-device buddies like CIBA [CIBA], Self-Issued OpenID Provider v2 [OpenID.SIOPv2], OpenID for Verifiable Presentations [OpenID.VP], the Pre-Authorized Code Flow in [OpenID.VCI], and any other cross-device protocol that relies on the user to authenticate the channel between devices 💜.
Here's the roadmap 🗺️: Section 3 has the details on susceptible protocols, Section 4 has the attack descriptions, and Section 5 gives an overview of existing protocols and standards. Section 6.1 covers the security mechanisms and mitigations, Section 6.2 is the protocol selection guidance, and Section 6.3 has the details from formal analysis of protocols that apply to cross-device flows.
3. Cross-Device Flow Patterns 🧚
Cross-device flows let a user start something on one device (like a smart TV) and finish or continue it on a second device (like a mobile phone). This specification covers two distinct cross-device use cases:
- Cross-Device Authorization: In this use case, the second device is used to authenticate the user or grant authorization before control passes back to the first device, as described in Section 3.1.
- Cross-Device Session Transfer: In this use case, the user is already authenticated on the first device before the session is transferred to the second device, without requiring the user to re-authenticate, as described in Section 3.2.
These flows typically involve using a mobile phone to scan a QR code or enter a user code displayed on the first device (e.g., a smart TV, kiosk, personal computer, or other electronic device) 📱.
3.1. Cross-Device Authorization 💖
In a cross-device authorization flow, a user tries to access a service on one device, referred to as the Consumption Device (e.g., a smart TV). Then they use a second device, referred to as the Authorization Device (e.g., a smartphone), to authorize access to a resource (e.g., access to a streaming service) on the Consumption Device.
Cross-device authorization flows have several benefits, including:
- Authorization on devices with limited input capabilities: End users can approve devices with limited input capabilities to access content (e.g., smart TVs, digital whiteboards, printers, or similarly constrained devices) 🖨️.
- Secure authentication on shared or public devices: End users can authenticate and authorize using a personally trusted device, without risking disclosure of their credentials to a public or shared device 🔐.
- Ubiquitous multi-factor authentication: Enables a user to use multi-factor authentication no matter which device the service is being accessed on (e.g., a kiosk, smart TV, or shared personal computer) 🌟.
- Convenience of a single, portable, credential store: Users can keep all their credentials in a mobile wallet or mobile phone that they already carry with them 👛.
There are three cross-device flow patterns for transferring the authorization request between the Consumption Device and the Authorization Device.
- User-Transferred Session Data Pattern: In this pattern, the user starts the authorization process with the Authorization Server by copying information from the Consumption Device to the Authorization Device, before authorizing an action. By transferring the data from the Consumption Device to the Authorization Device, the user transfers the authorization session. For example, the user may read a code displayed on the Consumption Device and enter it on the Authorization Device, or they may scan a QR code displayed on the Consumption Device with the Authorization Device. The device authorization grant [RFC8628] is an example of a cross-device flow that follows this pattern 🦋.
- Backchannel-Transferred Session Pattern: In this pattern, the OAuth client on the Consumption Device is responsible for transferring the session and initiating authorization on the Authorization Device via a backchannel with the Authorization Server. For example, the user may attempt an online purchase on a Consumption Device (e.g., a personal computer) and receive an authorization request on their Authorization Device (e.g., a mobile phone). CIBA [CIBA] is an example of a cross-device flow that follows this pattern 🌷.
- User-Transferred Authorization Data Pattern: In this pattern, the OAuth client on the Consumption Device triggers the authorization request via a backchannel with the Authorization Server. Authorization data (e.g., a 6-digit authorization code) is displayed on the Authorization Device, which the user transfers to the Consumption Device (e.g., by manually entering it). For example, the user may try to access data in an enterprise application and receive a 6-digit authorization code on their Authorization Device (e.g., a mobile phone) that they enter on the Consumption Device. Note that the use of a 6-digit code is illustrative and reflects common practice at the time of writing. Code length may vary based on usability and risk considerations, and specifying the appropriate length is out of scope for this document 🔢.
3.1.1. User-Transferred Session Data Pattern 🎀
okay bestie, so the device authorization grant [RFC8628] is the classic example of a cross-device flow 💅 where the user literally copies info from the Consumption Device over to the Authorization Device. They either type it in by hand or scan a QR code 📱. Figure 1 shows how it plays out 👇
+--------------+ +---------------+
| Consumption |--(B) Request -------->| |
| Device | QR/User Code | |
| | | |
| |<-(C) Return ----------| |
+------->| | QR/User Code | |
| | | | |
| | |--(D) Poll for ------->| |
(A) User | | Authorization | |
| Starts| | | |
| Flow | |<-(J) Grant -----------| Authorization |
| | | Authorization | Server |
| +--------------+ | |
| | |
+------+ | |
| User | | |
+------+ | |
| | | |
| (E) Scan QR Code or Enter User Code | |
| | | |
| | +--------------+ | |
| +------>| Authorization| | |
| | Device |--(F) Send QR Code --->| |
| | | or User Code | |
| | | | |
| | |<-(G) Request User ----| |
| | | Authentication and| |
| | | Authorization | |
+-(H) User->| | | |
Authenticates| | | |
and Grants | | | |
Authorization| | | |
| |--(I) Authentication ->| |
| | and Authorization| |
| | Completes | |
+--------------+ +---------------+Figure 1: User-Transferred Session Data Pattern 🌸
- (A) The user kicks things off on the Consumption Device 🛒 by starting a purchase, adding a device to a network, or connecting a service to the Consumption Device.
- (B) The Consumption Device asks an Authorization Server for a QR code or user code.
- (C) The Authorization Server sends back a QR code or user code to the Consumption Device. The Consumption Device shows it to the user along with instructions to scan the QR code or enter the user code using the Authorization Device.
- (D) The Consumption Device starts polling the Authorization Server to check whether the user granted authorization 👀.
- (E) The user scans the QR code or enters the user code on the Authorization Device.
- (F) The QR code or user code gets sent to the Authorization Server.
- (G) The Authorization Server validates the QR code or user code, then prompts the user to authenticate and either accept or decline the authorization request.
- (H) The user authenticates and grants authorization using the Authorization Device 🫶.
- (I) The user is authenticated, and authorization is granted to access the user's resources. There may be several additional messages here, depending on the authentication protocol, user interface, and other implementation details 🧚.
- (J) The Authorization Server grants authorization (e.g., by issuing tokens) to the Consumption Device so it can access the user's resources 👑.
3.1.2. Backchannel-Transferred Session Pattern 🦋
CIBA [CIBA] is the one that moves the session over the backchannel 📡. It transfers the session on the backchannel with the Authorization Server, so the Authorization Server can request authorization on the Authorization Device. Figure 2 shows an example of this flow ✨.
+--------------+ +---------------+
+------->| Consumption |--(B) Backchannel ---->| |
| | Device | Authorization | |
| | | Request | |
| | | | Authorization |
| | |<-(F) Grant------------| Server |
| +--------------+ Authorization | |
(A) User | |
| Starts | |
| Flow | |
| | |
+------+ | |
| User | | |
+------+ | |
| | |
(D) User Authenticates | |
| and Authorizes Action | |
| | |
| +--------------+ | |
| | Authorization| | |
| | Device |<-(C) Request User ----| |
+------->| | Authentication | |
| | Authorization | |
| | | |
| |--(E) Authentication ->| |
| | and Authorization| |
| | Completes | |
+--------------+ +---------------+Figure 2: Backchannel-Transferred Session Pattern 🌈
- (A) The user kicks things off on the Consumption Device 🛍️ by starting a purchase, adding a device to a network, or connecting a service to the Consumption Device.
- (B) The client on the Consumption Device asks the Authorization Server for user authorization over the backchannel 📡. It then tells the user to authorize the request on the Authorization Device and waits for the Authorization Server to respond.
- (C) The Authorization Server asks for user authentication and authorization on the user's Authorization Device 📲.
- (D) If the user isn't authenticated yet, they use their Authorization Device to authenticate and grant authorization to the Authorization Server 🔐.
- (E) The user is authenticated, and authorization is granted to access the user's resources. There may be several additional messages here, depending on the authentication protocol, user interface, and other implementation details 💜.
- (F) The Authorization Server grants authorization (e.g., by issuing tokens) to the Consumption Device so it can access the user's resources 👑.
The Authorization Server has a bunch of ways to ask for user authorization 🙌. It might send a push notification to a dedicated app on a mobile phone, or it might send a text message with a link to an endpoint where the user can authenticate and authorize an action 💬.
3.1.3. User-Transferred Authorization Data Pattern ✨
okay so this one is giving "copy the code, paste the code, done" 🎀 Examples of the User-Transferred Authorization Data Pattern include flows where the Consumption Device asks the Authorization Server to send authorization data (like a 6-digit authorization code in a text, an email, or a mobile app) over to the Authorization Device. Once the Authorization Device gets it, the user types it into the Consumption Device. Then the Consumption Device sends that data back to the Authorization Server for validation before it gets access to the user's resources. Figure 3 is the visual, bestie 💅
+--------------+ +---------------+
+------->| Consumption |--(B) Backchannel ---->| |
| | Device | Authorization | |
| | | Request | |
| | | | |
| | |--(F) Send------------>| |
| | | Authorization | |
| | | Data | |
| | | | Authorization |
| | |<-(G) Grant------------| Server |
| +--------------+ Authorization | |
(A) User ^ | |
| Starts | | |
| Flow (E) User Enters | |
| | Authorization | |
+------+ | Data | |
| User |----------+ | |
+------+ | |
^ | |
(D) User Copies | |
| Authorization Data | |
| | |
| +--------------+ | |
| | Authorization| | |
| | Device |<-(C) Send ------------| |
+--------| | Authorization | |
| | Data | |
+--------------+ +---------------+
Figure 3: User-Transferred Authorization Data Pattern(A)The user takes an action on the Consumption Device, like starting a purchase, adding a device to a network, or connecting a service to the Consumption Device. 🛍️(B)The client on the Consumption Device requests user authorization on the backchannel from the Authorization Server.(C)The Authorization Server sends authorization data (e.g., a 6-digit authorization code) to the Authorization Device. Examples of mechanisms that may be used to distribute the authorization data include text messages, email, or a mobile application.(D)The user reads and copies the authorization data (e.g., the 6-digit authorization code) received on the Authorization Device.(E)The user enters the authorization data on the Consumption Device.(F)The Consumption Device sends the authorization data to the Authorization Server.(G)The Authorization Server issues tokens or grants authorization to the Consumption Device to access the user's resources if the authorization data is the same as that sent in step(C). 🎉
The Authorization Server may choose to authenticate the user before sending the authorization data. 🔐
3.2. Cross-Device Session Transfer
Session transfer flows let a user move access to a service or network from a device where they're already authenticated over to a second device, like a mobile phone. 📱 In these flows, the user is authenticated and then authorizes the session transfer on one device, called the Authorization Device (e.g., a personal computer, web portal, or application). Then they transfer the session to the device where they'll keep consuming it, called the Consumption Device (e.g., a mobile phone or portable device). ✨
The session transfer preserves state information, including authentication state, at the second device. That means no extra setup, and the user experience gets a glow-up 🌸 These flows are often used to add new devices to a network, onboard customers to a mobile application, or provision new credentials (e.g., [OpenID.SIOPv2]).
3.2.1. Cross-Device Session Transfer Pattern
okay so here the user is authenticated and kicks things off by authorizing the transfer of the session on the Authorization Device. The Authorization Device requests a session transfer code, which may be rendered as a QR code on the Authorization Device. When the user scans the QR code or enters the code on the Consumption Device where they'd like the session to continue, the Consumption Device presents it to the Authorization Server. Then the Authorization Server transfers the session to the Consumption Device. This may include transferring authentication and authorization state to optimize the user experience. 🧚 This type of flow is used, for example, for adding new devices to networks, bootstrapping new applications, or provisioning new credentials. The Pre-Authorized Code Flow in [OpenID.VCI] is an instance of using this pattern to provision a new credential. Figure 4 shows a typical flow 🦋
+---------------+ +---------------+
+-------->| Authorization | | Authorization |
| | Device |--(B) Session -------->| Server |
| | | Transfer Request | |
| | | | |
| | |<-(C) Session ---------| |
| | | Transfer Code | |
| | | | |
| +---------------+ | |
(A) User | | |
| Starts (D) User Views | |
| Flow | Session Transfer Code | |
| v or QR Code | |
+---------------------------+ | |
| User | | |
+---------------------------+ | |
| | |
(E) Enter Session Transfer Code | |
| or Scan QR Code | |
| | |
v | |
+---------------+ | |
| Consumption | | |
| Device |--(F) Present -------->| |
| | Session Transfer | |
| | Code | |
| | | |
| |<-(G) Return Session --| |
| | Context | |
+---------------+ +---------------+
Figure 4: Cross-Device Session Transfer Pattern(A)The user is authenticated on the Authorization Device and authorizes the transfer of the session to the Consumption Device.(B)The user starts the flow and is authenticated on their Authorization Device before they authorize the transfer of the session to the Consumption Device.(C)The Authorization Server responds with a session transfer code, which may be rendered as a QR code on the Authorization Device.(D)The user views the session transfer code, which may be rendered as a QR code.(E)The user enters the session transfer code on the Consumption Device (e.g., their mobile phone). If the session transfer code is rendered as a QR code, the user scans the QR code with the target Consumption Device.(F)The client on the Consumption Device presents the session transfer code to the Authorization Server.(G)The Authorization Server verifies the session transfer code and returns the session context information needed to resume the session on the Consumption Device. The user resumes the session they initiated and authorized on the Authorization Device and proceeds to access the information on the Consumption Device. 🎀
3.3. Examples of Cross-Device Flows
These examples show the flows above in a bunch of different real-life settings 💖 Corresponding examples of how attackers may exploit these flows are documented in Section 4.3.
3.3.1. Example A1: Authorize Access to a Video Streaming Service (User-Transferred Session Data Pattern)
picture this: an end user sets up a new smart TV and wants to connect it to their favorite streaming service 📺 The streaming service shows a QR code on the TV, and the user scans it with their mobile phone. Then they're redirected to the streaming service provider's web page and asked to enter their credentials to authorize the smart TV to access the streaming service. The user enters their credentials and grants authorization, and after that the streaming service is available on the smart TV. 🍿 Section 4.3.1 illustrates an exploit that applies to this scenario. 😭
3.3.2. Example A2: Authorize Access to Productivity Services (User-Transferred Session Data Pattern)
main character energy: an employee wants to get to their files on an interactive whiteboard in a conference room 🧑💻 The whiteboard displays a URL and a code. The user enters the URL on their personal computer and is prompted for the code. Once they enter the code, they're asked to authenticate and authorize the interactive whiteboard to access their files. The user enters their credentials and authorizes the transaction, and then the interactive whiteboard retrieves their files and lets them interact with the content. 🪄 Section 4.3.2 describes an exploit relevant to this example. 💀
3.3.3. Example A3: Authorize Use of a Bicycle Sharing Scheme (User-Transferred Session Data Pattern)
Okay bestie 🚲 so an end user wants to rent a bicycle from a bicycle sharing scheme. The bicycles are locked up in racks on sidewalks all over the city. To unlock one, the user scans a QR code on the bicycle with their mobile phone 📱. The scan redirects them to the bicycle sharing scheme's authorization page, where they authenticate and authorize payment for renting the bicycle 💳. Once that's approved, the service unlocks the bicycle and the user is off cycling around the city 🌆✨. Section 4.3.3 spills the tea on an exploit that's relevant to this situation 👀.
3.3.4. Example A4: Authorize a Financial Transaction (Backchannel-Transferred Session Pattern)
An end user makes an online purchase 🛍️. Before the purchase goes through, they get a notification on their mobile phone asking them to authorize the transaction. They open their app and authenticate to the service before authorizing the transaction 🔐. Section 4.3.4 describes two exploits relevant to this example 🧐.
3.3.5. Example A5: Add a Device to a Network (Cross-Device Session Transfer Pattern)
An employee gets issued a personal computer that's already joined to a network 💻. They want to add their mobile phone to the network so it can access corporate data and services (e.g., files and email) 📧. They're logged in on the personal computer and start the process of adding the phone. The personal computer shows a QR code that authorizes the user to join their mobile phone to the network. The employee scans the QR code with their phone, and the phone gets joined 🎉. Now they can start accessing corporate data and services on their mobile device 🫶. Section 4.3.5 gives an example of how this flow may be exploited.
3.3.6. Example A6: Remote Onboarding (User-Transferred Session Data Pattern)
A new employee gets sent to an onboarding portal to provide extra info that confirms their identity on their first day with their new employer 🪪. Before the account gets activated, the portal asks them to present a government issued ID, proof of a background check, and proof of their qualifications. The portal displays a QR code, and the user scans it with their mobile phone. That scan invokes the employee's digital wallet on their phone 👛. They're asked to present digital versions of an identity document (e.g., a driving license), proof of a background check by an identity verifier, and proof of their qualifications. The employee authorizes the release of the credentials, and once onboarding is finished, their account is activated 🌸. Section 4.3.6 provides an example of an exploit for this use case.
3.3.7. Example A7: Application Bootstrap (Cross-Device Session Transfer Pattern)
An employee is signed in to an application on their personal computer and wants to bootstrap the mobile application on their phone 📲. They start the cross-device flow and see a QR code in their application. They launch the mobile application on their phone and scan the code, which signs them in to the application on the phone ✨. Section 4.3.7 describes an exploit that applies to this scenario.
3.3.8. Example A8: Access a Productivity Application (User-Transferred Authorization Data Pattern)
A user is opening a Computer-Aided Design (CAD) application 🎨. When they access it, authorization data in the form of a 6-digit authorization code is sent to their mobile phone. They view the 6-digit authorization code on their phone and enter it in the CAD application, which then displays their most recent designs 💖. Section 4.3.8 outlines an attack relevant to this scenario.
3.3.9. Example A9: Administer a System (Backchannel-Transferred Session Pattern)
A network administrator wants to get into an administration portal used to configure network assets and deploy new applications 🛠️. When they try to access the service, they get a notification in an app on their mobile device asking them to confirm access to the portal. They approve the request on their phone and get granted access 🔓. Section 4.3.9 describes how an attacker might exploit this flow 😬.
4. Cross-Device Flow Exploits ✨
Attackers take advantage of the fact that there's no authenticated channel between the two devices in a cross-device flow. They use the same social engineering tricks that show up in phishing attacks 🎣.
In cross-device authorization flows, the attacker uses these social engineering tricks by changing the context in which the authorization request is presented. The goal is to convince the user to grant authorization when they shouldn't 🙈. These attacks are also known as CDCP attacks.
In cross-device session transfer flows, the attacker uses these tricks to convince the user to start a session transfer and send them a session transfer code. Once the attacker has that code, they present it to the Authorization Server to transfer the session and access the user's resources 💀. These attacks are referred to as CDSP attacks.
4.1. Cross-Device Authorization Flow Exploits
Attackers exploit cross-device authorization flows by starting an authorization flow on the Consumption Device. Then they use social engineering to change the context in which the request is presented to the user, so the user grants authorization on the Authorization Device 🎭. The attacker is able to change that context because the channel between the Consumption Device and the Authorization Device is unauthenticated. These attacks are also known as CDCP attacks. 🌈
4.1.1. User-Transferred Session Data Pattern Exploits 🎀
okay so a super common move in cross-device flows is showing the user a QR code or a user code on the Consumption Device (think smart TV 📺), and then they scan it or type it into the Authorization Device (aka their phone 📱). When they scan or copy that code, there's zero proof that it's showing up where the service provider meant it to. Nothing. It's totally on the user to decide whether to trust it. So basically the user ends up doing the job of an authenticated channel between the TV and the phone, and bestie, that is NOT their job 😭
attackers lowkey love this gap 💀 they grab QR codes or user codes (by kicking off the authorization flows themselves 🙈), then use social engineering to change the context the request appears in, so the end user scans it or enters it on their Authorization Device. Once the user approves on the phone, the attacker who started the flow gets access to the user's resources. Figure 5 shows what this looks like.
+--------------+ +---------------+
| Attacker's |--(B) Request -------->| |
| Consumption | QR/User Code | |
| Device | | |
| |<-(C) Return ----------| |
+------->| | QR/User Code | |
| | | | |
| | |--(D) Poll for ------->| |
| | | Authorization | |
| | | | |
| | |<-(L) Grant -----------| Authorization |
| | | Authorization | Server |
| +--------------+ | |
| | | |
(A) Attacker (E) Attacker Copies | |
| Starts | QR or User Code | |
| Flow | | |
+--------------+ | | |
| Attacker |<--+ | |
+--------------+ | |
| | |
(F) Attacker Changes | |
| QR Code/User Code | |
v Context | |
+--------------+ | |
| User | | |
+--------------+ | |
| | | |
| (G) User Is Convinced by the | |
| | Attacker and Scans QR Code | |
| | or Enters User Code | |
| | +--------------+ | |
| +------>| Authorization| | |
| | Device |--(H) Send QR Code --->| |
| | | or User Code | |
| | | | |
| | |<-(I) Request User ----| |
| | | Authentication and| |
| | | Authorization | |
+-(J) User->| | | |
Authenticates| | | |
and Grants | | | |
Authorization| | | |
| |--(K) Authentication ->| |
| | and Authorization| |
| | Completes | |
+--------------+ +---------------+
Figure 5: User-Transferred Session Data Pattern Exploithere's the play-by-play, step by step 💅
(A) The attacker starts the protocol on the Consumption Device (or pretends to be the Consumption Device) by starting a purchase, adding a device to a network, or connecting a service to the Consumption Device. 🛍️
(B) The Consumption Device asks an Authorization Server for a QR code or user code. 📨
(C) The Authorization Server sends back a QR code or user code, and the Consumption Device shows it to the user with instructions to scan the QR code or enter the user code using the Authorization Device. 📲
(D) The Consumption Device starts polling the Authorization Server to see if the user has granted authorization. 🔁
(E) The attacker copies the QR code or user code. 👀
(F) The attacker changes the context where the QR code or user code is displayed, so the user is likely to scan it or use it when finishing the authorization. For example, the attacker could craft an email that includes the user code or QR code and send it to the user. The email might push the user to scan the code or enter the user code by suggesting that doing so would earn them a reward through a loyalty program or prevent the loss of their data. 🎁
(G) The QR code or user code shows up for the user in a context the attacker picked. The user is convinced by the attacker's effort and scans the QR code or enters the user code on the Authorization Device. 🫣
(H) The QR code or user code is sent to the Authorization Server. 🚀
(I) The Authorization Server checks the QR code or user code and prompts the user to authenticate and either accept or decline the authorization request. 🔐
(J) The user authenticates and grants authorization using the Authorization Device. ✅
(K) The user is authenticated with the Authorization Server, and authorization is granted to access the user's resources. (There may be several more messages, depending on the authentication protocol, user interface, and other implementation details.) 🤝
(L) The Authorization Server issues tokens or grants authorization to the Consumption Device, which is under the attacker's control, to access the user's resources. 😱 The attacker gains access to the resources and to any authorization artifacts, like access and refresh tokens. this is the whole ballgame, so yikes 💔
4.1.2. Backchannel-Transferred Session Pattern Exploits ✨
okay so in the Backchannel-Transferred Session Pattern, the client asks the Authorization Server to authenticate the user and get authorization for an action 🔐. This can happen because the user interacted with the Consumption Device, but it can also be triggered without the user touching the Consumption Device at all 😭. That means an authorization request can pop up with zero context about why it's happening or who started it 💀.
Attackers totally lean into that missing context 🙈. They use social engineering to prime the user for an authorization request so the user is more likely to just say yes. The sketchy tactics go all the way from messages that lie about why a request is coming, to spamming a ton of requests at a super inconvenient moment, in the hope that the user grants authorization just to make them stop 🙃. Figure 6 shows what this looks like 🦋.
Being able to trigger authorization requests without user involvement is also a big deal. An attacker can flood the user with a high volume of requests in a short period, which makes it way more likely the user accidentally approves one 💀🔥.
+--------------+ +---------------+
+------>| Attacker's |--(C) Backchannel ---->| |
| | Consumption | Authorization | |
| | Device | Request | |
| | | | Authorization |
| | |<-(G) Grant------------| Server |
| +--------------+ Authorization | |
(B) Attacker | |
| Starts | |
| Flow | |
| | |
+----------+ | |
| Attacker | | |
+----------+ | |
| | |
(A) Attacker Sends | |
| Social Engineering | |
v Message to User (Optional) | |
+----------+ | |
| User | | |
+----------+ | |
| | |
(E) User Authenticates | |
| and Authorizes Action | |
| | |
| +--------------+ | |
| | Authorization| | |
| | Device |<-(D) Request User ----| |
+------>| | Authentication | |
| | and Authorization| |
| | | |
| |--(F) Authentication ->| |
| | and Authorization| |
| | Completes | |
+--------------+ +---------------+
Figure 6: Backchannel-Transferred Session Pattern ExploitHere's the play-by-play 📝:
- (A) The attacker sends a social engineering message to prep the user for the upcoming authorization (optional). 🎀
- (B) The attacker starts the protocol on the Consumption Device (or copies the Consumption Device) by starting a purchase, adding a device to a network, or accessing a service on the Consumption Device. 🧚
- (C) The client on the Consumption Device asks the Authorization Server for user authorization over the backchannel and then waits for a response. ⏳
- (D) The Authorization Server requests user authentication and authorization on the user's Authorization Device. 📲
- (E) If the user isn't authenticated yet, they use their Authorization Device to authenticate and grant authorization to the Authorization Server. 🫶
- (F) The user is authenticated and authorization is granted to access the user's resources. There may be several more messages depending on the authentication protocol, the user interface, and other implementation details. 🌸
- (G) The Authorization Server issues tokens or grants authorization to the Consumption Device, which is under the attacker's control. The attacker now has access to the user's resources and possibly any authorization artifacts, like access and refresh tokens. 👑💀
4.1.3. User-Transferred Authorization Data Pattern Exploits ✨
Okay bestie, so in cross-device flows that follow the User-Transferred Authorization Data Pattern, the client on the Consumption Device starts the authorization request, but the user still has to move the authorization data over to the Consumption Device 🫶 The authorization data can come in different forms, like a numerical value such as a 6-digit authorization code 🔢 The request might happen because the user actually interacted with the Consumption Device, but it can also get triggered without the user touching it at all 👀
Attackers lowkey love this pattern 😭 They combine social engineering to set the scene for the user, then convince the user to hand over the authorization data that got sent to their Authorization Devices (like their phones) 📱 It's giving phishing, except the attacker also gets to trigger the authorization request so the Authorization Server sends it straight to the user 💀
+--------------+ +---------------+
+------->| Consumption |--(C) Backchannel ---->| Authorization |
| | Device | Authorization | Server |
| | | Request | |
| | | | |
| | |--(H) Send------------>| |
| | | Authorization | |
| | | Data | |
| | | | |
| | |<-(I) Grant------------| |
| +--------------+ Authorization | |
| ^ | |
| | | |
(B) Attacker (G) Attacker Enters | |
| Starts | Authorization | |
| Flow | Data | |
| | | |
+------------------------------------------+ | |
| Attacker | | |
+------------------------------------------+ | |
| ^ | |
(A) Attacker (F) User | |
| Sends | Sends | |
| Social | Authorization | |
| Engineering | Data | |
v Message | | |
+------------------------------------------+ | |
| User | | |
+------------------------------------------+ | |
^ | |
| | |
(E) User Copies | |
| Authorization Data | |
| | |
+--------------+ | |
| Authorization| | |
| Device |<-(D) Send ------------| |
| | Authorization | |
| | Data | |
+--------------+ +---------------+Figure 7: User-Transferred Authorization Data Pattern Exploit
- (A) The attacker sends a social engineering message to prime the user for the authorization request they are about to receive, including instructions on what to do with the authorization data once they receive it. 💌
- (B) The attacker initiates the protocol on the Consumption Device (or by mimicking the Consumption Device) by starting a purchase, adding a device to a network, or accessing a service on the Consumption Device. 🛒
- (C) The client on the Consumption Device requests user authorization on the backchannel from the Authorization Server.
- (D) The Authorization Server sends authorization data (e.g., a 6-digit authorization code) to the Authorization Device. Examples of mechanisms that may be used to distribute the authorization data include text messages, email, or a mobile application. The authorization data may be presented as text or a QR code. 📨
- (E) The user is convinced by the social engineering message received from the attacker in step (A) and copies the authorization data received on the Authorization Device. 😬
- (F) The user forwards the authorization data to the attacker. 🙈
- (G) The attacker enters the authorization data (e.g., a 6-digit authorization code) on the Consumption Device.
- (H) The attacker's Consumption Device sends the authorization data to the Authorization Server.
- (I) The Authorization Server grants authorization and issues access and refresh tokens to the Consumption Device, which is under the attacker's control. On completion of the exploit, the attacker gains access to the user's resources. 💀
The unauthenticated channel may also be exploited in variations of the above scenario if there is no session maintained in the channel for steps C and G. In that case, a user (as opposed to the attacker) initiates the flow and is then convinced using social engineering techniques into sending the authorization data (e.g., a 6-digit authorization code) to the attacker instead of using it themselves. The authorization data may be represented as a QR code or text string (e.g., 6-digit authorization code). The attacker then starts the flow and uses the authorization data to obtain the privileges that would have been assigned to the user. 🎭
4.2. Cross-Device Session Transfer Exploits 🦋
Attackers go after cross-device session transfer flows by using the same social engineering tricks they use in phishing attacks 🎣 They convince the user to authorize a transfer of a session, then get the session transfer code or QR code sent their way. Since there's no authenticated channel between the two devices, the attacker can use the session transfer code on their own device to get into the session and access the user's data 😱 These are called CDSP attacks.
+---------------+ +---------------+
+------>| Authorization | | Authorization |
| | Device |--(C) Session -------->| Server |
| | | Transfer Request | |
| | | | |
| | |<-(D) Session ---------| |
| | | Transfer Code | |
| | | | |
| +---------------+ | |
(B) User | | |
| Starts (E) User Views | |
| Flow | Session Transfer Code | |
| v or QR Code | |
+--------------------------------+ | |
| User | | |
+--------------------------------+ | |
^ | | |
| | | |
(A) Attacker (F) User Sends Session | |
| Sends | Transfer or QR Code | |
| Social | to Attacker | |
| Engineering | | |
| Message v | |
+-------------------------------+ | |
| Attacker | | |
+-------------------------------+ | |
| | |
(G) Attacker Enters | |
| Session Transfer Code | |
| or Scans QR Code | |
v | |
+---------------+ | |
| Consumption | | |
| Device |--(H) Present -------->| |
| | Session Transfer | |
| | Code | |
| | | |
| |<-(I) Return Session --| |
| | Context | |
+---------------+ +---------------+Figure 8: Cross-Device Session Transfer Pattern Exploit
- (A) The attacker sends a social engineering message that convinces the user that they should authorize a session transfer, including instructions on what to do with the QR code or session transfer code once they obtained it. 💌
- (B) The user starts the flow and is authenticated on their Authorization Device before they authorize the transfer of the session to the Consumption Device. 🙋♀️
- (C) The client on the Authorization Device requests a session transfer code from the Authorization Server.
- (D) The Authorization Server responds with a session transfer code, which may be rendered as a QR code on the Authorization Device.
- (E) The user views the session transfer code, which may be rendered as a QR code. 👀
- (F) The user sends the QR code or session transfer code to the attacker, following the instructions they received in step (A). 🙈
- (G) Once the attacker receives the QR code, they scan it or enter it on their own Consumption Device.
- (H) The client on the Consumption Device presents the session transfer code to the Authorization Server.
- (I) The Authorization Server verifies the session transfer code and returns the session context information needed to resume the session on the Consumption Device. The attacker resumes the session on their own Consumption Device and is able to access the information that the user authorized on their Authorization Device in step (B). 💀🔥
4.3. Examples of Cross-Device Flow Exploits ✨
Okay bestie, let's watch these attacks in action 👀 These examples apply the attacks to the use cases from Section 3.3, and the vibe is not cute. Attackers copy QR codes and user codes, switch up the context with social engineering, and trick users into granting consent so they can use services, access data, and make payments 💅 Iconic villain behavior, honestly 😭
4.3.1. Example B1: Illicit Access to a Video Streaming Service (User-Transferred Session Data Pattern) 📺
This exploit applies to the use case described in Section 3.3.1.
Picture this 🎬 An attacker gets a smart TV and tries to get into an online streaming service. The smart TV grabs a QR code from the streaming service's Authorization Server and shows it on screen. The attacker copies the QR code and embeds it in an email sent to a huge list of recipients. The email says the streaming service wants to thank them for their loyal support, and that by scanning the QR code they can add a bonus device to their account for no charge 🎁 One recipient opens it and scans the code to claim the loyalty reward. The user performs multi-factor authentication, and when asked if they want a new device added to their account, they authorize it ✅ The attacker's device is now authorized to access the content and obtains an access and refresh token. The access token lets the attacker access content, and the refresh token lets them get fresh tokens whenever the access token expires.
It gets worse 😩 The attacker scales up by emulating a new smart TV, obtaining multiple QR codes, and widening the audience they send them to. Every time a recipient scans and authorizes a new device, the attacker gets an access and refresh token, which they sell for a profit 💸
4.3.2. Example B2: Illicit Access to Productivity Services (User-Transferred Session Data Pattern) 🗂️
This exploit applies to the use case described in Section 3.3.2.
An attacker pretends to be an enterprise application (say, an interactive whiteboard 🖊️) and starts a cross-device flow by requesting a user code and URL from the Authorization Server. They grab a list of potential victims and send an email saying their files will be deleted within 24 hours if they don't follow the link, enter the user code, and authenticate. The email adds that this is the third time they've been notified and their last opportunity to prevent deletion of their work files 😱 One or more employees respond by following the URL, entering the code, and performing multi-factor authentication. Throughout the whole thing, the user is interacting with a trusted user experience, which reinforces the legitimacy of the request ✨ Once these employees authorize access, the attacker obtains access and refresh tokens from the Authorization Server and uses them to access the users' files, perform lateral attacks to obtain access to other information, and keep the session alive by continuously requesting new access tokens. These tokens may be exfiltrated and sold to third parties 💀
4.3.3. Example B3: Illicit Access to Physical Assets (User-Transferred Session Data Pattern) 🚲
This exploit applies to the use case described in Section 3.3.3.
An attacker copies a QR code from a bicycle locked in a city bike rack, prints it on a label, and sticks the label on a bicycle at the other end of the rack 🏷️ A customer walks up to the bicycle with the replicated QR code, scans it, authenticates, and authorizes payment for renting the bike. The rack unlocks the bicycle with the original QR code, and the attacker removes that bicycle and cycles down the street 🚴 Meanwhile, the customer is left frustrated that the bike they were trying to use isn't unlocking [NYC.Bike] 😤 They unlock another bicycle and lodge a complaint with the bicycle rental company.
4.3.4. Example B4: Illicit Transaction Authorization (Backchannel-Transferred Session Pattern) 🏦
These exploits apply to the use case described in Section 3.3.4.
4.3.4.1. Example B4.1: Bulk Authorization Request (Backchannel-Transferred Session Pattern)
An attacker obtains a list of user identifiers for a financial institution and triggers a transaction request for each user on the list. The financial institution's Authorization Server sends push notifications to each user requesting authorization of a transaction. The vast majority ignore the request 🙄 but a small percentage grants authorization by approving the transaction 😬
4.3.4.2. Example B4.2: Fake Help Desk (Backchannel-Transferred Session Pattern)
An attacker obtains a user's contact information and reaches out, pretending to be a representative of the user's financial institution. They say there were a bunch of fraudulent transactions on the account and ask the user to review them by approving or rejecting them. The attacker then triggers a sequence of transactions. The user receives an authorization request for each one and declines them, since they don't recognize them 🙅 The attacker then says the user needs to close the account and transfer all the funds to a new account to prevent further fraudulent transactions. The user receives another authorization request that they approve, or they provide additional authorization information to the attacker, which lets the attacker complete the attack and defraud the user 💔
4.3.5. Example B5: Illicit Network Join (Cross-Device Session Transfer Pattern) 🛜
This exploit applies to the use case described in Section 3.3.5.
An attacker sends a message to all employees of a company, claiming to be from a trusted technology provider investigating a suspected security breach 🕵️ They ask employees to send them the QR code typically used to join a new device to the network, along with detailed steps on how to obtain it. The employee, eager to assist, starts the process to add a new mobile device to the network. They authenticate to the network and obtain a QR code, then send it to the attacker. The attacker scans the QR code and adds their own device to the network 📱 They use this device access as an entry point and perform lateral moves to obtain additional privileges and access to restricted resources 🚨
4.3.6. Example B6: Illicit Onboarding (User-Transferred Session Data Pattern) 🧑💻
This exploit applies to the use case described in Section 3.3.6.
An attacker initiates an employee onboarding flow and obtains a QR code from the onboarding portal to invoke a digital wallet and present a verifiable credential attesting to a new employee's identity 🪪 The attacker obtains a list of potential new employees and sends an email informing them that it is time to present proof of their background check or government-issued ID. The new employee scans the QR code, invokes their digital wallet, and presents their credentials. Once the credentials are presented, the employee's account is activated ✅ The employee portal that the attacker accessed to obtain the QR code displays a message to the attacker with instructions on how to access their account.
4.3.7. Example B7: Illicit Application Bootstrap (Cross-Device Session Transfer Pattern) 🥾
This exploit applies to the use case described in Section 3.3.7.
An attacker sends a message to all employees of a company, claiming to be from the company's IT service provider. They claim they're trying to resolve an application performance issue and ask employees to send them the QR code typically used to transfer a session. The employee, eager to assist, starts the process to transfer a session. They authenticate, obtain a QR code, and send it to the attacker. The attacker scans the QR code with their mobile phone and accesses the user's data and resources 🔓
4.3.8. Example B8: Account Takeover (User-Transferred Authorization Data Pattern) 🎨
This exploit applies to the use case described in Section 3.3.8.
An attacker obtains a user's credentials for a Computer-Aided Design (CAD) application but cannot complete the authorization without the 6-digit authorization code sent to the user's mobile phone 📲 The attacker triggers the authorization request, causing the Authorization Server to send a 6-digit authorization code to the user's mobile phone. The attacker then contacts the user, claiming to be from the CAD application's support desk and investigating a problem with the user's account, and asks the user to read back the code they have just received. Because the attacker has established the context for the code, the user provides it 😩 The attacker enters the code in the CAD application and obtains access to the user's designs.
4.3.9. Example B9: Illicit Access to Administration Capabilities Through Consent Request Overload (Backchannel-Transferred Session Pattern) 🛎️
This exploit applies to the use case described in Section 3.3.9.
An attacker attempts to access an administration portal repeatedly, generating a stream of authorization requests to the network administrator 💥 The attempts are timed to occur while the administrator is asleep 😴 The administrator is woken by the incoming requests on their phone, and in an attempt to stop the notifications, they accidentally approve access. The attacker gains access to the portal 🫠
4.3.10. Out of Scope
In all of the attack scenarios listed above, a user is misled or exploited. For other attacks, where the user is willingly colluding with the attacker, the threat model, security implications, and potential mitigations are very different. For example, a cooperating user can bypass software mitigations on their device, share access to hardware tokens with the attacker, and install additional devices to forward radio signals to circumvent proximity checks 📡
This document only considers scenarios where a user does not collude with an attacker. 🫶
5. Cross-Device Protocols and Standards ✨
okay so cross-device flows that get hit by the attacks we just went through usually have a few things in common 💅
- The attacker can start the flow and mess with the context of an authorization request 👀. For example, they can grab a QR code or user code, or they can ask the user for an authentication/authorization decision.
- The chat between the Consumption Device and Authorization Device is unauthenticated 🙈. So it's on the user to decide whether the QR code, user code, or authentication request is showing up in a legit context. bestie, that is a LOT to put on one person 😭
Protocols that are already standardized (or are in the middle of getting standardized) with these traits include:
- IETF OAuth 2.0 device authorization grant [RFC8628]: A standard for authorization on devices with constrained input capabilities (e.g., smart TVs, printers, and kiosks) 📺. The user code or QR code is shown on the Consumption Device and then entered on a second device (e.g., a mobile phone) 📱.
- OpenID Foundation CIBA [CIBA]: A standard from the OpenID Foundation that lets a device or service (e.g., a personal computer, smart TV, or kiosk) ask the OpenID Provider to start an authentication flow, as long as it knows a valid identifier for the user 🔔. The user finishes the flow on a second device (e.g., a mobile phone). Here there's no QR code to scan and no user code to grab off the Consumption Device. Instead, the OpenID Provider reaches out with a push notification, email, text message, or any other suitable mechanism 💌.
- OpenID for Verifiable Credential Protocol Suite (Issuance, Presentation): OpenID for Verifiable Credentials enables cross-device scenarios by letting users scan QR codes to retrieve credentials (Issuance; see [OpenID.VCI]) or present credentials (Presentation; see [OpenID.VP]) 🪪. The QR code is presented on the device that starts the flow ✨.
- Self-Issued OpenID Provider v2 (SIOPv2): A standard that lets end users present self-attested or third-party attested attributes when it's used with OpenID for Verifiable Credential protocols 🦋. The user scans a QR code presented by the relying party to start the flow.
Cross-device protocols SHOULD NOT be used for same-device scenarios 🙅. If the Consumption Device and Authorization Device are the same device, protocols like OpenID Connect Core [OpenID.Core] and OAuth 2.0 authorization code grant as defined in [RFC6749] are a much better fit 💖. If a protocol supports both same-device and cross-device modes (e.g., [OpenID.SIOPv2] and [OpenID.VP]), the cross-device mode SHOULD NOT be used for same-device scenarios. An Authorization Server MAY choose to block cross-device protocols used in same-device scenarios if it detects that the same device is being used 🚫. Implementers should take into account that in environments that use Network Address Translation (NAT), multiple devices may appear to originate from the same network address. That raises the risk of wrongly thinking a cross-device flow is happening on a single device 🙈.
The W3C Digital Credentials API [W3C.DCAPI] is a standard that defines a browser API for requesting and presenting verifiable credentials 🌈. The API is designed to be used in both same-device and cross-device scenarios. In cross-device scenarios, it can help secure flows against the attacks in this document by making sure the Consumption Device and Authorization Device are actually close to each other (e.g., by leveraging Bluetooth Low Energy (BLE)) 📡. In same-device scenarios, the API can be used without proximity checks.
An Authorization Server MAY use device fingerprinting, network address, or other techniques to detect if a cross-device protocol is being used on the same device 🕵️. If an implementer decides to use a cross-device protocol, or a protocol with a cross-device mode, in a same-device scenario, the mitigations recommended in this document SHOULD be implemented to reduce the risk that the unauthenticated channel gets exploited 🛡️.
6. Mitigating Against Cross-Device Flow Attacks 🧚
The unauthenticated channel between the Consumption Device and the Authorization Device lets attackers change the context in which the authorization request is shown to the user. That shifts the job of authenticating the channel between the two devices onto the end user 😩. End users have "expertise elsewhere," are usually not security experts, and don't understand the protocols and systems they use. So end users are pretty poorly equipped to authenticate the channel between the two devices. Mitigations should focus on:
- Minimizing reliance on the user to make decisions to authenticate the channel.
- Providing better information to help the user make decisions to authenticate the channel.
- Recovering from incorrect channel authentication decisions by users.
To get those outcomes, mitigating CDCP attacks takes a three-pronged approach 🔱:
- Reduce the risks of deployed protocols with practical mitigations.
- Adopt or develop protocols that are less susceptible to these attacks where possible.
- Provide analytical tools to assess vulnerabilities and the effectiveness of mitigations.
6.1. Practical Mitigations 🛠️
A number of protocols that enable cross-device flows, and that are susceptible to CDCP attacks, are already deployed. Their security profile can be improved with practical mitigations that provide defense in depth. Those mitigations either:
- Prevent the attack from being initiated.
- Disrupt the attack once it has been initiated.
- Remediate or reduce the impact if the attack succeeds.
It is RECOMMENDED that one or more of the mitigations be applied when implementing a cross-device flow 💜. Each mitigation, despite its limitations, adds another layer of security that may make an attack harder to start, disrupt attacks already in progress, or reduce the impact of a successful attack 🫶.
6.1.1. Establish Proximity ✨
Okay so the unauthenticated channel between the Consumption Device and the Authorization Device lets attackers grab a QR code or user code in one place and display it somewhere else 😭. That's why proximity-enforced cross-device flows are way more resistant to CDCP attacks than proximity-less ones, no cap 🛡️. Locking down proximity between the two devices also limits an attacker's ability to blast codes at tons of users who are spread all over the map 🌍. Quick heads up: the Authorization Server typically cannot directly tell whether the Consumption Device and Authorization Device are physically close to each other 🙈. So it has to lean on the surrounding systems, the protocols in use, device capabilities, or info it gets from other systems to establish or verify proximity. The Authorization Server can validate what it receives, but it can't independently measure or enforce proximity on its own 💅. There are a bunch of ways to establish proximity, and each one comes with its own perks and downsides ✨:
- Physical connectivity: This is a solid indicator of proximity 💪, but it needs specific ports, cables, and hardware. It may be challenging from a user experience perspective, and it may not be possible in certain settings (e.g., when USB ports are blocked or removed for security purposes) 🔌. Physical connectivity may be better suited to dedicated hardware like FIDO devices that can be used with protocols that are resistant to the exploits described in this document 🔐. Using physically connected devices may introduce additional security risks (e.g., data access or device compromise through malicious peripherals), and assessing and mitigating those risks is beyond the scope of this document 🙃.
- Wireless proximity: Near Field Communications (NFC), Bluetooth Low Energy (BLE), and Ultra Wideband (UWB) services can be used to prove proximity between the two devices 📡. NFC is everywhere in phones for payments 💳, but NFC readers are way less common. BLE is another option for establishing proximity, but it can bring some user experience challenges during setup 😬. UWB standards such as IEEE 802.15.4 and the IEEE 802.15.4z-2020 Amendment 1 enable secure ranging between devices and let them establish proximity relative to each other [IEEE-802.15.4]. FIDO and WebAuthn-based cross-device flows use BLE for wireless proximity and are the RECOMMENDED approach for performing secure cross-device flows (see Section 6.2.3) 👑. For presenting digital credentials, the W3C Digital Credentials API [W3C.DCAPI] can be used 🪪.
- Shared network: Device proximity can be inferred by checking that both devices are on the same network 🏠. The Authorization Server can do this by comparing the network addresses of the device where the code is displayed (the Consumption Device) and the Authorization Device. Or the check can happen on the device itself, as long as the network address is available 📶. This could work if the Authorization Server encodes the Consumption Device's network address in the QR code and uses a digital signature to prevent tampering with the code 🖋️. This does require the wallet to be aware of the countermeasure and to effectively enforce it. It's also super common for a Consumption Device (like a TV 📺) to use Wi-Fi while the Authorization Device (like a phone 📱) uses a mobile network. Even though they're physically in proximity, they don't share a network, so other proximity checks are needed.
- Geolocation: Proximity can be established by comparing geolocation information, either derived from Global Navigation Satellite System (GNSS) coordinates or from a geolocation lookup of IP addresses 🗺️. GNSS-based geolocation may vary in accuracy depending on the user's location. When mapped to national or regional boundaries, it may show a Consumption Device and an Authorization Device in different locations if they're close to a border 🧭. Since relative position matters more than absolute location, implementations should consider relative location to both devices rather than absolute location when determining proximity. IP-based geolocation may be inaccurate along regional or national borders, due to overlapping coverage by different network providers from the respective regions. This can map the Consumption Device to one region while the Authorization Device is on another network from another provider and mapped to a different region 🌏. These inaccuracies may require restrictions to be at a more granular level (e.g., same city, country, region, or continent). Just like the shared network checks, these checks may be performed by the Authorization Server or on the user's device, provided that the information encoded in a QR code is integrity protected using a digital signature 🔏.
Depending on the risk profile and the threat model a system is operating in, it MAY be necessary to use more than one mechanism to establish proximity, to raise the bar for any potential attackers 🧗. Proximity mechanisms that rely on establishing a user's location or identifying a user's device SHOULD be evaluated for their privacy implications within the context of a specific application or deployment 🔍.
Note: Some scenarios need authorization to happen in a different location from the one where the transaction was started 🌍. For example, there may be a primary and secondary credit card holder. Both can initiate transactions, but only the primary holder can authorize them. There's no guarantee the primary and secondary holders are in the same location at the time of authorization. In such cases, proximity can still serve as a risk signal 🚨. For example, while the two holders may normally be in the same city, a sudden presence on different continents may prompt the system to apply additional controls (e.g., transaction value limits or transaction velocity limits), or to fold proximity information into a broader risk management decision 🧠.
Limitations: Proximity mechanisms make CDCP attacks harder to pull off 💪. However, depending on how the proximity check is performed, an attacker may be able to get around the protection 😈. The attacker can use a VPN to simulate a shared network or spoof a GNSS position. For example, the attacker can request the location of the end user's Authorization Device through browser APIs, then simulate the same location on their Consumption Device using standard debugging features available on many platforms 🕵️. Relying on IP address mapping can also degrade user experience when a VPN is used on the Consumption Device or the Authorization Device 😵. In those cases the devices may appear to be in different locations, requiring additional user guidance or alternative mechanisms to establish proximity 🧭.
6.1.2. Short-Lived/Time-Bound QR or User Codes ⏳
The impact of an attack can be reduced by making QR or user codes short-lived 🥀. If an attacker obtains a short-lived code, the duration during which the unauthenticated channel can be exploited gets smaller, which potentially increases the cost of a successful attack 💸. This mitigation can be implemented on the Authorization Server without changes to other system components ✅.
Limitations: There's a practical limit to how short a user code can be valid, because of network latency and user experience limitations (the time it takes to enter a code, to complete authentication, or to re-enter codes or re-authenticate due to an error) ⏱️. More sophisticated CDCP attacks counter the effectiveness of short-lived codes by convincing a user to respond to a phishing email and only requesting the QR or user code once the user clicks on the link in that phishing email 🎣 [SQPHISH].
6.1.3. One-Time or Limited-Use Codes 🎟️
By enforcing one-time use or limited use of user or QR codes, the Authorization Server can limit the impact of attacks where the same user code or QR code is sent to multiple victims 🎯. One-time use may be achieved by including a nonce or date stamp in the user code or QR code, which the Authorization Server validates when the user scans the QR code against a list of previously issued codes 📋. This mitigation can be implemented on the Authorization Server without changes to other system components.
Limitations: Enforcing one-time use may be difficult in large, globally distributed systems with low latency requirements, in which case short-lived tokens may be more practical 🌐. One-time use codes may also have an impact on the user experience. For example, a user may enter a code, but their session could be interrupted before the access request is completed 😩. If the code is a one-time use code, they would need to restart the session and obtain a new code, since they won't be allowed to enter the same code a second time. To avoid this, implementers MAY allow the same code to be presented a few times 💡.
6.1.4. Unique Codes 🦄
By issuing unique user or QR codes, an Authorization Server can detect if the same codes are being repeatedly submitted 🕵️♀️. This may be interpreted as anomalous behavior, and the Authorization Server MAY choose to decline issuing access and refresh tokens if it detects the same codes being presented repeatedly 🚫. This may be achieved by maintaining a deny list that contains QR codes or user codes that were previously used 📕. The Authorization Server MAY use a sliding window equal to the lifetime of a token if short-lived/time-bound tokens are used (see Section 6.1.2) ⏲️. This will limit the size of the deny list. This mitigation can be implemented on the Authorization Server without changes to other system components.
Limitations: Maintaining a deny list of previously redeemed codes, even with a sliding window, may have an impact on the latency of globally distributed systems 🐢. One alternative is to segment user codes by geography or region and maintain local deny lists 🗺️.
6.1.5. Content Filtering 🛡️
Okay so attackers love to mess with the unauthenticated channel 😤. They change the context of the user code or QR code and then send a message to a user (email, text messaging, instant messaging, or other communication mechanisms) 📩. Content filtering (e.g., anti-spam filter) can block these messages so they never reach the end users 🚫. It's also possible to fine-tune content-filtering solutions to spot artifacts like QR codes or user codes sitting inside a message that went out to a bunch of recipients, because the attacker is counting on at least one of them getting convinced and granting access to restricted resources 🙃. Spray-and-pray behaviour is giving scam energy 💀.
Limitations: Some scenarios may require legitimate retransmission of user data, QR codes, and authorization data (e.g., retries) 🔁. To keep legit scenarios from breaking, content filters may use a threshold and allow a limited number of messages with the same QR or user codes to be transmitted before they interrupt delivery 🎯. Content filtering may also be fragmented across multiple communications systems and communication channels (email, text messaging, instant messaging, or other communication mechanisms), which makes attacks spread over several channels harder to detect or interrupt, unless there is a high degree of integration between content-filtering systems 🧩.
6.1.6. Detect and Remediate 🕵️♀️
The Authorization Server may be able to detect misuse of the codes due to repeated use as described in Section 6.1.4, as an input from a content-filtering engine as described in Section 6.1.5, or through other mechanisms such as reports from end users 👀. If an Authorization Server determines that a user code or QR code is being used in an attack, it MAY choose to invalidate all tokens issued in response to these codes and make that information available through a token introspection endpoint (see [RFC7662]) 🚨. In addition, it may notify resource servers to stop accepting these tokens or to terminate existing sessions associated with these tokens using Continuous Access Evaluation Protocol (CAEP) messages [CAEP] using the Shared Signals Framework (SSF) [SSF] or an equivalent notification system. ✨
Limitations: Detection and remediation require that resource servers are integrated with security eventing systems or token introspection services. This may not always be practical for existing systems and may need to be targeted to the most critical resource services in an environment 🏰.
6.1.7. Trusted Devices 🔐
If an attacker is unable to initiate the protocol, they can't get a QR code or user code that's useful for the attacks described in this document 🙅♀️. By restricting the protocol to only be executed on devices trusted by the Authorization Server, it blocks attackers from using arbitrary devices or mimicking devices to start the protocol 🤖🚫.
Authorization Servers MAY use different mechanisms to establish which devices they trust for cross-device flows 🧐. This includes limiting cross-device flows to specific device types such as interactive whiteboards or smart TVs 📺, pre-registering devices with the Authorization Server 📝, or only allowing cross-device flows on devices managed through device management systems 🖥️. Device management systems may enforce policies that govern patching, version updates, on-device anti-malware deployment, revocation status, and device location amongst others 🛠️. Trusted devices MAY have their identities rooted in hardware (e.g., a Trusted Platform Module (TPM) or equivalent technology) 🔩.
By only allowing trusted devices to initiate cross-device flows, the attacker has to have access to such a device and keep that access in a way that doesn't get the device's trust status revoked 🕵️.
Mechanisms that identify a specific device SHOULD be evaluated for their privacy implications within the context of a specific application or deployment 🙈.
Limitations: An attacker may still be able to obtain access to a trusted device and use it to initiate authorization requests, making it necessary to apply additional controls and integrate with other threat detection and management systems that can detect suspicious behavior, such as repeated requests to initiate authorization or a high volume of service activation on the same device 🚩. An attacker may also spoof device identities or device types that are not cryptographically established or verified through attestation mechanisms 🥸.
6.1.8. Trusted Networks 🌐
An attacker can be stopped from initiating a cross-device flow protocol by only allowing the protocol to be started on a trusted network or within a security perimeter (e.g., a corporate network) 🏢. A trusted network may be defined as a set of IP addresses, and joining the network is subject to security controls managed by the network operator 🔑. Those controls may include only allowing trusted devices on the network, device management, user authentication, and physical access policies and systems 🚪. In some deployments, a trusted network may also be inferred using information supplied by a Subscriber Identity Module (SIM) or the network operator 📶. By limiting protocol initiation to a specific network, the attacker needs to have access to a device on the network 🧱. This mitigation can be implemented on the Authorization Server without changes to other system components ⭐.
Limitations: Network-level controls may not always be feasible, especially when dealing with consumer scenarios where the network may not be under control of the service provider 🙃. Even if it is possible to deploy network-level controls, they SHOULD be used in conjunction with other controls outlined in this document to achieve defense in depth 🫶.
6.1.9. Limited Scopes 🎟️
Authorization Servers MAY choose to limit the scopes they include in access tokens issued through cross-device flows where the unauthenticated channel between two devices is susceptible to being exploited 🎯. Including limited scopes lessens the impact in case of a successful attack 🪫. The decision about which scopes are included may be further refined based on whether the protocol is initiated on a trusted device or the user's location relative to the location of the Consumption Device 📍. This mitigation can be implemented on the Authorization Server without changes to other system components 💅.
Limitations: Limiting scopes reduces the impact of a compromise but does not avoid it. It SHOULD be used in conjunction with other mitigations described in this document 🧩.
6.1.10. Short-Lived Tokens ⏳
Another mitigation strategy includes limiting the life of the access and refresh tokens 🕰️. The lifetime can be lengthened or shortened, depending on the user's location, the resources they are trying to access, or whether they are using a trusted device 🌍. Short-lived tokens do not prevent or disrupt the attack, but they work as a remedial mechanism in case the attack succeeded 🩹. This mitigation can be implemented on the Authorization Server without changes to other system components 🌸.
Limitations: Short-lived tokens reduce the time window during which an attacker can benefit from a successful attack. This is most effective for access tokens 🎀. However, once an attacker obtains a refresh token, they can keep requesting new access tokens as well as refresh tokens 😩. Forcing the expiry of refresh tokens may cause the user to re-authorize an action more frequently, which results in a negative user experience 😖.
6.1.11. Rate Limits 🚦
An attacker that runs a scaled attack may need to request a large number of user codes (see the exploit described in Section 4.3.1) or initiate a large number of authorization requests (see the exploits described in Sections 4.3.4.1 and 4.3.9) in a short period of time 🏃♀️💨. An Authorization Server MAY apply rate limits to minimize the number of requests it would accept from a client or send to a user in a limited time period 🐢.
Limitations: Rate limits are effective at slowing an attacker down and help to degrade scaled attacks, but they do not prevent more targeted attacks that are executed with lower volumes and velocity 🐌. Therefore, they should be used along with other techniques to provide defense in depth against cross-device attacks 🛡️💜.
6.1.12. Sender-Constrained Tokens 🔑
Sender-constrained tokens limit the impact of a successful attack by stopping the tokens from being moved from the device where the attack was successfully executed 🔒. This makes attacks where an attacker gathers a large number of access and refresh tokens on a single device and then sells them for profit more difficult, since the attacker would also have to export the cryptographic keys used to sender-constrain the tokens or be able to access them and generate signatures for future use 💰. If the attack is being executed on a trusted device targeting a device with anti-malware, any attempts to exfiltrate tokens or keys may be detected, and the device's trust status may be changed 🚨. Using hardware keys with sender-constrained tokens will further reduce the attacker's ability to move tokens to another device 🔩✨.
Limitations: Sender-constrained tokens, especially sender-constrained tokens that require proof of possession, raise the bar for executing the attack and profiting from exfiltrating tokens 📈. Although a software proof-of-possession key is better than no proof-of-possession key, an attacker may still exfiltrate the software key 🙀. Hardware keys are harder to exfiltrate but come with additional implementation complexity 🧠. An attacker that controls the Consumption Device may still be able to exercise the key, even if it is in hardware 😬. So the main protection from sender-constrained tokens is stopping tokens from being moved from the Consumption Device to another device, which makes it harder to sell stolen tokens and profit from the attack 💸🙅♀️.
6.1.13. User Education 🎓
Research shows that user education is effective in reducing the risk of phishing attacks [Baki2023] 📚. The service provider MAY educate users on the risks of CDCP, as part of broader anti-phishing education, such as guidance to avoid clicking on links in emails or other unsolicited messages, as described by NIST in [NISTPhishing] 🎓🍓. In addition, the service provider MAY provide out-of-band reinforcement on the context and conditions under which an authorization grant may be requested 📣. For example, if the service provider does not send emails containing QR codes that ask users to grant authorization, that expectation can be reinforced through marketing communications and anti-fraud awareness campaigns 💌. The service provider MAY also reinforce these user education messages through in-app experiences 📱. In [PCRSM2023], it is proposed that users be advised to verify the trustworthiness of the source of a QR code, for example, by confirming that the connection is protected using TLS or that the URL belongs to the Authorization Server. 🔍🫶
Limitations: Although user education helps to raise awareness and reduce the overall risk to users, it is insufficient on its own to mitigate CDCP attacks 🙇♀️. In particular, carefully designed phishing attacks can be practically indistinguishable from benign authorization flows, even for well-trained users 🎭. User education SHOULD therefore be used in conjunction with other controls described in this document 💖.
6.1.14. User Experience ✨
Okay bestie, the UX is where the vibes get checked 💅. The user experience SHOULD preserve the context the protocols were started in and tell the user clearly when they're being asked to authorize, authenticate, or present a credential 🎀. It should be clear who invoked the flow, why it was invoked, and what happens if they finish the authorization, authentication, or credential presentation 🧐. The user experience SHOULD reinforce the message that unless the user started the authorization request or was expecting it, they should decline the request 🙅.
This info MAY be shown graphically or as a simple message, like this one 🍓:
It looks like you are trying to access your files on a digital whiteboard in your city center office. Click here to grant access to your files. If you are not trying to access your files, you should decline this request and notify the security departmentThe user interface SHOULD provide an obvious and unambiguous way for the user to decline or cancel a request 🚫. To avoid accidental authorization grants, the "decline" option SHOULD be the default option or given similar prominence in the user experience as the "grant" option 🙈.
If the user is on a mobile app and scans a QR code, the app MAY display info about when they should expect to be asked to scan one and when they should never scan one 📱. For example, it could say the QR code will only be displayed on kiosks within trusted locations or on trusted websites hosted on a specific domain, and never in email or other media and locations 💌.
The user experience MAY include info to further educate the user on CDCP attacks and reinforce the conditions under which authorization grants may be requested 📚.
Limitations: Improvements to user experience on their own are unlikely to be sufficient and SHOULD be used in conjunction with other controls described in this document.
6.1.15. Authenticate then Initiate 🔐
Okay so, if the user has to sign in on the Consumption Device with a phishing-resistant authentication method before starting a cross-device flow, the server can stop an attacker from starting one and grabbing QR codes or user codes 🛑. For example, a banking app might only kick off a cross-device authorization request using the Backchannel-Transferred Session Pattern after the user is already authenticated and tries a high-value transaction 💸. This stops the attacker from starting a cross-device authorization request and getting a QR code or a user code they could use to mislead an unsuspecting user 😤. This needs the Consumption Device to have enough input capabilities to support a phishing-resistant authentication mechanism, which may in itself negate the need for a cross-device flow 🤷♀️.
Limitations: This mitigation is limited to Consumption Devices capable of supporting phishing-resistant authentication mechanisms. Authenticating on the Consumption Device before starting a cross-device flow does not prevent the attacks described in Sections 4.3.5 and 4.3.7, and it is RECOMMENDED that additional mitigations described in this document be used if the cross-device flows are used in scenarios such as those described in Sections 3.3.5 and 3.3.7 🚨.
6.1.16. Request Initiation Verification 🙋
The user MAY be asked to confirm whether they started an authentication or authorization request. The way it works is they get a one-time password (OTP) or PIN on their Authorization Device and have to type it into the Consumption Device to confirm the request 🔢. If the request was started without their consent, they'd get an OTP or PIN totally out of context, which may raise suspicion for the user 👀. Plus, they wouldn't have any info on where to enter the OTP or PIN 🤔. The user experience on the Authorization Device MAY reinforce the risk of getting an out-of-context OTP or PIN and provide info on how to report an unauthorized authentication or authorization request 📣.
Limitations: The extra verification step may reduce the overall usability of the system, since it's one more thing users need to do right 😩. Attackers may combine conventional phishing attacks and target users who reply to those messages with an interactive attack that sets the expectation that they'll have to provide the OTP or PIN, in addition to granting authorization for the request 🎭.
6.1.17. Request Binding with Out-of-Band Data 🧷
In the User-Transferred Session Data Pattern, users MAY enter out-of-band info on the Consumption Device to start the authorization process ✍️. That out-of-band data MAY then be included in the QR code shown on the Consumption Device 📲. When the Authorization Device scans the QR code, the out-of-band data gets verified by the user or by the Authorization Device ✅. The out-of-band data could be any attribute that the user or the Authorization Device can retrieve during the authorization process 🧠. Examples include a serial number, OTP or PIN, location, or any other data that the user or the Authorization Device can recall or retrieve during the authorization process (see [MPRCS2020] and [PCRSM2023]) 💫.
Limitations: A sophisticated attacker may add an extra step to their attack, where they run a phishing attack that collects the out-of-band data from the user before starting the authorization request 🕵️. That extra step could also hurt the usability of the solution 😬.
6.1.18. Practical Mitigation Summary 🧩
The practical mitigations in this section can, within the limitations described, prevent or substantially increase the difficulty of starting attacks, disrupt attacks once they begin, or reduce the impact of an attack or remediate it if it succeeds 💪. When one or more of these mitigations are combined, the overall security profile of a cross-device flow improves significantly 📈. Here's the summary table, bestie 💖:
+=================================+=========+=========+=========+
| Mitigation | Prevent | Disrupt | Recover |
+=================================+=========+=========+=========+
| Establish Proximity | X | X | |
+---------------------------------+---------+---------+---------+
| Short-Lived/Time-Bound Codes | | X | |
+---------------------------------+---------+---------+---------+
| One-Time or Limited-Use Codes | | X | |
+---------------------------------+---------+---------+---------+
| Unique Codes | | X | |
+---------------------------------+---------+---------+---------+
| Content Filtering | | X | |
+---------------------------------+---------+---------+---------+
| Detect and Remediate | | | X |
+---------------------------------+---------+---------+---------+
| Trusted Devices | X | | |
+---------------------------------+---------+---------+---------+
| Trusted Networks | X | | |
+---------------------------------+---------+---------+---------+
| Limited Scopes | | | X |
+---------------------------------+---------+---------+---------+
| Short-Lived Tokens | | | X |
+---------------------------------+---------+---------+---------+
| Rate Limits | X | X | |
+---------------------------------+---------+---------+---------+
| Sender-Constrained Tokens | | | X |
+---------------------------------+---------+---------+---------+
| User Education | X | | |
+---------------------------------+---------+---------+---------+
| User Experience | X | | |
+---------------------------------+---------+---------+---------+
| Authenticate then Initiate | X | | |
+---------------------------------+---------+---------+---------+
| Request Initiation Verification | | X | |
+---------------------------------+---------+---------+---------+
| Request Binding with Out-of- | | X | |
| Band Data | | | |
+---------------------------------+---------+---------+---------+
Table 1: Practical Mitigation Summary6.2. Protocol Selection 🦋
Some cross-device protocols are way more susceptible to the exploits in this document than others 👀. In this section we compare three cross-device protocols on how susceptible they are to exploits focused on the unauthenticated channel, what they need to implement and deploy, and guidance on when it's right to use them 🧭.
6.2.1. IETF OAuth 2.0 Device Authorization Grant 📺
6.2.1.1. Description
[RFC8628] is a standard for enabling authorization on devices with constrained input capabilities (e.g., smart TVs, printers, and kiosks) 🖨️. In this protocol, the user code or QR code is displayed or made available on the Consumption Device (smart TV) and entered on a second device (e.g., a mobile phone) 📱.
6.2.1.2. Susceptibility
There are several reports out in the public domain on how the unauthenticated channel may be exploited to pull off a CDCP attack (see [ARTDCPHISH], [DCFLOWPHISH], [NEWDCPHISH], [DEFCON29], [DCATTACK], and [SQPHISH]) 🎣.
6.2.1.3. Device Capabilities
There are no assumptions in the protocol about the underlying capabilities of the device, which makes it a "least common denominator" protocol 🫶. It's expected to work on the broadest set of devices and environments 🌈.
6.2.1.4. Mitigations
In addition to the Security Considerations section in [RFC8628], it is RECOMMENDED that one or more of the mitigations outlined in this document be considered 🛡️. Especially the ones that help establish proximity or stop attackers from getting QR or user codes 💅.
6.2.1.5. When to Use
Only use this protocol if other cross-device protocols aren't viable due to device or system constraints 🙅. Avoid using it if the protected resources are sensitive, high value, or business critical 💼. Always deploy additional mitigations like proximity, or only allow it with pre-registered devices 🔒. Do not use it for same-device scenarios (e.g., if the Consumption Device and Authorization Device are the same device) 🚫.
6.2.2. OpenID Foundation Client-Initiated Backchannel Authentication (CIBA) 🔔
6.2.2.1. Description
CIBA [CIBA] is a standard developed in the OpenID Foundation 🏛️. It lets a device or service (e.g., a personal computer, smart TV, or kiosk) ask the OpenID Provider to start an authentication flow, as long as it knows a valid identifier for the user 🪪. The user finishes the authentication flow on a second device (e.g., a mobile phone) 📲. The vibe here is different, though: the user doesn't scan a QR code or grab a user code from the Consumption Device. Instead, the OpenID Provider reaches out to them to complete the authentication, using a push notification, email, text message, or any other suitable mechanism 💌✨.
6.2.2.2. Susceptibility 🙈
okay so CIBA is less susceptible to unauthenticated channel attacks 💅 but it's still vulnerable to attackers who know or can guess the user identifier and initiate an attack as described in Section 4.3.4.1. so not totally off the hook, bestie 💀
6.2.2.3. Device Capabilities 🎀
there's no requirement on the Consumption Device to support specific hardware 🧚 the Authorization Device must be registered/associated with the user, and it must be possible for the Authorization Server to trigger an authorization on this device. that's the whole vibe ✨
6.2.2.4. Mitigations 🛡️
in addition to the Security Considerations section in [CIBA], it is RECOMMENDED that one or more of the mitigations outlined in this document be considered, especially mitigations that can help establish proximity or prevent attackers from initiating authorization requests. ngl this part is literally the main character move 🔥
6.2.2.5. When to Use 👑
use CIBA instead of the device authorization grant if it is possible for the Consumption Device to obtain a user identifier on the Consumption Device (e.g., through an input or selection mechanism) and if the Authorization Server can trigger an authorization on the Authorization Device. do not use for same-device scenarios (e.g., if the Consumption Device and Authorization Device are the same device) 🙅♀️ the same device is not the vibe here, periodt 💖
6.2.3. FIDO2/WebAuthn ✨
6.2.3.1. Description 🦋
okay so FIDO2/WebAuthn is a stack of standards developed in the FIDO Alliance and W3C, respectively, which allow for origin-bound, phishing-resistant user authentication using asymmetric cryptography that can be invoked from a web browser or native client 🔐 version 2.2 of the FIDO Client to Authenticator Protocol (CTAP) supports a new cross-device authentication protocol, called "hybrid transports", which enables an external device, such as a phone or tablet, to be used as a roaming authenticator for signing in to the primary device, such as a personal computer 📱 this is commonly called FIDO Cross-Device Authentication (CDA). CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms 🌈
when a user wants to authenticate using their mobile device (authenticator) for the first time, they need to link their authenticator to their main device. this is done using a scan of a QR code 📸 when the authenticator scans the QR code, the device sends an encrypted BLE advertisement containing keying material and a tunnel ID. the main device (CTAP client) and authenticator both establish connections to the web service, and the normal CTAP protocol exchange occurs 🤝
if the user chooses to keep their authenticator linked with the main device, the QR code link step is not necessary for subsequent use. the user will receive a push notification on the authenticator 🔔
6.2.3.2. Susceptibility 🕵️♀️
the CDA flow proves proximity by leveraging BLE advertisements for service establishment, significantly reducing the susceptibility to any of the exploits described in examples B1-B6 in Section 4.3. proximity is the whole game and BLE is doing the heavy lifting 🦋
6.2.3.3. Device Capabilities 📲
both the Consumption Device and the authenticator require BLE support and access to the internet. the Consumption Device must support both the WebAuthn API [W3CWebAuthn] (or a platform-specific WebAuthn abstraction for native apps) and the FIDO CTAP, specifically version 2.2 with hybrid transports [FIDOCTAP22]. the device serving as the FIDO authenticator must also support CTAP 2.2 or later to be used as a cross-device authenticator 💅
6.2.3.4. Mitigations 🛡️
FIDO CDA establishes proximity through the use of BLE, reducing the need for additional mitigations 🫶 an implementer MAY still choose to implement additional mitigations as described in this document. totally optional, but iconic if you do 🌸
6.2.3.5. When to Use 🌈
FIDO2/WebAuthn SHOULD be used for cross-device authentication scenarios whenever the devices are capable of doing so and a suitable FIDO credential is not available on the Consumption Device 🍓 it MAY be used as an authentication method with the authorization code grant [RFC6749] and Proof Key for Code Exchange (PKCE) [RFC7636], to grant authorization to a Consumption Device (e.g., a smart TV or interactive whiteboard) using a device serving as the FIDO authenticator (e.g., a mobile phone) for authentication. this combination of FIDO2/WebAuthn and authorization code flow with PKCE enables cross-device authorization flows, without the risks posed by the device authorization grant [RFC8628] no cap, this combo is ICONIC 🌈✨
6.2.4. Protocol Selection Summary 🏆
the FIDO CDA flow provides the best protection against attacks on the unauthenticated channel for cross-device flows 👑 it can be combined with OAuth 2.0 and OpenID Connect protocols for standards-based authorization and authentication flows. if FIDO2/WebAuthn support is not available, CIBA provides an alternative, provided that there is a channel through which the Authorization Server can contact the end user. examples of such a channel include device push notifications, email, or text messages that the user can access from their device 📬 if CIBA is used, additional mitigations to enforce proximity and initiate transactions from trusted devices or trusted networks SHOULD be considered. the OAuth 2.0 device authorization grant provides the most flexibility and has the lowest requirements on devices used, but it is RECOMMENDED that it only be used when additional mitigations are deployed to prevent attacks that exploit the unauthenticated channel between devices 🧱 so lowkey: the flexible option is also the riskiest one, so mitigate, mitigate, MITIGATE 😭
6.3. Foundational Pillars 🧱
experience with web authorization and authentication protocols such as OAuth and OpenID Connect has shown that securing these protocols can be hard 😩 the major reason for this is that the landscape in which they are operating -- the web infrastructure with browsers, servers, and the underlying network -- is complex, diverse, and ever-evolving 🌪️
as is the case with other kinds of protocols, it can be easy to overlook vulnerabilities in this environment 👀 one way to reduce the chances of hidden security problems is to use mathematical-logical models to describe the protocols, their environments, and their security goals, and then use these models to try to prove security. this approach is what is usually subsumed as "formal security analysis" 🧠
there are two major strengths of formal analysis. first, finding new vulnerabilities does not require creativity (i.e., new classes of attacks can be uncovered even if no one thought of these attacks before) 🤯 in a faithful model, vulnerabilities become clear during the proof process or even earlier. second, formal analysis can exclude the existence of any attacks within the boundaries of the model (e.g., the protocol layers modeled, the level of detail and functionalities covered, the assumed attacker capabilities, and the formalized security goals) 🎯
as a downside, there is usually a gap between the model (which necessarily abstracts away from details) and implementations 🙃 in other words, implementations can introduce flaws where the model does not have any. nonetheless, for protocol standards, formal analysis can help to ensure that the specification is secure when implemented correctly 💜
there are various different approaches to formal security analysis, and each brings its own strengths and weaknesses 🧩 for example, models differ in the level of detail in which they can capture a protocol (granularity and expressiveness), in the kind of statements they can produce, and whether the proofs can be assisted by tools or have to be performed manually.
the following works have been identified as relevant to the analysis of cross-device flows 📚
- in "Formal analysis of self-issued OpenID providers" [Bauer2022], the protocol of [OpenID.SIOPv2] was analyzed using the Web Infrastructure Model (WIM). the WIM is specifically designed for the analysis of web authentication and authorization protocols. while it is a manual (pen-and-paper) model, it captures details of browsers and web interactions to a degree that is hard to match in automated models. in previous works, previously unknown flaws in OAuth, OpenID Connect, and OpenID FAPI were discovered using the WIM. in the analysis of a cross-device SIOPv2 flow in [Bauer2022], the request replay attack already described in Section 13.3 of [OpenID.SIOPv2] was confirmed in the model. a mitigation was implemented based on a so-called Cross-Device Stub, essentially a component that serves to link the two devices before the protocol flow starts. this can be seen as an implementation of a trusted device relationship as described in Section 6.1.7. the mitigation was shown to be effective in the model ✅
- in "Security analysis of the Grant Negotiation and Authorization Protocol" [Helmschmidt2022], an analysis of a draft of the Grant Negotiation and Authorization Protocol (GNAP) [RFC9635] was performed using the Web Infrastructure Model (WIM). the same attack as in [Bauer2022] was found to apply to GNAP as well. in this case, a model of a "careful user" (see Section 6.1.13) was used to show that the attack can be prevented (at least in theory) by the user 🧐
- in "The Good, the Bad and the (Not So) Ugly of Out-of-Band Authentication with eID Cards and Push Notifications: Design, Formal and Risk Analysis" [MPRCS2020], Pernpruner et al. formally analyzed an authentication protocol relying on push notifications delivered to an out-of-band device to approve the authentication attempt on the primary device (the Backchannel-Transferred Session Pattern in Section 3.1.2). the analysis was performed using the specification language ASLan++ and the model checker SATMC. according to the results of the analysis, they identified and defined the category of "implicit attacks", which manage to deceive users into approving a malicious authentication attempt through social engineering techniques, thus not compromising all the authentication factors involved; these attacks are aligned with the definition of CDCP attacks 😳
- in "An Automated Multi-Layered Methodology to Assist the Secure and Risk-Aware Design of Multi-Factor Authentication Protocols" [PCRSM2023], Pernpruner et al. defined a multi-layered methodology to analyze multi-factor authentication protocols at different levels of granularity. they leveraged their methodology to formally analyze a protocol relying on a QR code that has to be scanned on a secondary device to approve the authentication attempt on the primary device (the User-Transferred Session Data Pattern in Section 3.1.1). given the results of the analysis, they proposed some practical mitigations to either prevent or reduce the risk of successful attacks, such as those described in Sections 6.1.13, 6.1.16, and 6.1.17 🛠️
7. Security Considerations 🚨
security considerations are described in Sections 2 and 6. this is the part you do NOT skip, bestie, it's serious business 🔒💀
8. IANA Considerations 🧚
this document has no IANA actions. nothing to register here, so we're all good ✨
9. Conclusion 🎀
okay so cross-device flows are literally such a vibe 🦋 they let you authorize stuff on devices with limited input capabilities, keep authentication secure when you're on a public or shared device, give you a path toward multi-factor authentication, and hand you the convenience of one portable credential store 💼✨
but the popularity got the attention of attackers 💀 who exploit the unauthenticated channel between the Consumption Device and the Authorization Device using techniques commonly used in phishing attacks. these CDCP attacks let attackers grab access and refresh tokens instead of authentication credentials, so they can get into resources even if the user used multi-factor authentication 😭🚨
so to fix this, we're proposing a three-pronged approach 👑 first, deploying practical mitigations to safeguard protocols that are already deployed 🛡️ second, giving guidance on when to use different protocols (including protocols that aren't susceptible to these attacks) 🧭 and third, introducing formal methods to evaluate the impact of mitigations and find additional issues 🔬🧚
10. References 📚
10.1. Normative References 🔐
[CAEP]Tulshibagwale, A. and T. Cappalli, "OpenID Continuous Access Evaluation Profile 1.0", August 2025,<https://openid.net/specs/openid-caep-1_0-final.html>.[CIBA]Rodriguez, G. F., Walter, F., Nennker, A., Tonge, D., and B. Campbell, "OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", September 2021,<https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html>.[FIDOCTAP22]Bradley, J., Jones, M.B., Kumar, A., Lindemann, R., Verrept, S., and D. Waite, "Client to Authenticator Protocol (CTAP)", July 2025,<https://fidoalliance.org/specs/fido-v2.2-ps-20250714/fido-client-to-authenticator-protocol-v2.2-ps-20250714.html>.[IEEE-802.15.4]IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Std 802.15.4-2024, DOI 10.1109/IEEESTD.2024.10794632, 2024,<https://doi.org/10.1109/IEEESTD.2024.10794632>.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<https://www.rfc-editor.org/info/rfc2119>.[RFC6749]Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012,<https://www.rfc-editor.org/info/rfc6749>.[RFC7636]Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015,<https://www.rfc-editor.org/info/rfc7636>.[RFC7662]Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015,<https://www.rfc-editor.org/info/rfc7662>.[RFC8174]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,<https://www.rfc-editor.org/info/rfc8174>.[RFC8628]Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019,<https://www.rfc-editor.org/info/rfc8628>.[SSF]Tulshibagwale, A., Cappalli, T., Scurtescu, M., Backman, A., Bradley, J., and S. Miel, "OpenID Shared Signals Framework Specification 1.0", August 2025,<https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html>.[W3CWebAuthn]Cappalli, T., Ed., Kumar, A., Ed., Lundberg, E., Ed., Miller, M., Ed., Pascoe, Ed., and N. Satragno, "Web Authentication: An API for accessing Public Key Credentials Level 3", W3C Candidate Recommendation Snapshot, January 2025,<https://www.w3.org/TR/2026/CR-webauthn-3-20260526/>. Latest version available at<https://www.w3.org/TR/webauthn-3/>.
10.2. Informative References 🔍
[ARTDCPHISH]Cooke, B., "The Art of the Device Code Phish", July 2021,<https://0xboku.com/2021/07/12/ArtOfDeviceCodePhish.html>.[Baki2023]Baki, S. and R. M. Verma, "Sixteen Years of Phishing User Studies: What Have We Learned?", IEEE Transactions on Dependable and Secure Computing, vol. 20, no. 2, pp. 1200-1212, 2023,<https://doi.org/10.1109/TDSC.2022.3151103>.[Bauer2022]Bauer, C., "Formal analysis of self-issued OpenID providers", Master's Thesis, University of Stuttgart, 2022,<https://elib.uni-stuttgart.de/handle/11682/12417>.[DCATTACK]Secureworks Counter Threat Unit Research Team, "OAuth's Device Code Flow Abused in Phishing Attacks", June 2021,<https://www.sophos.com/en-us/blog/oauths-device-code-flow-abused-in-phishing-attacks>.[DCFLOWPHISH]Min, D., "Microsoft 365 OAuth Device Code Flow and Phishing", August 2021,<https://www.optiv.com/insights/source-zero/blog/microsoft-365-oauth-device-code-flow-and-phishing>.[DEFCON29]Hwong, J., "New Phishing Attacks Exploiting OAuth Authentication Flows (DEFCON 29)", DEF CON 29, Video, August 2021,<https://www.youtube.com/watch?v=9slRYvpKHp4>.[Helmschmidt2022]Helmschmidt, F., "Security analysis of the Grant Negotiation and Authorization Protocol", Master's Thesis, University of Stuttgart, 2022,<https://elib.uni-stuttgart.de/handle/11682/12220>.[MPRCS2020]Pernpruner, M., Carbone, R., Ranise, S., and G. Sciarretta, "The Good, the Bad and the (Not So) Ugly of Out-of-Band Authentication with eID Cards and Push Notifications: Design, Formal and Risk Analysis", Proceedings of the Tenth ACM Conference on Data and Application Security and Privacy, pp. 223-234, DOI 10.1145/3374664.3375727, 2020,<https://doi.org/10.1145/3374664.3375727>.[NEWDCPHISH]Syynimaa, N., "Introducing a new phishing technique for compromising Office 365 accounts", October 2020,<https://aadinternals.com/post/phishing/>.[NISTGlossary]NIST, "NIST Computer Security Resource Center Glossary",<https://csrc.nist.gov/glossary>.[NISTPhishing]NIST, "NIST Small Business Cybersecurity Fact Sheet: Phishing",<https://www.nist.gov/system/files/documents/2024/03/12/Phishing_SMB%20FactSheet_2024_Final.pdf>.[NYC.Bike]Byrne, K. J., "Citi Bikes being swiped by joyriding scammers who have cracked the QR code", New York Post, August 2021,<https://nypost.com/2021/08/07/citi-bikes-being-swiped-by-joyriding-scammers-who-have-cracked-the-qr-code/>.[OpenID.Core]Sakimura, N., Bradley, J., Jones, M. B., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", December 2023,<https://openid.net/specs/openid-connect-core-1_0.html>.[OpenID.SIOPv2]Yasuda, K., Jones, M., and T. Lodderstedt, "Self-Issued OpenID Provider v2 - draft 13", November 2023,<https://openid.net/specs/openid-connect-self-issued-v2-1_0.html>.[OpenID.VCI]Lodderstedt, T., Yasuda, K., Looker, T., and P. Bastian, "OpenID for Verifiable Credential Issuance 1.0", September 2025,<https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html>.[OpenID.VP]Terbu, O., Lodderstedt, T., Yasuda, K., Fett, D., and J. Heenan, "OpenID for Verifiable Presentations 1.0", July 2025,<https://openid.net/specs/openid-4-verifiable-presentations-1_0.html>.[PCRSM2023]Pernpruner, M., Carbone, R., Sciarretta, G., and S. Ranise, "An Automated Multi-Layered Methodology to Assist the Secure and Risk-Aware Design of Multi-Factor Authentication Protocols", IEEE Transactions on Dependable and Secure Computing, vol. 21, no. 4, pp. 1935-1950, 2023,<https://doi.org/10.1109/TDSC.2023.3296210>.[RFC9635]Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024,<https://www.rfc-editor.org/info/rfc9635>.[SQPHISH]Talebzadeh, K. and N. Romsdahl, "SquarePhish: Advanced phishing tool combines QR codes and OAuth 2.0 device code flow", Help Net Security, Video, August 2022,<https://www.helpnetsecurity.com/2022/08/11/squarephish-video/>.[W3C.DCAPI]Caceres, M., Ed., Cappalli, T., Ed., and M. Yosef, Ed., "Digital Credentials API", W3C Editor's Draft, 16 July 2026,<https://w3c-fedid.github.io/digital-credentials/>. Latest version available at<https://www.w3.org/TR/digital-credentials/>.
Contributors 🫶
the authors want to give a big shoutout to Tim Cappalli, Nick Ludwig, Adrian Frei, Nikhil Reddy Boreddy, Bjorn Hjelm, Joseph Heenan, Brian Campbell, Damien Bowden, Kristina Yasuda, Tim Würtele, Karsten Meyer zu Selhausen, Maryam Mehrnezhad, Marco Pernpruner, Giada Sciarretta, Dean H. Saxe, Roy Williams, Aaron Parecki, George Fletcher, Hannes Tschofenig, Dan Moore, Deb Cooley, Paul Kyzivat, David Mandelberg, Jim Fenton, Bing Liu, Mohamed Boucadair, Mike Bishop, Roman Danyliw, and others for their valuable input, feedback, and general support of this work 💖
Authors' Addresses 💌
- Pieter Kasselman
- Defakto Security
- Email: prkasselman@gmail.com
- Daniel Fett
- Authlete
- Email: mail@danielfett.de
- Filip Skokan
- Okta
- Email: panva.ip@gmail.com
📦 where this page comes from
- ietf: rfc10027 2026-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms