Internet Engineering Task Force (IETF) P. Kasselman
Request for Comments: 10027 Defakto Security
BCP: 247 D. Fett
Category: Best Current Practice Authlete
ISSN: 2070-1721 F. Skokan
Okta
August 2026
This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts, and engineers implementing cross-device flows.
このドキュメントでは、クロスデバイス フローに対する脅威と、実際的な軽減策、プロトコル選択のガイダンス、およびクロスデバイス フローのセキュリティに関連すると特定された正式な分析結果の概要について説明します。これは、システム設計者、アーキテクト、プロダクト マネージャー、セキュリティ スペシャリスト、詐欺アナリスト、クロスデバイス フローを実装するエンジニアに対するセキュリティ ガイドとして機能します。
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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されました。BCP の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10027.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10027 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
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' Addresses
Protocol flows that span multiple end-user devices are in widespread use today. These flows are often referred to as cross-device flows. A common example is a user that uses their mobile phone to scan a QR code from their smart TV, giving an app on the TV access to their video streaming service. Besides QR codes, other mechanisms are often used, such as PIN codes that the user has to enter on one of the devices or push notifications to a mobile app that the user has to approve.
複数のエンドユーザー デバイスにまたがるプロトコル フローは、現在広く使用されています。これらのフローは、クロスデバイス フローと呼ばれることがよくあります。一般的な例は、ユーザーが携帯電話を使用してスマート TV から QR コードをスキャンし、テレビ上のアプリがビデオ ストリーミング サービスにアクセスできるようにすることです。QR コードに加えて、ユーザーがいずれかのデバイスに入力する必要がある PIN コードや、ユーザーが承認する必要があるモバイル アプリへのプッシュ通知など、他のメカニズムもよく使用されます。
In all cases, it is up to the user to decide whether or not to grant authorization. However, the QR code or PIN is transferred via an unauthenticated channel, leaving it up to the user to decide in which context an authorization is requested. This may be exploited by attackers to gain unauthorized access to a user's resources.
いずれの場合も、許可を与えるかどうかはユーザーが決定します。ただし、QR コードまたは PIN は認証されていないチャネルを介して転送されるため、どのコンテキストで承認が要求されるかを決定するのはユーザーに任されています。これは、攻撃者によってユーザーのリソースへの不正アクセスを取得するために悪用される可能性があります。
To accommodate the various nuances of cross-device flows, this document distinguishes between use cases where the cross-device flow is used to authorize access to a resource (cross-device authorization flows) and use cases where the cross-device flow is used to transfer an existing session (cross-device session transfer flows).
クロスデバイス フローのさまざまなニュアンスに対応するために、このドキュメントでは、クロスデバイス フローを使用してリソースへのアクセスを承認するユース ケース (クロスデバイス承認フロー) と、クロスデバイス フローを使用して既存のセッションを転送するユース ケース (クロスデバイス セッション転送フロー) を区別します。
Cross-device authorization flows enable a user to initiate an authorization flow on one device (the Consumption Device) and then use a second, personally trusted, device (the Authorization Device) to authorize the Consumption Device to access a resource (e.g., access to a service). The device authorization grant [RFC8628] and Client-Initiated Backchannel Authentication (CIBA) [CIBA] are two examples of popular cross-device authorization flows.
クロスデバイス認証フローを使用すると、ユーザーは 1 つのデバイス (消費デバイス) で認証フローを開始し、次に個人的に信頼できる 2 番目のデバイス (認証デバイス) を使用して、消費デバイスがリソースにアクセスすること (サービスへのアクセスなど) を認証できます。デバイス認可グラント [RFC8628] とクライアント開始バックチャネル認証 (CIBA) [CIBA] は、一般的なクロスデバイス認可フローの 2 つの例です。
In these flows, the Consumption Device and the Authorization Device are not directly connected, and there are no technical mechanisms for the Authorization Device and Consumption Device to establish mutual authentication. It is left to the user to decide whether the source of the authorization request (the Consumption Device) should be trusted before they scan a QR code, enter a user code, or accept an authorization request pushed to their Authorization Device. The transfer of the authorization request and context between the Consumption Device and Authorization Device is done over an unauthenticated channel. The only mitigation against this unauthenticated channel is the user's judgment.
これらのフローでは、消費デバイスと認可デバイスは直接接続されておらず、認可デバイスと消費デバイスが相互認証を確立するための技術的なメカニズムはありません。QR コードをスキャンする前、ユーザー コードを入力する前、または認証デバイスにプッシュされた認証リクエストを受け入れる前に、認証リクエストのソース (消費デバイス) を信頼すべきかどうかを判断するのはユーザーに任されています。消費デバイスと認可デバイス間の認可リクエストとコンテキストの転送は、認証されていないチャネル経由で行われます。この未認証チャネルに対する唯一の緩和策は、ユーザーの判断です。
Cross-Device Consent Phishing (CDCP) attacks exploit the unauthenticated channel between the Consumption Device and Authorization Device using social engineering techniques commonly used in phishing attacks to gain unauthorized access to the user's data.
クロスデバイス同意フィッシング (CDCP) 攻撃は、フィッシング攻撃で一般的に使用されるソーシャル エンジニアリング技術を使用して、消費デバイスと認証デバイス間の認証されていないチャネルを悪用し、ユーザーのデータへの不正アクセスを取得します。
Several publications have emerged in the public domain ([ARTDCPHISH], [DCFLOWPHISH], [NEWDCPHISH], [DEFCON29], [DCATTACK], and [SQPHISH]) that describe how the unauthenticated channel can be exploited using social engineering techniques borrowed from phishing. Unlike conventional phishing attacks, these attacks don't harvest credentials. Instead, they skip the step of collecting credentials by persuading users to grant authorization using their Authorization Devices.
フィッシングから借用したソーシャル エンジニアリング技術を使用して、認証されていないチャネルを悪用する方法を説明するいくつかの出版物 ([ARTDCPHISH]、[DCFLOWPHISH]、[NEWDCPHISH]、[DEFCON29]、[DCATTACK]、および [SQPHISH]) がパブリック ドメインで公開されています。従来のフィッシング攻撃とは異なり、これらの攻撃は資格情報を収集しません。代わりに、認証デバイスを使用して認証を与えるようにユーザーを説得することで、資格情報を収集するステップをスキップします。
Once the user grants authorization, the attacker has access to the user's resources and in some cases is able to collect access and refresh tokens. Once in possession of the access and refresh tokens, the attacker may use these tokens to execute lateral attacks and gain additional access, or monetize the tokens by selling them. These attacks are effective even when multi-factor authentication is deployed, since the attacker's aim is not to capture and replay the credentials, but rather to persuade the user to grant authorization.
ユーザーが認可を与えると、攻撃者はユーザーのリソースにアクセスできるようになり、場合によってはアクセス トークンやリフレッシュ トークンを収集できるようになります。アクセス トークンとリフレッシュ トークンを取得すると、攻撃者はこれらのトークンを使用して水平攻撃を実行し、追加のアクセス権を取得したり、トークンを販売して収益化したりする可能性があります。これらの攻撃は、多要素認証が導入されている場合でも効果的です。これは、攻撃者の目的が資格情報を取得して再生することではなく、ユーザーに認可を与えるように説得することであるためです。
Session transfer flows enable a user to transfer access to a service or network from a device on which the user is already authenticated to a second device such as a mobile phone. In these flows, the user is authenticated and then authorizes the session transfer on one device, referred to as the Authorization Device (e.g., a personal computer, web portal, or application), and transfers the session to the device where they will continue to consume the session, referred to as the Consumption Device (e.g., a mobile phone or portable device).
セッション転送フローを使用すると、ユーザーは、すでに認証されているデバイスから携帯電話などの 2 番目のデバイスにサービスまたはネットワークへのアクセスを転送できます。これらのフローでは、ユーザーは認証された後、認証デバイス (パーソナル コンピューター、Web ポータル、アプリケーションなど) と呼ばれる 1 つのデバイスでセッション転送を承認し、消費デバイス (携帯電話やポータブル デバイスなど) と呼ばれるセッションの消費を継続するデバイスにセッションを転送します。
The session may be transferred by showing the user a session transfer code on the Authorization Device, which is then entered on the Consumption Device. This flow may be streamlined by rendering the session transfer code as a QR code on the Authorization Device and scanning it with the Consumption Device.
セッションは、認証デバイスでセッション転送コードをユーザーに表示し、消費デバイスで入力することによって転送できます。このフローは、セッション転送コードを認可デバイス上で QR コードとしてレンダリングし、それを消費デバイスでスキャンすることで合理化できます。
The session transfer preserves state information, including authentication state, at the second device to avoid additional configuration and optimize the user experience. These flows are often used to add new devices to a network, onboard customers to a mobile application, or provision new credentials (e.g., as described in [OpenID.SIOPv2]).
セッション転送では、認証状態を含む状態情報が 2 番目のデバイスに保存されるため、追加の構成が回避され、ユーザー エクスペリエンスが最適化されます。これらのフローは、新しいデバイスをネットワークに追加したり、顧客をモバイル アプリケーションにオンボードしたり、新しい資格情報をプロビジョニングしたりするためによく使用されます (たとえば、[OpenID.SIOPv2] で説明されているように)。
In these cross-device session transfer flows, the channel between the Authorization Device and the Consumption Device is unauthenticated.
これらのクロスデバイス セッション転送フローでは、認可デバイスと消費デバイス間のチャネルは認証されません。
Cross-Device Session Phishing (CDSP) attacks exploit the unauthenticated channel between the Authorization Device and Consumption Device by using social engineering techniques to convince the user to send the session transfer code to the attacker. These attacks borrow techniques from conventional phishing attacks, but instead of collecting passwords, attackers collect session transfer codes and other artifacts that allow them to set up a session and then use it to access a user's data.
クロスデバイス セッション フィッシング (CDSP) 攻撃は、ソーシャル エンジニアリング技術を使用して、認証デバイスと消費デバイス間の認証されていないチャネルを悪用し、ユーザーにセッション転送コードを攻撃者に送信するよう誘導します。これらの攻撃は従来のフィッシング攻撃の手法を借用していますが、攻撃者はパスワードを収集する代わりに、セッションを設定し、それを使用してユーザーのデータにアクセスできるようにするセッション転送コードやその他のアーティファクトを収集します。
This document provides guidance to implementers (e.g., system designers, architects, product managers, security specialists, fraud analysts, and engineers) of cross-device flows to defend against CDCP and CDSP attacks. This guidance includes:
このドキュメントは、クロスデバイス フローの実装者 (システム設計者、アーキテクト、プロダクト マネージャー、セキュリティ スペシャリスト、不正アナリスト、エンジニアなど) に、CDCP および CDSP 攻撃を防御するためのガイダンスを提供します。このガイダンスには次のものが含まれます。
1. Practical mitigations for susceptible protocols (Section 6.1).
1. 影響を受けやすいプロトコルに対する実際的な軽減策 (セクション 6.1)。
2. Protocol selection guidance to avoid using susceptible protocols (Section 6.2).
2. 影響を受けやすいプロトコルの使用を避けるためのプロトコル選択ガイダンス (セクション 6.2)。
3. Results from formal analysis of susceptible protocols (Section 6.3).
3. 影響を受けやすいプロトコルの正式な分析の結果 (セクション 6.3)。
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] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This specification uses the terms "access token", "refresh token", "authorization server", "resource server", "authorization request", and "client" defined in "The OAuth 2.0 Authorization Framework" [RFC6749].
この仕様では、「The OAuth 2.0 Authorization Framework」[RFC6749] で定義されている「アクセス トークン」、「リフレッシュ トークン」、「認可サーバー」、「リソース サーバー」、「認可リクエスト」、および「クライアント」という用語を使用します。
This document uses the terms "social engineering" and "phishing" as described in the NIST Computer Security Resource Center Glossary [NISTGlossary].
このドキュメントでは、NIST コンピュータ セキュリティ リソース センター用語集 [NISTGlossary] で説明されている「ソーシャル エンジニアリング」および「フィッシング」という用語を使用します。
This section describes the set of security mechanisms and measures to secure cross-device protocols against CDCP and CDSP attacks that the OAuth Working Group considers best practices at the time of writing this specification.
このセクションでは、この仕様の作成時点で OAuth Working Group がベスト プラクティスと考えている、CDCP および CDSP 攻撃からクロスデバイス プロトコルを保護するための一連のセキュリティ メカニズムと対策について説明します。
1. Implementers MUST perform a risk assessment before implementing cross-device flows, weighing the risks from CDCP and CDSP attacks against benefits for users.
1. 実装者は、クロスデバイス フローを実装する前に、CDCP および CDSP 攻撃によるリスクとユーザーのメリットを比較検討して、リスク評価を実行しなければなりません。
2. Implementers SHOULD avoid cross-device flows if risks cannot be sufficiently mitigated.
2. リスクを十分に軽減できない場合、実装者はクロスデバイス フローを避ける必要があります (SHOULD)。
3. Implementers SHOULD follow the guidance provided in Section 6.2 for protocol selection.
3. 実装者は、プロトコルの選択に関してセクション 6.2 で提供されるガイダンスに従う必要があります (SHOULD)。
4. Implementers MUST select appropriate mitigations from Section 6.1 to address risks identified in the risk assessment.
4. 実装者は、リスク評価で特定されたリスクに対処するために、セクション 6.1 から適切な緩和策を選択しなければなりません。
5. Implementers SHOULD include proximity as one of the selected mitigations as defined in Section 6.1.1, if possible.
5. 実装者は、可能であれば、セクション 6.1.1 で定義されているように、選択された緩和策の 1 つとして近接性を含めるべきです (SHOULD)。
These best practices apply to the device authorization grant [RFC8628] as well as other cross-device protocols such as CIBA [CIBA], Self-Issued OpenID Provider v2 [OpenID.SIOPv2], OpenID for Verifiable Presentations [OpenID.VP], the Pre-Authorized Code Flow in [OpenID.VCI], and other cross-device protocols that rely on the user to authenticate the channel between devices.
これらのベスト プラクティスは、デバイス認証グラント [RFC8628] だけでなく、CIBA [CIBA]、自己発行 OpenID プロバイダー v2 [OpenID.SIOPv2]、OpenID for Verifiable Presentations [OpenID.VP]、[OpenID.VCI] の事前認証コード フロー、およびデバイス間のチャネルの認証をユーザーに依存する他のクロスデバイス プロトコルにも適用されます。
Section 3 provides details about susceptible protocols, and Section 4 provides attack descriptions. Section 5 provides an overview of existing protocols and standards. Section 6.1 provides details about the security mechanisms and mitigations, Section 6.2 provides protocol selection guidance, and Section 6.3 provides details from formal analysis of protocols that apply to cross-device flows.
セクション 3 では影響を受けやすいプロトコルの詳細を説明し、セクション 4 では攻撃について説明します。セクション 5 では、既存のプロトコルと標準の概要を説明します。セクション 6.1 ではセキュリティ メカニズムと緩和策の詳細を提供し、セクション 6.2 ではプロトコル選択のガイダンスを提供し、セクション 6.3 ではクロスデバイス フローに適用されるプロトコルの正式な分析の詳細を提供します。
Cross-device flows enable a user to initiate an interaction on one device (e.g., a smart TV) and complete or continue it on a second device (e.g., a mobile phone). This specification addresses two distinct cross-device use cases:
クロスデバイス フローにより、ユーザーは 1 つのデバイス (スマート TV など) でインタラクションを開始し、2 番目のデバイス (携帯電話など) でそれを完了または継続することができます。この仕様は、次の 2 つの異なるクロスデバイスのユースケースに対応しています。
* *Cross-Device Authorization:* In the cross-device authorization use case, the second device is used to authenticate the user or grant authorization before passing control back to the first device as described in Section 3.1.
* *クロスデバイス認証:* クロスデバイス認証の使用例では、セクション 3.1 で説明されているように、2 番目のデバイスはユーザーを認証するか、最初のデバイスに制御を戻す前に認可を与えるために使用されます。
* *Cross-Device Session Transfer:* In the cross-device session transfer 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.
* *クロスデバイス セッション転送:* クロスデバイス セッション転送の使用例では、セッションが 2 番目のデバイスに転送される前に、ユーザーは最初のデバイスですでに認証されており、セクション 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).
これらのフローには通常、携帯電話を使用して QR コードをスキャンするか、最初のデバイス (スマート TV、キオスク、パーソナル コンピューター、またはその他の電子デバイスなど) に表示されるユーザー コードを入力することが含まれます。
In a cross-device authorization flow, a user attempts to access a service on one device, referred to as the Consumption Device (e.g., a smart TV), and then uses 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.
クロスデバイス認証フローでは、ユーザーは、消費デバイスと呼ばれる 1 つのデバイス (スマート TV など) 上のサービスにアクセスを試み、次に、認証デバイスと呼ばれる 2 番目のデバイス (スマートフォンなど) を使用して、消費デバイス上のリソースへのアクセス (ストリーミング サービスへのアクセスなど) を承認します。
Cross-device authorization flows have several benefits, including:
クロスデバイス認証フローには、次のようないくつかの利点があります。
* Authorization on devices with limited input capabilities: End users can authorize devices with limited input capabilities to access content (e.g., smart TVs, digital whiteboards, printers, or similarly constrained devices).
* 入力機能が制限されたデバイスの承認: エンドユーザーは、入力機能が制限されたデバイス (スマート TV、デジタル ホワイトボード、プリンター、または同様に制限されたデバイスなど) がコンテンツにアクセスすることを承認できます。
* Secure authentication on shared or public devices: End users can perform authentication and authorization using a personally trusted device, without risk of disclosing their credentials to a public or shared device.
* 共有デバイスまたはパブリックデバイスでの安全な認証: エンドユーザーは、自分の資格情報をパブリックデバイスまたは共有デバイスに開示するリスクを負うことなく、個人的に信頼できるデバイスを使用して認証と認可を実行できます。
* Ubiquitous multi-factor authentication: Enables a user to use multi-factor authentication, independent of the device on which the service is being accessed (e.g., a kiosk, smart TV, or shared personal computer).
* ユビキタス多要素認証: サービスにアクセスしているデバイス (キオスク、スマート TV、共有パーソナル コンピューターなど) に関係なく、ユーザーが多要素認証を使用できるようにします。
* 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.
消費デバイスと認可デバイスの間で認可リクエストを転送するには、3 つのクロスデバイス フロー パターンがあります。
* *User-Transferred Session Data Pattern:* In this pattern, the user initiates 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.
* *ユーザー転送セッション データ パターン:* このパターンでは、ユーザーは、アクションを承認する前に、消費デバイスから承認デバイスに情報をコピーすることにより、承認サーバーで承認プロセスを開始します。消費デバイスから認可デバイスにデータを転送することにより、ユーザーは認可セッションを転送します。たとえば、ユーザーは、消費デバイスに表示されたコードを読み取って認証デバイスに入力したり、消費デバイスに表示された QR コードを認証デバイスでスキャンしたりできます。デバイス認可グラント [RFC8628] は、このパターンに従うクロスデバイス フローの例です。
* *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.
* *バックチャネル転送セッション パターン:* このパターンでは、消費デバイス上の OAuth クライアントが、認可サーバーとのバックチャネルを介してセッションを転送し、認可デバイス上で認可を開始する責任を負います。たとえば、ユーザーは消費デバイス (パーソナル コンピュータなど) でオンライン購入を試み、認証デバイス (携帯電話など) で認証リクエストを受信する場合があります。CIBA [CIBA] は、このパターンに従うクロスデバイス フローの例です。
* *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 attempt 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.
* *ユーザー転送承認データ パターン:* このパターンでは、消費デバイス上の OAuth クライアントが、承認サーバーとのバックチャネル経由で承認リクエストをトリガーします。認証データ (例: 6 桁の認証コード) が認証デバイスに表示され、ユーザーはそれを消費デバイスに転送します (たとえば、手動で入力することによって)。たとえば、ユーザーはエンタープライズ アプリケーションのデータにアクセスしようとすると、認証デバイス (携帯電話など) で 6 桁の認証コードを受信し、それを消費デバイスに入力する場合があります。6 桁のコードの使用は説明のためのものであり、執筆時点での一般的な慣行を反映していることに注意してください。コードの長さは使いやすさとリスクの考慮事項に基づいて変化する可能性があり、適切な長さの指定はこのドキュメントの範囲外です。
The device authorization grant [RFC8628] is an example of a cross-device flow that relies on the user copying information from the Consumption Device to the Authorization Device by either entering data manually or scanning a QR code. Figure 1 shows a typical example of this flow.
デバイス認可グラント [RFC8628] は、データを手動で入力するか QR コードをスキャンすることによって、ユーザーが消費デバイスから認可デバイスに情報をコピーすることに依存するクロスデバイス フローの一例です。図 1 は、このフローの典型的な例を示しています。
+--------------+ +---------------+
| 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
図 1: ユーザー転送セッション データ パターン
(A)
(A)
The user takes an action on the Consumption Device by starting a purchase, adding a device to a network, or connecting a service to the Consumption Device.
ユーザーは、購入を開始したり、ネットワークにデバイスを追加したり、消費デバイスにサービスを接続したりすることにより、消費デバイス上でアクションを実行します。
(B)
(B)
The Consumption Device requests a QR code or user code from an Authorization Server.
消費デバイスは認可サーバーに QR コードまたはユーザー コードを要求します。
(C)
(C)
The Authorization Server returns a QR code or user code to the Consumption Device, which displays it to the user with instructions to scan the QR code or enter the user code using the Authorization Device.
認可サーバーは QR コードまたはユーザー コードを消費デバイスに返し、消費デバイスはそれをユーザーに表示し、認可デバイスを使用して QR コードをスキャンするかユーザー コードを入力するように指示します。
(D)
(D)
The Consumption Device starts polling the Authorization Server to find out if the user granted authorization.
消費デバイスは、ユーザーが認可を与えたかどうかを確認するために認可サーバーへのポーリングを開始します。
(E)
(ホ)
The user scans the QR code or enters the user code on the Authorization Device.
ユーザーは QR コードをスキャンするか、認証デバイスにユーザー コードを入力します。
(F)
(F)
The QR code or user code is sent to the Authorization Server.
QR コードまたはユーザー コードが認可サーバーに送信されます。
(G)
(G)
The Authorization Server validates the QR code or user code and prompts the user to authenticate and either accept or decline the authorization request.
認可サーバーは QR コードまたはユーザー コードを検証し、ユーザーに認証を求め、認可リクエストを受け入れるか拒否するかを求めます。
(H)
(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, depending on the authentication protocol, user interface, and other implementation details).
ユーザーは認証され、ユーザーのリソースへのアクセスが許可されます (認証プロトコル、ユーザー インターフェイス、およびその他の実装の詳細に応じて、いくつかの追加メッセージが存在する場合があります)。
(J)
(J)
The Authorization Server grants authorization (e.g., by issuing tokens) to the Consumption Device to access the user's resources.
認可サーバーは、消費デバイスにユーザーのリソースにアクセスするための認可を (トークンの発行などにより) 与えます。
CIBA [CIBA] transfers the session on the backchannel with the Authorization Server to request authorization on the Authorization Device. Figure 2 shows an example of this flow.
CIBA [CIBA] は、認可サーバーとのバックチャネルでセッションを転送し、認可デバイスでの認可を要求します。図 2 にこのフローの例を示します。
+--------------+ +---------------+
+------->| 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 | |
| | and Authorization| |
| | | |
| |--(E) Authentication ->| |
| | and Authorization| |
| | Completes | |
+--------------+ +---------------+
Figure 2: Backchannel-Transferred Session Pattern
図 2: バックチャネル転送セッション パターン
(A)
(A)
The user takes an action on the Consumption Device by starting a purchase, adding a device to a network, or connecting a service to the Consumption Device.
ユーザーは、購入を開始したり、ネットワークにデバイスを追加したり、消費デバイスにサービスを接続したりすることにより、消費デバイス上でアクションを実行します。
(B)
(B)
The client on the Consumption Device requests user authorization on the backchannel from the Authorization Server, instructs the user to authorize the request on the Authorization Device, and waits for a response from the Authorization Server.
消費デバイス上のクライアントは、バックチャネル上で認可サーバーからのユーザー認可を要求し、認可デバイス上でリクエストを認可するようにユーザーに指示し、認可サーバーからの応答を待ちます。
(C)
(C)
The Authorization Server requests user authentication and authorization on the user's Authorization Device.
認可サーバーは、ユーザーの認証とユーザーの認可デバイス上の認可を要求します。
(D)
(D)
If the user is unauthenticated, 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, depending on the authentication protocol, user interface, and other implementation details).
ユーザーは認証され、ユーザーのリソースへのアクセスが許可されます (認証プロトコル、ユーザー インターフェイス、およびその他の実装の詳細によっては、いくつかの追加メッセージが存在する場合があります)。
(F)
(F)
The Authorization Server grants authorization (e.g., by issuing tokens) to the Consumption Device to access the user's resources.
認可サーバーは、消費デバイスにユーザーのリソースにアクセスするための認可を (トークンの発行などにより) 与えます。
The Authorization Server may use a variety of mechanisms to request user authorization, including a push notification to a dedicated app on a mobile phone or sending a text message with a link to an endpoint where the user can authenticate and authorize an action.
認可サーバーは、携帯電話上の専用アプリへのプッシュ通知や、ユーザーがアクションを認証および認可できるエンドポイントへのリンクを含むテキスト メッセージの送信など、さまざまなメカニズムを使用してユーザー認可を要求できます。
Examples of the User-Transferred Authorization Data Pattern include flows in which the Consumption Device requests the Authorization Server to send authorization data (e.g., a 6-digit authorization code in a text message, email, or mobile application) to the Authorization Device. Once the Authorization Device receives the authorization data, the user enters it on the Consumption Device. The Consumption Device sends the authorization data back to the Authorization Server for validation before gaining access to the user's resources. Figure 3 shows an example of this flow.
ユーザー転送認証データ パターンの例には、消費デバイスが認証サーバーに認証データ (テキスト メッセージ、電子メール、またはモバイル アプリケーション内の 6 桁の認証コードなど) を認証デバイスに送信するよう要求するフローが含まれます。認証デバイスが認証データを受信すると、ユーザーはそれを消費デバイスに入力します。消費デバイスは、ユーザーのリソースにアクセスする前に、検証のために認可データを認可サーバーに送り返します。図 3 にこのフローの例を示します。
+--------------+ +---------------+
+------->| 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
図 3: ユーザー転送承認データ パターン
(A)
(A)
The user takes an action on the Consumption Device by starting a purchase, adding a device to a network, or connecting a service to the Consumption Device.
ユーザーは、購入を開始したり、ネットワークにデバイスを追加したり、消費デバイスにサービスを接続したりすることにより、消費デバイス上でアクションを実行します。
(B)
(B)
The client on the Consumption Device requests user authorization on the backchannel from the Authorization Server.
消費デバイス上のクライアントは、認可サーバーからのバックチャネルでユーザー認可を要求します。
(C)
(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.
認可サーバーは認可データ (例: 6 桁の認可コード) を認可デバイスに送信します。認証データを配布するために使用できるメカニズムの例には、テキスト メッセージ、電子メール、モバイル アプリケーションなどがあります。
(D)
(D)
The user reads and copies the authorization data (e.g., the 6-digit authorization code) received on the Authorization Device.
ユーザーは、認証デバイスで受信した認証データ (6 桁の認証コードなど) を読み取り、コピーします。
(E)
(ホ)
The user enters the authorization data on the Consumption Device.
ユーザーは消費デバイスに認証データを入力します。
(F)
(F)
The Consumption Device sends the authorization data to the Authorization Server.
消費デバイスは認証データを認証サーバーに送信します。
(G)
(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).
認可サーバーは、認可データがステップ (C) で送信されたものと同じである場合、トークンを発行するか、消費デバイスにユーザーのリソースにアクセスするための認可を与えます。
The Authorization Server may choose to authenticate the user before sending the authorization data.
認可サーバーは、認可データを送信する前にユーザーを認証することを選択する場合があります。
Session transfer flows enable a user to transfer access to a service or network from a device on which the user is already authenticated to a second device such as a mobile phone. In these flows, the user is authenticated and then authorizes the session transfer on one device, referred to as the Authorization Device (e.g., a personal computer, web portal or application), and transfers the session to the device where they will continue to consume the session, referred to as the Consumption Device (e.g., a mobile phone or portable device).
セッション転送フローを使用すると、ユーザーは、すでに認証されているデバイスから携帯電話などの 2 番目のデバイスにサービスまたはネットワークへのアクセスを転送できます。これらのフローでは、ユーザーは認証されてから、認証デバイス (パーソナル コンピューター、Web ポータル、アプリケーションなど) と呼ばれる 1 つのデバイスでセッション転送を承認し、消費デバイス (携帯電話やポータブル デバイスなど) と呼ばれるセッションを継続して使用するデバイスにセッションを転送します。
The session transfer preserves state information, including authentication state, at the second device to avoid additional configuration and optimize the user experience. 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]).
セッション転送では、認証状態を含む状態情報が 2 番目のデバイスに保存されるため、追加の構成が回避され、ユーザー エクスペリエンスが最適化されます。これらのフローは、ネットワークへの新しいデバイスの追加、モバイル アプリケーションへの顧客のオンボード、または新しい資格情報 ([OpenID.SIOPv2] など) のプロビジョニングによく使用されます。
In this flow, the user is authenticated and starts the flow 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 it on the Consumption Device where they would like the session to continue, the Consumption Device presents it to the Authorization Server. The Authorization Server then 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.
このフローでは、ユーザーが認証され、認可デバイスでセッションの転送を認可することでフローが開始されます。認証デバイスは、セッション転送コードを要求します。このコードは、認証デバイス上で QR コードとして表示される場合があります。ユーザーが QR コードをスキャンするか、セッションの継続を希望する消費デバイスに QR コードを入力すると、消費デバイスはそれを認証サーバーに提示します。次に、認可サーバーはセッションを消費デバイスに転送します。これには、ユーザー エクスペリエンスを最適化するための認証および認可状態の転送が含まれる場合があります。このタイプのフローは、たとえば、ネットワークへの新しいデバイスの追加、新しいアプリケーションのブートストラップ、または新しい資格情報のプロビジョニングに使用されます。[OpenID.VCI] の事前承認コード フローは、このパターンを使用して新しい認証情報をプロビジョニングする例です。図 4 に一般的なフローを示します。
+---------------+ +---------------+
+-------->| 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
図 4: クロスデバイス セッション転送パターン
(A)
(A)
The user is authenticated on the Authorization Device and authorizes the transfer of the session to the Consumption Device.
ユーザーは認可デバイスで認証され、消費デバイスへのセッションの転送を認可します。
(B)
(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)
(C)
The Authorization Server responds with a session transfer code, which may be rendered as a QR code on the Authorization Device.
認可サーバーは、セッション転送コードで応答します。このコードは、認可デバイス上で QR コードとして表示される場合があります。
(D)
(D)
The user views the session transfer code, which may be rendered as a QR code.
ユーザーは、QR コードとして表示されるセッション転送コードを表示します。
(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.
ユーザーは、消費デバイス (携帯電話など) にセッション転送コードを入力します。セッション転送コードが QR コードとしてレンダリングされる場合、ユーザーはターゲットの消費デバイスで QR コードをスキャンします。
(F)
(F)
The client on the Consumption Device presents the session transfer code to the Authorization Server.
消費デバイス上のクライアントは、セッション転送コードを認可サーバーに提示します。
(G)
(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.
認可サーバーはセッション転送コードを検証し、消費デバイスでセッションを再開するために必要なセッション コンテキスト情報を返します。ユーザーは、認証デバイス上で開始して認証したセッションを再開し、消費デバイス上の情報へのアクセスに進みます。
The following examples illustrate the above flows in a diverse range of practical settings. Corresponding examples of how these flows may be exploited by attackers are documented in Section 4.3.
次の例は、さまざまな実際の設定における上記のフローを示しています。これらのフローが攻撃者によってどのように悪用されるかについての対応する例は、セクション 4.3 に文書化されています。
An end user sets up a new smart TV and wants to connect it to their favorite streaming service. The streaming service displays a QR code on the TV that the user scans with their mobile phone. The user is 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, after which the streaming service is available on the smart TV. Section 4.3.1 illustrates an exploit that applies to this scenario.
エンド ユーザーは新しいスマート TV をセットアップし、お気に入りのストリーミング サービスに接続したいと考えています。ストリーミング サービスでは、ユーザーが携帯電話でスキャンする QR コードをテレビに表示します。ユーザーはストリーミング サービス プロバイダーの Web ページにリダイレクトされ、スマート TV がストリーミング サービスにアクセスすることを承認するための資格情報を入力するように求められます。ユーザーが資格情報を入力して承認を与えると、スマート TV でストリーミング サービスが利用できるようになります。セクション 4.3.1 では、このシナリオに適用されるエクスプロイトを説明します。
An employee wants to access their files on an interactive whiteboard in a conference room. The interactive 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, the user is asked to authenticate and authorize the interactive whiteboard to access their files. The user enters their credentials and authorizes the transaction, and the interactive whiteboard retrieves their files and allows the user to interact with the content. Section 4.3.2 describes an exploit relevant to this example.
従業員は、会議室のインタラクティブ ホワイトボード上のファイルにアクセスしたいと考えています。インタラクティブ ホワイトボードには URL とコードが表示されます。ユーザーが自分のコンピュータに URL を入力すると、コードの入力を求められます。コードを入力すると、ユーザーは認証を求められ、インタラクティブ ホワイトボードがファイルにアクセスすることを許可されます。ユーザーが資格情報を入力してトランザクションを承認すると、インタラクティブ ホワイトボードがファイルを取得して、ユーザーがコンテンツを操作できるようになります。セクション 4.3.2 では、この例に関連するエクスプロイトについて説明します。
An end user wants to rent a bicycle from a bike sharing scheme. The bicycles are locked in bicycle racks on sidewalks throughout a city. To unlock and use a bicycle, the user scans a QR code on the bicycle using their mobile phone. Scanning the QR code redirects the user to the bicycle sharing scheme's authorization page where the user authenticates and authorizes payment for renting the bicycle. Once authorized, the bicycle sharing service unlocks the bicycle, allowing the user to use it to cycle around the city. Section 4.3.3 outlines an exploit relevant to this situation.
エンドユーザーは自転車シェアリングスキームから自転車をレンタルしたいと考えています。自転車は街中の歩道にある自転車ラックに施錠されています。自転車のロックを解除して使用するには、ユーザーは携帯電話を使用して自転車の QR コードをスキャンします。QR コードをスキャンすると、ユーザーは自転車共有スキームの認証ページにリダイレクトされ、そこでユーザーが認証され、自転車レンタルの支払いが承認されます。承認されると、自転車シェアリングサービスは自転車のロックを解除し、ユーザーはそれを使って市内をサイクリングできるようになります。セクション 4.3.3 では、この状況に関連するエクスプロイトの概要を説明します。
An end user makes an online purchase. Before completing the purchase, they get a notification on their mobile phone, asking them to authorize the transaction. The user opens their app and authenticates to the service before authorizing the transaction. Section 4.3.4 describes two exploits relevant to this example.
エンドユーザーがオンラインで購入します。購入を完了する前に、取引の承認を求める通知が携帯電話に届きます。ユーザーは、トランザクションを承認する前に、アプリを開いてサービスに対する認証を行います。セクション 4.3.4 では、この例に関連する 2 つのエクスプロイトについて説明します。
An employee is issued a personal computer that is already joined to a network. The employee wants to add their mobile phone to the network to allow it to access corporate data and services (e.g., files and email). The employee is logged in on the personal computer where they initiate the process of adding their mobile phone to the network. The personal computer displays a QR code that authorizes the user to join their mobile phone to the network. The employee scans the QR code with their mobile phone, and the mobile phone is joined to the network. The employee 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.
従業員には、ネットワークに接続済みのパーソナル コンピュータが支給されます。従業員は、携帯電話をネットワークに追加して、企業データやサービス (ファイルや電子メールなど) にアクセスできるようにしたいと考えています。従業員はパーソナル コンピュータにログインし、そこで携帯電話をネットワークに追加するプロセスを開始します。パーソナル コンピュータには、ユーザーが携帯電話をネットワークに参加することを許可する QR コードが表示されます。従業員が携帯電話で QR コードをスキャンすると、携帯電話がネットワークに接続されます。従業員はモバイル デバイスで企業データやサービスにアクセスできるようになります。セクション 4.3.5 では、このフローを悪用する方法の例を示します。
A new employee is directed to an onboarding portal to provide additional information to confirm their identity on their first day with their new employer. Before activating the employee's account, the onboarding portal requests that the employee present a government issued ID, proof of a background check, and proof of their qualifications. The onboarding portal displays a QR code, which the user scans with their mobile phone. Scanning the QR code invokes the employee's digital wallet on their mobile phone, and the employee is 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 after completing the onboarding process, their account is activated. Section 4.3.6 provides an example of an exploit for this use case.
新しい従業員は、新しい雇用主との初日に身元を確認するための追加情報を提供するためにオンボーディング ポータルに誘導されます。従業員のアカウントをアクティブ化する前に、オンボーディング ポータルは従業員に政府発行の ID、身元調査の証拠、および資格の証明書の提示を要求します。オンボーディング ポータルには QR コードが表示され、ユーザーは携帯電話でそれをスキャンします。QR コードをスキャンすると、従業員の携帯電話でデジタル ウォレットが呼び出され、従業員はデジタル版の身分証明書 (運転免許証など)、身元確認者による身元調査の証拠、および資格の証明書の提示を求められます。従業員は資格情報のリリースを承認し、オンボーディング プロセスが完了すると、アカウントがアクティブ化されます。セクション 4.3.6 では、この使用例のエクスプロイトの例を示します。
An employee is signed in to an application on their personal computer and wants to bootstrap the mobile application on their mobile phone. The employee initiates the cross-device flow and is shown a QR code in their application. The employee launches the mobile application on their phone and scans the QR code, which results in the user being signed in to the application on the mobile phone. Section 4.3.7 describes an exploit that applies to this scenario.
従業員は個人コンピュータでアプリケーションにサインインしており、携帯電話でモバイル アプリケーションをブートストラップしたいと考えています。従業員はクロスデバイス フローを開始し、アプリケーションに QR コードが表示されます。従業員が携帯電話でモバイル アプリケーションを起動し、QR コードをスキャンすると、ユーザーは携帯電話でアプリケーションにサインインします。セクション 4.3.7 では、このシナリオに適用されるエクスプロイトについて説明します。
A user is accessing a Computer-Aided Design (CAD) application. When accessing the application, authorization data in the form of a 6-digit authorization code is sent to the user's mobile phone. The user views the 6-digit authorization code on their phone and enters it in the CAD application, after which the CAD application displays the user's most recent designs. Section 4.3.8 outlines an attack relevant to this scenario.
ユーザーがコンピュータ支援設計 (CAD) アプリケーションにアクセスしています。アプリケーションにアクセスすると、6 桁の認証コードの形式の認証データがユーザーの携帯電話に送信されます。ユーザーは携帯電話で 6 桁の認証コードを表示し、それを CAD アプリケーションに入力すると、CAD アプリケーションにユーザーの最新の設計が表示されます。セクション 4.3.8 では、このシナリオに関連する攻撃の概要を説明します。
A network administrator wants to access an administration portal used to configure network assets and deploy new applications. When attempting to access the service, the network administrator receives a notification in an app on their mobile device, requesting them to confirm access to the portal. The network administrator approves the request on their mobile phone and is granted access to the portal. Section 4.3.9 describes how an attacker might exploit this flow.
ネットワーク管理者は、ネットワーク資産の構成と新しいアプリケーションの展開に使用される管理ポータルにアクセスしたいと考えています。サービスにアクセスしようとすると、ネットワーク管理者はモバイル デバイス上のアプリで通知を受け取り、ポータルへのアクセスを確認するよう要求します。ネットワーク管理者は携帯電話でリクエストを承認し、ポータルへのアクセスが許可されます。セクション 4.3.9 では、攻撃者がこのフローを悪用する方法について説明します。
Attackers exploit the absence of an authenticated channel between the two devices used in a cross-device flow by using social engineering techniques typically used in phishing attacks.
攻撃者は、フィッシング攻撃で通常使用されるソーシャル エンジニアリング手法を使用して、クロスデバイス フローで使用される 2 つのデバイス間に認証されたチャネルがないことを悪用します。
In cross-device authorization flows, the attacker uses these social engineering techniques by changing the context in which the authorization request is presented to convince the user to grant authorization when they shouldn't. These attacks are also known as CDCP attacks.
クロスデバイス承認フローでは、攻撃者は、承認リクエストが提示されるコンテキストを変更することでこれらのソーシャル エンジニアリング手法を使用し、承認すべきではないときに承認を与えるようにユーザーを説得します。これらの攻撃は CDCP 攻撃とも呼ばれます。
In cross-device session transfer flows, the attacker uses these social engineering techniques to convince the user to initiate a session transfer and send them a session transfer code. Once the attacker is in possession of this session transfer 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.
クロスデバイスのセッション転送フローでは、攻撃者はこれらのソーシャル エンジニアリング手法を使用して、ユーザーを説得してセッション転送を開始し、セッション転送コードを送信します。攻撃者がこのセッション転送コードを入手すると、それを認可サーバーに提示してセッションを転送し、ユーザーのリソースにアクセスします。これらの攻撃は CDSP 攻撃と呼ばれます。
Attackers exploit cross-device authorization flows by initiating an authorization flow on the Consumption Device and then use social engineering techniques to change the context in which the request is presented to the user in order to convince them to grant authorization on the Authorization Device. The attacker is able to change the context of the authorization request because the channel between the Consumption Device and the Authorization Device is unauthenticated. These attacks are also known as CDCP attacks.
攻撃者は、消費デバイス上で認証フローを開始することでクロスデバイス認証フローを悪用し、ソーシャル エンジニアリング手法を使用して、ユーザーに要求が提示されるコンテキストを変更して、認証デバイス上で認証を与えるようにユーザーを説得します。消費デバイスと認可デバイス間のチャネルが認証されていないため、攻撃者は認可リクエストのコンテキストを変更できます。これらの攻撃は CDCP 攻撃とも呼ばれます。
A common action in cross-device flows is to present the user with a QR code or a user code on the Consumption Device (e.g., smart TV), which is then scanned or entered on the Authorization Device (e.g., mobile phone). When the user scans the code or copies the user code, they do so without any proof that the QR code or user code is being displayed in the place or context intended by the service provider. It is up to the user to decide whether they should trust the QR code or user code. In effect, the user is asked to compensate for the absence of an authenticated channel between the Consumption Device (e.g., smart TV) and the Authorization Device (e.g., mobile phone).
クロスデバイス フローの一般的なアクションは、消費デバイス (スマート TV など) で QR コードまたはユーザー コードをユーザーに提示し、それが認証デバイス (携帯電話など) でスキャンまたは入力されることです。ユーザーがコードをスキャンしたり、ユーザー コードをコピーしたりする場合、QR コードまたはユーザー コードがサービス プロバイダーが意図した場所またはコンテキストに表示されていることを証明する必要はありません。QR コードとユーザー コードのどちらを信頼するかはユーザーが決定します。実際、ユーザーは、消費デバイス (スマート TV など) と認証デバイス (携帯電話など) の間に認証済みチャネルがないことを補うように求められます。
Attackers exploit this absence of an authenticated channel between the two devices by obtaining QR codes or user codes (e.g., by initiating the authorization flows). They then use social engineering techniques to change the context in which authorization is requested to convince end users to scan the QR code or enter it on their Authorization Device (e.g., mobile phone). Once the end user performs the authorization on the mobile device, the attacker who initiated the authentication or authorization request obtains access to the user's resources. Figure 5 shows an example of such an attack.
攻撃者は、2 つのデバイス間に認証されたチャネルがないことを利用して、QR コードまたはユーザー コードを取得します (たとえば、認証フローを開始することによって)。次に、ソーシャル エンジニアリング技術を使用して、承認が要求されるコンテキストを変更し、エンド ユーザーに QR コードをスキャンするか、承認デバイス (携帯電話など) に QR コードを入力するよう説得します。エンド ユーザーがモバイル デバイスで認証を実行すると、認証または認可リクエストを開始した攻撃者がユーザーのリソースへのアクセスを取得します。図 5 は、そのような攻撃の例を示しています。
+--------------+ +---------------+
| 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 Exploit
図 5: ユーザー転送セッション データ パターンの悪用
(A)
(A)
The attacker initiates the protocol on the Consumption Device (or mimics the Consumption Device) by starting a purchase, adding a device to a network, or connecting a service to the Consumption Device.
攻撃者は、購入を開始したり、ネットワークにデバイスを追加したり、消費デバイスにサービスを接続したりすることで、消費デバイス上でプロトコルを開始します (または消費デバイスを模倣します)。
(B)
(B)
The Consumption Device requests a QR code or user code from an Authorization Server.
消費デバイスは、認可サーバーに QR コードまたはユーザー コードを要求します。
(C)
(C)
The Authorization Server returns a QR code or user code to the Consumption Device, which displays it to the user with instructions to scan the QR code or enter the user code using the Authorization Device.
認可サーバーは QR コードまたはユーザー コードを消費デバイスに返し、消費デバイスはそれをユーザーに表示し、認可デバイスを使用して QR コードをスキャンするかユーザー コードを入力するように指示します。
(D)
(D)
The Consumption Device starts polling the Authorization Server to find out if the user granted authorization.
消費デバイスは、ユーザーが認可を与えたかどうかを確認するために認可サーバーへのポーリングを開始します。
(E)
(ホ)
The attacker copies the QR code or user code.
攻撃者は QR コードまたはユーザー コードをコピーします。
(F)
(F)
The attacker changes the context in which the QR code or user code is displayed in such a way that the user is likely to scan the QR code or use the user code when completing 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 encourage the user to scan the QR code or enter the user code by suggesting that doing so would grant them a reward through a loyalty program or prevent the loss of their data.
攻撃者は、ユーザーが認証を完了する際に QR コードをスキャンするかユーザー コードを使用する可能性が高いように、QR コードまたはユーザー コードが表示されるコンテキストを変更します。たとえば、攻撃者はユーザー コードまたは QR コードを含む電子メールを作成し、ユーザーに送信する可能性があります。この電子メールは、ユーザーに QR コードのスキャンまたはユーザー コードの入力を奨励し、そうすることでロイヤルティ プログラムを通じて特典が付与されたり、データの損失が防止されることを示唆したりする可能性があります。
(G)
(G)
The QR code or user code is displayed to the user in a context chosen by the attacker. The user is convinced by the attacker's effort and scans the QR code or enters the user code on the Authorization Device.
QR コードまたはユーザー コードは、攻撃者が選択したコンテキストでユーザーに表示されます。ユーザーは攻撃者の取り組みを確信し、QR コードをスキャンするか、認証デバイスにユーザー コードを入力します。
(H)
(H)
The QR code or user code is sent to the Authorization Server.
QR コードまたはユーザー コードが認可サーバーに送信されます。
(I)
（私）
The Authorization Server validates the QR code or user code and prompts the user to authenticate and accept or decline the authorization request.
認可サーバーは QR コードまたはユーザー コードを検証し、ユーザーに認証を求め、認可リクエストを受け入れるか拒否するかを求めます。
(J)
(J)
The user authenticates and grants authorization using the Authorization Device.
ユーザーは認可デバイスを使用して認証および認可を行います。
(K)
(K)
The user is authenticated with the Authorization Server, and authorization is granted to access the user's resources (there may be several additional 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 any authorization artifacts like access and refresh tokens.
認可サーバーは、攻撃者の制御下にある消費デバイスにトークンを発行するか、ユーザーのリソースにアクセスするための認可を与えます。攻撃者は、リソースと、アクセス トークンやリフレッシュ トークンなどの認証アーティファクトへのアクセスを取得します。
In the Backchannel-Transferred Session Pattern, the client requests the Authorization Server to authenticate the user and obtain authorization for an action. This may happen as a result of user interaction with the Consumption Device but may also be triggered without the user's direct interaction with the Consumption Device, resulting in an authorization request presented to the user without context of why or who triggered the request.
バックチャネル転送セッション パターンでは、クライアントは認可サーバーにユーザーを認証し、アクションの認可を取得するよう要求します。これは、消費デバイスとのユーザーの対話の結果として発生する可能性がありますが、消費デバイスとのユーザーの直接対話なしでトリガーされることもあり、その結果、要求をトリガーした理由や誰がトリガーしたかのコンテキストなしで承認リクエストがユーザーに提示されます。
Attackers exploit this lack of context by using social engineering techniques to prime the user for an authorization request and thereby convince them to grant authorization. The social engineering techniques range in sophistication from messages misrepresenting the reason for receiving an authorization request to triggering a large volume of requests at an inconvenient time for the user, in the hope that the user will grant authorization to make the requests stop. Figure 6 shows an example of such an attack.
攻撃者は、ソーシャル エンジニアリング技術を使用してこのコンテキストの欠如を利用して、ユーザーに承認リクエストを促し、ユーザーに承認を与えるよう説得します。ソーシャル エンジニアリング手法は、承認リクエストを受信した理由を偽るメッセージから、ユーザーがリクエストを停止するための承認を期待して、ユーザーにとって都合の悪い時間に大量のリクエストをトリガーするものまで、高度なものまで多岐にわたります。図 6 は、そのような攻撃の例を示しています。
The ability to trigger authorization requests without user involvement can be exploited by an attacker to overwhelm users with a high volume of requests in a short period, increasing the likelihood of inadvertent approval.
ユーザーの関与なしに承認リクエストをトリガーできる機能を攻撃者が悪用して、短期間に大量のリクエストでユーザーを圧倒し、不用意に承認される可能性が高まります。
+--------------+ +---------------+
+------>| 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 Exploit
図 6: バックチャネル転送セッション パターンの悪用
(A)
(A)
The attacker sends a social engineering message to prepare the user for the upcoming authorization (optional).
攻撃者はソーシャル エンジニアリング メッセージを送信して、今後の認証に向けてユーザーを準備させます (オプション)。
(B)
(B)
The attacker initiates the protocol on the Consumption Device (or mimics the Consumption Device) by starting a purchase, adding a device to a network, or accessing a service on the Consumption Device.
攻撃者は、購入を開始したり、ネットワークにデバイスを追加したり、消費デバイス上のサービスにアクセスしたりすることで、消費デバイス上でプロトコルを開始します (または消費デバイスを模倣します)。
(C)
(C)
The client on the Consumption Device requests user authorization on the backchannel from the Authorization Server and waits for a response from the Authorization Server.
消費デバイス上のクライアントは、認可サーバーからのバックチャネルでユーザー認可を要求し、認可サーバーからの応答を待ちます。
(D)
(D)
The Authorization Server requests user authentication and authorization on the user's Authorization Device.
認可サーバーは、ユーザーの認証とユーザーの認可デバイス上の認可を要求します。
(E)
(ホ)
If the user is unauthenticated, they use their Authorization Device to authenticate and grant authorization to the Authorization Server.
ユーザーが認証されていない場合、ユーザーは認可デバイスを使用して認証し、認可サーバーに認可を与えます。
(F)
(F)
The user is authenticated, and authorization is granted to access the user's resources (there may be several additional messages, depending on the authentication protocol, user interface, and other implementation details).
ユーザーは認証され、ユーザーのリソースへのアクセスが許可されます (認証プロトコル、ユーザー インターフェイス、およびその他の実装の詳細に応じて、いくつかの追加メッセージが存在する場合があります)。
(G)
(G)
The Authorization Server issues tokens or grants authorization to the Consumption Device, which is under the attacker's control. The attacker gains access to the user's resources and possibly any authorization artifacts like access and refresh tokens.
認可サーバーはトークンを発行するか、攻撃者の制御下にある消費デバイスに認可を与えます。攻撃者はユーザーのリソースにアクセスし、場合によってはアクセス トークンやリフレッシュ トークンなどの認証アーティファクトにもアクセスします。
In cross-device flows that follow the User-Transferred Authorization Data Pattern, the client on the Consumption Device initiates the authorization request, but the user still has to transfer the authorization data to the Consumption Device. The authorization data may take different forms, including a numerical value such as a 6-digit authorization code. The authorization request may happen as a result of user interaction with the Consumption Device but may also be triggered without the user's direct interaction with the Consumption Device.
ユーザー転送認証データ パターンに従うクロスデバイス フローでは、消費デバイス上のクライアントが認証リクエストを開始しますが、ユーザーは依然として認証データを消費デバイスに転送する必要があります。認証データは、6 桁の認証コードなどの数値を含むさまざまな形式をとる場合があります。認可リクエストは、ユーザーによる消費デバイスとの対話の結果として発生する場合もありますが、ユーザーによる消費デバイスとの直接対話なしにトリガーされる場合もあります。
Attackers exploit the User-Transferred Authorization Data Pattern by combining the social engineering techniques used to set context for users and convincing users to provide them with authorization data sent to their Authorization Devices (e.g., mobile phones). These attacks are very similar to phishing attacks, except that the attacker also has the ability to trigger the authorization request to be sent to the user directly by the Authorization Server.
攻撃者は、ユーザーにコンテキストを設定し、認証デバイス (携帯電話など) に送信される認証データをユーザーに提供するよう説得するために使用されるソーシャル エンジニアリング技術を組み合わせることにより、ユーザー転送認証データ パターンを悪用します。これらの攻撃はフィッシング攻撃に非常に似ていますが、攻撃者が認可サーバーによってユーザーに直接送信される認可リクエストをトリガーする機能も備えている点が異なります。
+--------------+ +---------------+
+------->| 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
図 7: ユーザー転送認証データ パターンの悪用
(A)
(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)
(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)
(C)
The client on the Consumption Device requests user authorization on the backchannel from the Authorization Server.
消費デバイス上のクライアントは、認可サーバーからのバックチャネルでユーザー認可を要求します。
(D)
(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.
認可サーバーは認可データ (例: 6 桁の認可コード) を認可デバイスに送信します。認証データを配布するために使用できるメカニズムの例には、テキスト メッセージ、電子メール、モバイル アプリケーションなどがあります。認証データはテキストまたは QR コードとして表示されます。
(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.
ユーザーは、ステップ (A) で攻撃者から受信したソーシャル エンジニアリング メッセージを確信し、認証デバイスで受信した認証データをコピーします。
(F)
(F)
The user forwards the authorization data to the attacker.
ユーザーは認証データを攻撃者に転送します。
(G)
(G)
The attacker enters the authorization data (e.g., a 6-digit authorization code) on the Consumption Device.
攻撃者は消費デバイスに認証データ (6 桁の認証コードなど) を入力します。
(H)
(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.
ステップ C および G のチャネルでセッションが維持されていない場合、未認証チャネルは上記のシナリオのバリエーションでも悪用される可能性があります。その場合、ユーザー (攻撃者ではなく) がフローを開始し、ソーシャル エンジニアリング技術を使用して承認データ (例: 6 桁の承認コード) を自分自身で使用するのではなく攻撃者に送信するように説得されます。認証データは、QR コードまたはテキスト文字列 (6 桁の認証コードなど) として表すことができます。次に、攻撃者はフローを開始し、認証データを使用して、ユーザーに割り当てられている権限を取得します。
Attackers exploit cross-device session transfer flows by using social engineering techniques typically used in phishing attacks to convince the user to authorize the transfer of a session and then send the session transfer code or QR code to the attacker. The absence of an authenticated channel between these two devices enables the attacker to use the session transfer code on their own device to obtain access to the session and access the user's data. These attacks are referred to as CDSP attacks.
攻撃者は、フィッシング攻撃で通常使用されるソーシャル エンジニアリング手法を使用してクロスデバイス セッション転送フローを悪用し、ユーザーにセッションの転送を承認させ、セッション転送コードまたは QR コードを攻撃者に送信します。これら 2 つのデバイス間に認証されたチャネルが存在しないため、攻撃者は自分のデバイスでセッション転送コードを使用してセッションへのアクセスを取得し、ユーザーのデータにアクセスすることができます。これらの攻撃は CDSP 攻撃と呼ばれます。
+---------------+ +---------------+
+------>| 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
図 8: クロスデバイス セッション転送パターンの悪用
(A)
(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.
攻撃者は、QR コードまたはセッション転送コードを取得した後の処理方法に関する指示を含む、セッション転送を承認する必要があることをユーザーに納得させるソーシャル エンジニアリング メッセージを送信します。
(B)
(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)
(C)
The client on the Authorization Device requests a session transfer code from the Authorization Server.
認可デバイス上のクライアントは、認可サーバーにセッション転送コードを要求します。
(D)
(D)
The Authorization Server responds with a session transfer code, which may be rendered as a QR code on the Authorization Device.
認可サーバーは、セッション転送コードで応答します。このコードは、認可デバイス上で QR コードとして表示される場合があります。
(E)
(ホ)
The user views the session transfer code, which may be rendered as a QR code.
ユーザーは、QR コードとして表示されるセッション転送コードを表示します。
(F)
(F)
The user sends the QR code or session transfer code to the attacker, following the instructions they received in step (A).
ユーザーは、ステップ (A) で受け取った指示に従って、QR コードまたはセッション転送コードを攻撃者に送信します。
(G)
(G)
Once the attacker receives the QR code, they scan it or enter it on their own Consumption Device.
攻撃者は QR コードを受け取ると、それをスキャンするか、自分の消費デバイスに入力します。
(H)
(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).
認可サーバーはセッション転送コードを検証し、消費デバイスでセッションを再開するために必要なセッション コンテキスト情報を返します。攻撃者は自分の消費デバイスでセッションを再開し、ステップ (B) でユーザーが認証デバイスで認証した情報にアクセスできるようになります。
The following examples illustrate these attacks in practical settings applied to the use cases described in Section 3.3. These examples show how the unauthenticated channel is exploited by attackers who can copy the QR codes and user codes, change the context in which they are presented using social engineering techniques, and mislead end users to grant consent to avail of services, access data, and make payments.
次の例は、セクション 3.3 で説明した使用例に適用される実際の設定でのこれらの攻撃を示しています。これらの例は、QR コードとユーザー コードをコピーし、ソーシャル エンジニアリング技術を使用してコードが表示されるコンテキストを変更し、サービスの利用、データへのアクセス、支払いの同意をエンド ユーザーに与えることができる攻撃者によって、認証されていないチャネルがどのように悪用されるかを示しています。
This exploit applies to the use case described in Section 3.3.1.
このエクスプロイトは、セクション 3.3.1 で説明されているユースケースに適用されます。
An attacker obtains a smart TV and attempts to access an online streaming service. The smart TV obtains a QR code from the streaming service Authorization Server and displays it on screen. The attacker copies the QR code and embeds it in an email that is sent to a large number of recipients. The email contains a message stating that the streaming service wants to thank them for their loyal support and by scanning the QR code, they will be able to add a bonus device to their account for no charge. One of the recipients opens the email and scans the QR code to claim the loyalty reward. The user performs multi-factor authentication, and when asked if they want a new device to be added to their account, they authorize the action. The attacker's device is now authorized to access the content and obtains an access and refresh token. The access token allows the attacker to access content, and the refresh token allows the attacker to obtain fresh tokens whenever the access token expires.
攻撃者はスマート TV を入手し、オンライン ストリーミング サービスにアクセスしようとします。スマート TV はストリーミング サービスの認証サーバーから QR コードを取得し、画面に表示します。攻撃者は QR コードをコピーし、多数の受信者に送信される電子メールに埋め込みます。この電子メールには、ストリーミング サービスが彼らの忠実なサポートに感謝したいというメッセージが含まれており、QR コードをスキャンすることでボーナス デバイスをアカウントに無料で追加できるようになります。受信者の 1 人が電子メールを開き、QR コードをスキャンしてロイヤルティ特典を請求します。ユーザーは多要素認証を実行し、新しいデバイスを自分のアカウントに追加するかどうかを尋ねられたら、そのアクションを承認します。攻撃者のデバイスはコンテンツへのアクセスを許可され、アクセス トークンとリフレッシュ トークンを取得します。アクセス トークンを使用すると、攻撃者はコンテンツにアクセスでき、リフレッシュ トークンを使用すると、アクセス トークンの有効期限が切れるたびに新しいトークンを取得できます。
The attacker scales up the attack by emulating a new smart TV, obtaining multiple QR codes and widening the audience it sends the QR code to. Whenever a recipient scans the QR code and authorizes the addition of a new device, the attacker obtains an access and refresh token, which they sell for a profit.
攻撃者は、新しいスマート TV をエミュレートして複数の QR コードを取得し、QR コードの送信先の視聴者を拡大することで攻撃を拡大します。受信者が QR コードをスキャンして新しいデバイスの追加を承認するたびに、攻撃者はアクセス トークンとリフレッシュ トークンを取得し、それを販売して利益を得ます。
This exploit applies to the use case described in Section 3.3.2.
このエクスプロイトは、セクション 3.3.2 で説明されているユースケースに適用されます。
An attacker emulates an enterprise application (e.g., an interactive whiteboard) and initiates a cross-device flow by requesting a user code and URL from the Authorization Server. The attacker obtains a list of potential victims and sends an email informing users that their files will be deleted within 24 hours if they don't follow the link, enter the user code, and authenticate. The email reminds them that this is the third time that they have 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 authentication experience, the user is interacting with a trusted user experience, reinforcing 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 continuously refresh the session by requesting new access tokens. These tokens may be exfiltrated and sold to third parties.
攻撃者はエンタープライズ アプリケーション (インタラクティブ ホワイトボードなど) をエミュレートし、認可サーバーにユーザー コードと URL を要求することでクロスデバイス フローを開始します。攻撃者は、潜在的な被害者のリストを取得し、リンクをたどり、ユーザー コードを入力し、認証しない場合はファイルが 24 時間以内に削除されることをユーザーに通知する電子メールを送信します。この電子メールは、通知を受けるのはこれが 3 回目であり、作業ファイルの削除を防ぐ最後の機会であることを通知します。1 人以上の従業員が URL をたどり、コードを入力し、多要素認証を実行して応答します。認証エクスペリエンス全体を通じて、ユーザーは信頼できるユーザー エクスペリエンスと対話し、リクエストの正当性を強化します。これらの従業員がアクセスを許可すると、攻撃者は認可サーバーからアクセス トークンとリフレッシュ トークンを取得し、それらを使用してユーザーのファイルにアクセスし、横方向攻撃を実行して他の情報へのアクセスを取得し、新しいアクセス トークンを要求してセッションを継続的にリフレッシュします。これらのトークンは盗まれて第三者に販売される可能性があります。
This exploit applies to the use case described in Section 3.3.3.
このエクスプロイトは、セクション 3.3.3 で説明されているユースケースに適用されます。
An attacker copies a QR code from a bicycle locked in a bicycle rack in a city, prints it on a label, and places the label on a bicycle at the other end of the bicycle rack. A customer approaches the bicycle that contains the replicated QR code, scans the code, and authenticates before authorizing payment for renting the bicycle. The bicycle rack unlocks the bicycle containing the original QR code, and the attacker removes the bicycle before cycling down the street, while the customer is left frustrated that the bicycle they were trying to use is not being unlocked [NYC.Bike]. The customer proceeds to unlock another bicycle and lodges a complaint with the bicycle rental company.
攻撃者は、市内の自転車ラックにロックされた自転車から QR コードをコピーし、それをラベルに印刷し、そのラベルを自転車ラックの反対側の自転車に貼り付けます。顧客は、複製された QR コードを含む自転車に近づき、コードをスキャンして認証を行った後、自転車のレンタル料の支払いを承認します。自転車ラックはオリジナルの QR コードが含まれた自転車のロックを解除し、攻撃者は通りを自転車で走る前に自転車を撤去します。一方、顧客は、使おうとしていた自転車のロックが解除されないことにイライラしたままになります [NYC.Bike]。顧客は別の自転車のロックを解除し、自転車レンタル会社に苦情を申し立てます。
These exploits apply to the use case described in Section 3.3.4.
これらのエクスプロイトは、セクション 3.3.4 で説明されているユースケースに適用されます。
An attacker obtains a list of user identifiers for a financial institution and triggers a transaction request for each of the users on the list. The financial institution's Authorization Server sends push notifications to each of the users, requesting authorization of a transaction. The vast majority of users ignore the request to authorize the transaction, but a small percentage grants authorization by approving the transaction.
攻撃者は金融機関のユーザー識別子のリストを取得し、リスト上の各ユーザーに対してトランザクション リクエストをトリガーします。金融機関の認可サーバーは各ユーザーにプッシュ通知を送信し、トランザクションの認可を要求します。大多数のユーザーはトランザクションの承認リクエストを無視しますが、少数のユーザーはトランザクションを承認することで承認を与えます。
An attacker obtains the contact information for a user and contacts them, pretending to be a representative of the user's financial institution. The attacker informs the user that there were a number of fraudulent transactions against their account and asks them to review these transactions by approving or rejecting them. The attacker then triggers a sequence of transactions. The user receives an authorization request for each transaction and declines them as they do not recognize them. The attacker then informs the user that they need to close the user's 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 provides additional authorization information to the attacker, which enables the attacker to complete their attack and defraud the user.
攻撃者は、ユーザーの連絡先情報を入手し、ユーザーの金融機関の代表者になりすまして連絡します。攻撃者は、自分のアカウントに対して多数の不正な取引があったことをユーザーに通知し、これらの取引を承認または拒否して確認するよう求めます。その後、攻撃者は一連のトランザクションをトリガーします。ユーザーはトランザクションごとに承認リクエストを受け取りますが、認識できないため拒否します。次に、攻撃者は、さらなる不正取引を防ぐために、ユーザーのアカウントを閉鎖し、すべての資金を新しいアカウントに移す必要があることをユーザーに通知します。ユーザーは、承認する別の認可リクエストを受信するか、追加の認可情報を攻撃者に提供します。これにより、攻撃者は攻撃を完了してユーザーをだますことができます。
This exploit applies to the use case described in Section 3.3.5.
このエクスプロイトは、セクション 3.3.5 で説明されているユースケースに適用されます。
An attacker creates 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 the QR code. The employee, eager to assist, initiates the process to add a new mobile device to the network. They authenticate to the network and obtain a QR code. They send the QR code 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.
攻撃者は、セキュリティ侵害の疑いを調査している信頼できるテクノロジー プロバイダーからのものであると主張して、企業の全従業員にメッセージを作成します。新しいデバイスをネットワークに参加させるために通常使用される QR コードと、その QR コードを取得するための詳細な手順を従業員に送信するよう求めます。従業員は熱心にサポートし、新しいモバイル デバイスをネットワークに追加するプロセスを開始します。ネットワークに対して認証を行い、QR コードを取得します。彼らは QR コードを攻撃者に送信します。攻撃者は QR コードをスキャンし、自分のデバイスをネットワークに追加します。彼らはこのデバイス アクセスをエントリ ポイントとして使用し、横方向の移動を実行して追加の権限を取得し、制限されたリソースにアクセスします。
This exploit applies to the use case described in Section 3.3.6.
このエクスプロイトは、セクション 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 accessed by the attacker to obtain the QR code displays a message to the attacker with instructions on how to access their account.
攻撃者は従業員のオンボーディング フローを開始し、オンボーディング ポータルから QR コードを取得してデジタル ウォレットを呼び出し、新入社員の身元を証明する検証可能な資格情報を提示します。攻撃者は、潜在的な新入社員のリストを入手し、身元調査または政府発行の身分証明書を提示する時期が来たことを通知する電子メールを送信します。新入社員は QR コードをスキャンし、デジタル ウォレットを呼び出し、資格情報を提示します。資格情報が提示されると、従業員のアカウントがアクティブ化されます。攻撃者が QR コードを取得するためにアクセスした従業員ポータルには、アカウントにアクセスする方法を説明するメッセージが攻撃者に表示されます。
This exploit applies to the use case described in Section 3.3.7.
このエクスプロイトは、セクション 3.3.7 で説明されているユースケースに適用されます。
An attacker creates a message to all employees of a company, claiming to be from the company's IT service provider. They claim that they are 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, initiates the process to transfer a session. They authenticate, obtain a QR code, and then send the QR code to the attacker. The attacker scans the QR code with their mobile phone and accesses the user's data and resources.
攻撃者は、企業の IT サービス プロバイダーからのものであると主張して、企業の全従業員に宛てたメッセージを作成します。彼らは、アプリケーションのパフォーマンスの問題を解決しようとしていると主張し、通常セッションの転送に使用される QR コードを送信するよう従業員に求めています。従業員は熱心にサポートし、セッションを転送するプロセスを開始します。彼らは認証して QR コードを取得し、その QR コードを攻撃者に送信します。攻撃者は携帯電話で QR コードをスキャンし、ユーザーのデータとリソースにアクセスします。
This exploit applies to the use case described in Section 3.3.8.
このエクスプロイトは、セクション 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.
攻撃者はコンピュータ支援設計 (CAD) アプリケーションのユーザーの認証情報を取得しますが、ユーザーの携帯電話に送信される 6 桁の認証コードがなければ認証を完了できません。攻撃者は認可リクエストをトリガーし、認可サーバーに 6 桁の認可コードをユーザーの携帯電話に送信させます。次に、攻撃者は、CAD アプリケーションのサポート デスクから来てユーザーのアカウントの問題を調査していると称してユーザーに連絡し、受信したコードを読み直すよう要求します。攻撃者がコードのコンテキストを確立しているため、ユーザーはそれを提供します。攻撃者は CAD アプリケーションにコードを入力し、ユーザーの設計へのアクセスを取得します。
This exploit applies to the use case described in Section 3.3.9.
このエクスプロイトは、セクション 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, and the attacker gains access to the portal.
攻撃者は管理ポータルへのアクセスを繰り返し試行し、ネットワーク管理者に対する承認リクエストのストリームを生成します。試行は、管理者が眠っている間に行われるようにタイミングが設定されます。管理者は電話にリクエストが届くことで目覚め、通知を止めようとして誤ってアクセスを承認してしまい、攻撃者がポータルにアクセスしてしまいます。
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.
このドキュメントでは、ユーザーが攻撃者と共謀しないシナリオのみを考慮します。
Cross-device flows that are subject to the attacks described earlier typically share the following characteristics:
前述の攻撃の対象となるクロスデバイス フローは、通常、次の特徴を共有します。
1. The attacker can initiate the flow and manipulate the context of an authorization request. For example, the attacker can obtain a QR code or user code, or the attacker can request an authentication/authorization decision from the user.
1. 攻撃者はフローを開始し、認可リクエストのコンテキストを操作する可能性があります。たとえば、攻撃者は QR コードやユーザー コードを取得したり、ユーザーに認証/認可の決定を要求したりすることができます。
2. The interaction between the Consumption Device and Authorization Device is unauthenticated. That is, it is left to the user to decide if the QR code, user code, or authentication request is being presented in a legitimate context.
2. 消費デバイスと認可デバイス間の対話は認証されません。つまり、QR コード、ユーザー コード、または認証要求が正当なコンテキストで提示されているかどうかの判断はユーザーに任されています。
Protocols that have been standardized (or are in the process of being standardized) that share these characteristics include:
これらの特性を共有する標準化された (または標準化の過程にある) プロトコルには次のものがあります。
* *IETF OAuth 2.0 device authorization grant [RFC8628]:* A standard to enable 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 on the Consumption Device and entered on a second device (e.g., a mobile phone).
* *IETF OAuth 2.0 デバイス認証許可 [RFC8628]:* 入力機能が制限されたデバイス (スマート TV、プリンター、キオスクなど) での認証を有効にする標準。このプロトコルでは、ユーザー コードまたは QR コードが消費デバイスに表示され、2 番目のデバイス (携帯電話など) に入力されます。
* *OpenID Foundation CIBA [CIBA]:* A standard developed in the OpenID Foundation that allows a device or service (e.g., a personal computer, smart TV, or kiosk) to request the OpenID Provider to initiate an authentication flow if it knows a valid identifier for the user. The user completes the authentication flow using a second device (e.g., a mobile phone). In this flow, the user does not scan a QR code or obtain a user code from the Consumption Device but is instead contacted by the OpenID Provider to complete the authentication using a push notification, email, text message, or any other suitable mechanism.
* *OpenID Foundation CIBA [CIBA]:* OpenID Foundation で開発された標準。ユーザーの有効な識別子を知っている場合、デバイスまたはサービス (パーソナル コンピューター、スマート TV、キオスクなど) が OpenID プロバイダーに認証フローの開始を要求できるようにします。ユーザーは 2 番目のデバイス (携帯電話など) を使用して認証フローを完了します。このフローでは、ユーザーは QR コードをスキャンしたり、消費デバイスからユーザー コードを取得したりするのではなく、代わりに OpenID プロバイダーから連絡を受け、プッシュ通知、電子メール、テキスト メッセージ、またはその他の適切なメカニズムを使用して認証を完了します。
* *OpenID for Verifiable Credential Protocol Suite (Issuance, Presentation):* The OpenID for Verifiable Credentials enables cross-device scenarios by allowing users to scan QR codes to retrieve credentials (Issuance; see [OpenID.VCI]) or present credentials (Presentation; see [OpenID.VP]). The QR code is presented on a device that initiates the flow.
* *OpenID for Verifiable Credential Protocol Suite (発行、プレゼンテーション):* OpenID for Verifiable Credentials は、ユーザーが QR コードをスキャンして資格情報を取得 (発行、[OpenID.VCI] を参照) または資格情報を提示 (プレゼンテーション、[OpenID.VP] を参照) できるようにすることで、クロスデバイス シナリオを可能にします。QR コードは、フローを開始するデバイスに表示されます。
* *Self-Issued OpenID Provider v2 (SIOPv2):* A standard that allows end users to present self-attested or third-party attested attributes when used with OpenID for Verifiable Credential protocols. The user scans a QR code presented by the relying party to initiate the flow.
* *自己発行 OpenID プロバイダー v2 (SIOPv2):* OpenID for Verifiable Credential プロトコルで使用する場合に、エンド ユーザーが自己証明またはサードパーティ証明の属性を提示できるようにする標準。ユーザーは、信頼当事者によって提示された QR コードをスキャンして、フローを開始します。
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 more appropriate. 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 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, increasing the risk of incorrectly inferring that a cross-device flow is occurring on a single device.
クロスデバイス プロトコルは、同じデバイスのシナリオでは使用しないでください。消費デバイスと認可デバイスが同じデバイスの場合、OpenID Connect Core [OpenID.Core] や [RFC6749] で定義されている OAuth 2.0 認可コードグラントなどのプロトコルがより適切です。プロトコルが同一デバイス モードとクロスデバイス モードの両方をサポートしている場合 ([OpenID.SIOPv2] と [OpenID.VP] など)、クロスデバイス モードは同一デバイスのシナリオに使用すべきではありません (SHOULD NOT)。認可サーバーは、同じデバイスが使用されていることを検出した場合、同じデバイスのシナリオで使用されるクロスデバイス プロトコルをブロックすることを選択してもよい(MAY)。実装者は、ネットワーク アドレス変換 (NAT) を使用する環境では、複数のデバイスが同じネットワーク アドレスから発信されているように見える可能性があり、クロスデバイス フローが単一のデバイスで発生していると誤って推測されるリスクが高まることを考慮する必要があります。
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, the API can be used to secure flows against the attacks presented in this document by ensuring proximity between the Consumption Device and Authorization Device (e.g., by leveraging Bluetooth Low Energy (BLE)). In same-device scenarios, the API can be used without proximity checks.
W3C デジタル資格情報 API [W3C.DCAPI] は、検証可能な資格情報を要求および提示するためのブラウザ API を定義する標準です。API は、同一デバイスのシナリオとクロスデバイスのシナリオの両方で使用できるように設計されています。クロスデバイスのシナリオでは、API を使用して、(Bluetooth Low Energy (BLE) を活用するなどして) 消費デバイスと認証デバイスの間の近接性を確保することにより、このドキュメントで説明されている攻撃に対してフローを保護できます。同一デバイスのシナリオでは、近接性チェックなしで API を使用できます。
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 risks that the unauthenticated channel is exploited.
認可サーバーは、デバイスのフィンガープリンティング、ネットワーク アドレス、または他の技術を使用して、同じデバイス上でクロスデバイス プロトコルが使用されているかどうかを検出してもよい(MAY)。実装者が、同一デバイスのシナリオでクロスデバイス プロトコルまたはクロスデバイス モードのプロトコルを使用することを決定した場合、認証されていないチャネルが悪用されるリスクを軽減するために、この文書で推奨されている緩和策を実装する必要があります (SHOULD)。
The unauthenticated channel between the Consumption Device and the Authorization Device allows attackers to change the context in which the authorization request is presented to the user. This shifts responsibility of authenticating the channel between the two devices to the end user. End users have "expertise elsewhere", are typically not security experts, and don't understand the protocols and systems they interact with. As a result, end users are poorly equipped to authenticate the channel between the two devices. Mitigations should focus on:
消費デバイスと認可デバイス間の未認証チャネルにより、攻撃者は認可リクエストがユーザーに提示されるコンテキストを変更することができます。これにより、2 つのデバイス間のチャネルを認証する責任がエンド ユーザーに移ります。エンドユーザーは「他の場所で専門知識」を持っており、通常はセキュリティの専門家ではなく、対話するプロトコルやシステムを理解していません。その結果、エンド ユーザーは 2 つのデバイス間のチャネルを認証する能力が不十分になります。緩和策は以下に焦点を当てる必要があります。
1. Minimizing reliance on the user to make decisions to authenticate the channel.
1. チャネルを認証するための決定を行う際のユーザーへの依存を最小限に抑えます。
2. Providing better information with which to make decisions to authenticate the channel.
2. チャネルを認証するための決定を下すためのより適切な情報を提供します。
3. Recovering from incorrect channel authentication decisions by users.
3. ユーザーによるチャネル認証の誤った決定からの回復。
To achieve the above outcomes, mitigating against CDCP attacks requires a three-pronged approach:
上記の結果を達成するには、CDCP 攻撃を軽減するために次の 3 つの側面からのアプローチが必要です。
1. Reduce the risks of deployed protocols with practical mitigations.
1. 実用的な軽減策により、導入されたプロトコルのリスクを軽減します。
2. Adopt or develop protocols that are less susceptible to these attacks where possible.
2. 可能な場合は、これらの攻撃の影響を受けにくいプロトコルを採用または開発します。
3. Provide analytical tools to assess vulnerabilities and effectiveness of mitigations.
3. 脆弱性と緩和策の有効性を評価するための分析ツールを提供します。
A number of protocols that enable cross-device flows that are susceptible to CDCP attacks are already deployed. The security profile of these protocols can be improved through practical mitigations that provide defense in depth that either:
CDCP 攻撃の影響を受けやすいクロスデバイス フローを可能にする多数のプロトコルがすでに導入されています。これらのプロトコルのセキュリティ プロファイルは、次のいずれかの多層防御を提供する実際的な緩和策によって改善できます。
1. Prevents the attack from being initiated.
1. 攻撃が開始されるのを防ぎます。
2. Disrupts the attack once it is initiated.
2. 攻撃が開始されると攻撃を中断します。
3. Remediates or reduces the impact if the attack succeeds.
3. 攻撃が成功した場合は、影響を修復または軽減します。
It is RECOMMENDED that one or more of the mitigations be applied when implementing a cross-device flow. Each mitigation, despite limitations in its effectiveness, provides an additional layer of security that may increase the difficulty of initiating an attack, disrupt attacks in progress, or reduce the impact of a successful attack.
クロスデバイス フローを実装する場合は、1 つ以上の緩和策を適用することが推奨されます。各緩和策は、その有効性に限界があるにもかかわらず、追加のセキュリティ層を提供し、攻撃の開始の難易度を高めたり、進行中の攻撃を中断したり、攻撃が成功した場合の影響を軽減したりする可能性があります。
The unauthenticated channel between the Consumption Device and Authorization Device allows attackers to obtain a QR code or user code in one location and display it in another location. Consequently, proximity-enforced cross-device flows are more resistant to CDCP attacks than proximity-less cross-device flows. Establishing proximity between the location of the Consumption Device and the Authorization Device limits an attacker's ability to launch attacks by sending user codes or QR codes to large numbers of users that are geographically distributed. Note that the Authorization Server typically cannot directly determine whether the Consumption Device and Authorization Device are physically close to each other. Instead, it must rely on the surrounding systems, protocols in use, device capabilities, or information it obtains from other systems to establish or verify proximity. The Authorization Server can validate information it receives, but it cannot independently measure or enforce proximity on its own. There are a number of ways to establish proximity, each with its own implementation benefits and limitations:
消費デバイスと認証デバイス間の非認証チャネルにより、攻撃者はある場所で QR コードまたはユーザー コードを取得し、それを別の場所で表示することができます。その結果、近接性が適用されたクロスデバイス フローは、近接性のないクロスデバイス フローよりも CDCP 攻撃に対する耐性が高くなります。消費デバイスの位置と認証デバイスとの間の近接性を確立すると、攻撃者が地理的に分散した多数のユーザーにユーザー コードまたは QR コードを送信して攻撃を開始する能力が制限されます。通常、認可サーバーは、消費デバイスと認可デバイスが物理的に互いに近いかどうかを直接判断できないことに注意してください。代わりに、近接性を確立または検証するには、周囲のシステム、使用中のプロトコル、デバイスの機能、または他のシステムから取得した情報に依存する必要があります。認可サーバーは受信した情報を検証できますが、独自に近接性を測定したり強制したりすることはできません。近接性を確立するにはさまざまな方法があり、それぞれに独自の実装上の利点と制限があります。
* Physical connectivity: This is a good indicator of proximity but requires specific ports, cables, and hardware, and it may be challenging from a user experience perspective or 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. The use of physically connected devices may introduce additional security risks (e.g., data access or device compromise through malicious peripherals), the assessment and mitigation of which are beyond the scope of this document.
* 物理的な接続: これは近接性を示す良い指標ですが、特定のポート、ケーブル、およびハードウェアが必要であり、ユーザー エクスペリエンスの観点から難しい場合や、特定の設定では不可能な場合があります (セキュリティ目的で USB ポートがブロックまたは削除されている場合など)。物理接続は、このドキュメントで説明されているエクスプロイトに耐性のあるプロトコルで使用できる FIDO デバイスのような専用ハードウェアに適している可能性があります。物理的に接続されたデバイスを使用すると、追加のセキュリティ リスク (悪意のある周辺機器によるデータ アクセスやデバイスの侵害など) が発生する可能性がありますが、その評価と軽減方法については、このドキュメントの範囲を超えています。
* 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 technology is widely deployed in mobile phones as part of payment solutions, but NFC readers are less widely deployed. BLE presents another alternative for establishing proximity but may present user experience challenges when setting up. UWB standards such as IEEE 802.15.4 and the IEEE 802.15.4z-2020 Amendment 1 enable secure ranging between devices and allow devices to establish proximity relative to each other [IEEE-802.15.4]. FIDO and WebAuthn-based cross-device flows leverage wireless proximity using BLE and are the RECOMMENDED approach for performing secure cross-device flows (see Section 6.2.3). For the presentation of digital credentials, the W3C Digital Credentials API [W3C.DCAPI] can be used.
* ワイヤレス近接性: 近距離無線通信 (NFC)、Bluetooth Low Energy (BLE)、および超広帯域 (UWB) サービスを使用して、2 つのデバイス間の近接性を証明できます。NFC テクノロジーは、決済ソリューションの一部として携帯電話に広く導入されていますが、NFC リーダーはそれほど広く導入されていません。BLE は近接性を確立するための別の代替手段を提供しますが、セットアップ時にユーザー エクスペリエンスに課題が生じる可能性があります。IEEE 802.15.4 や IEEE 802.15.4z-2020 Amendment 1 などの UWB 標準により、デバイス間の安全なレンジングが可能になり、デバイスが相互に近接性を確立できるようになります [IEEE-802.15.4]。FIDO および WebAuthn ベースのクロスデバイス フローは、BLE を使用したワイヤレス近接機能を活用しており、安全なクロスデバイス フローを実行するための推奨されるアプローチです (セクション 6.2.3 を参照)。デジタル資格情報の提示には、W3C デジタル資格情報 API [W3C.DCAPI] を使用できます。
* Shared network: Device proximity can be inferred by verifying that both devices are on the same network. This check may be performed by the Authorization Server by comparing the network addresses of the device where the code is displayed (Consumption Device) with that of the Authorization Device. Alternatively, the check can be performed on the device, provided that the network address is available. This could be achieved 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 effectively enforce it. Note that it is common for a Consumption Device (e.g., a TV) to use a Wi-Fi connection while the Authorization Device (e.g., a phone) uses a mobile network. Though physically in proximity, they don't share a network, so other proximity checks are needed.
* 共有ネットワーク: 両方のデバイスが同じネットワーク上にあることを確認することで、デバイスの近接性を推測できます。このチェックは、コードが表示されるデバイス (消費デバイス) のネットワーク アドレスと認可デバイスのネットワーク アドレスを比較することによって、認可サーバーによって実行されます。あるいは、ネットワーク アドレスが利用可能な場合は、デバイス上でチェックを実行することもできます。これは、認証サーバーが QR コード内の消費デバイスのネットワーク アドレスをエンコードし、デジタル署名を使用してコードの改ざんを防止する場合に実現できます。これには、ウォレットが対策を認識し、それを効果的に施行する必要があります。消費デバイス (テレビなど) が Wi-Fi 接続を使用し、認証デバイス (電話など) がモバイル ネットワークを使用するのが一般的であることに注意してください。物理的には近接していますが、ネットワークを共有していないため、他の近接チェックが必要です。
* Geolocation: Proximity can be established by comparing geolocation information derived from Global Navigation Satellite System (GNSS) coordinates or geolocation lookup of IP addresses and comparing proximity. Geolocation based on GNSS may vary in accuracy depending on the user's location and, when mapped to national or regional boundaries, may show a Consumption and Authorization Device in different locations if those devices are close to a border. Since relative position is more important than absolute location, implementations should consider relative location to both devices rather than absolute location when determining proximity. Geolocation based on IP addresses may be inaccurate along regional or national borders due to overlapping coverage by different network providers from the respective regions. This may result in the Consumption Device being mapped to one region, while the Authorization Device may be on another network from another provider and mapped to another region. These inaccuracies may require restrictions to be at a more granular level (e.g., same city, country, region, or continent). Similar to 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.
* 地理的位置: 全地球航法衛星システム (GNSS) 座標または IP アドレスの地理的位置検索から得られる地理的位置情報を比較し、近接性を比較することによって、近接性を確立できます。GNSS に基づく地理位置情報は、ユーザーの位置に応じて精度が異なる場合があり、国または地域の境界にマッピングされた場合、消費デバイスと認証デバイスが国境に近い場合は、異なる場所に消費デバイスと認証デバイスが表示される場合があります。相対位置は絶対位置よりも重要であるため、実装では、近接性を判断するときに絶対位置ではなく両方のデバイスに対する相対位置を考慮する必要があります。IP アドレスに基づく地理位置情報は、地域または国境に沿って、それぞれの地域の異なるネットワーク プロバイダーによるサービス範囲が重複しているため、不正確になる可能性があります。これにより、消費デバイスが 1 つのリージョンにマッピングされる一方で、認可デバイスが別のプロバイダーの別のネットワーク上にあり、別のリージョンにマッピングされる可能性があります。このような不正確さがあるため、より詳細なレベル (同じ都市、国、地域、大陸など) での制限が必要になる場合があります。共有ネットワーク チェックと同様に、QR コードにエンコードされた情報がデジタル署名を使用して完全性が保護されている場合、これらのチェックは認証サーバーまたはユーザーのデバイスで実行できます。
Depending on the risk profile and the threat model in which a system is operating, 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.
システムが動作しているリスク プロファイルと脅威モデルによっては、潜在的な攻撃者に対する基準を高めるために、複数のメカニズムを使用して近接性を確立する必要がある場合があります。ユーザーの位置の確立やユーザーのデバイスの識別に依存する近接メカニズムは、特定のアプリケーションまたは展開のコンテキスト内でプライバシーへの影響について評価されるべきです(SHOULD)。
Note: There are scenarios that require that authorization takes place in a different location than the one in which the transaction is initiated. For example, there may be a primary and secondary credit card holder, and both can initiate transactions, but only the primary holder can authorize it. There is no guarantee that the primary and secondary holders are in the same location at the time of the authorization. In such cases, proximity can still serve as a risk signal. For example, while the primary and secondary holders may normally be located in the same city, a sudden presence in different continents may prompt the system to apply additional controls (e.g., transaction value limits or transaction velocity limits) or incorporate proximity information into a broader risk management decision.
注: シナリオによっては、トランザクションが開始された場所とは別の場所で認証を行う必要がある場合があります。たとえば、プライマリ クレジット カード所有者とセカンダリ クレジット カード所有者が存在し、どちらもトランザクションを開始できますが、トランザクションを承認できるのはプライマリ カード所有者だけです。認証時に一次保有者と二次保有者が同じ場所に存在するという保証はありません。このような場合でも、近接性がリスクシグナルとして機能する可能性があります。たとえば、プライマリ保有者とセカンダリ保有者は通常同じ都市に位置している可能性がありますが、異なる大陸に突然存在すると、システムが追加の制御（取引額制限や取引速度制限など）を適用したり、より広範なリスク管理の決定に近接情報を組み込んだりする可能性があります。
*Limitations:* Proximity mechanisms make it harder to perform CDCP attacks. However, depending on how the proximity check is performed, an attacker may be able to circumvent the protection: The attacker can use a VPN to simulate a shared network or spoof a GNSS position. For example, the attacker can try to request the location of the end user's Authorization Device through browser APIs and then simulate the same location on their Consumption Device using standard debugging features available on many platforms. Relying on IP address mapping can degrade user experience when a VPN is used on the Consumption or Authorization Device. In such cases, the devices may appear to be in different locations, requiring additional user guidance or alternative mechanisms to establish proximity.
*制限事項:* 近接メカニズムにより、CDCP 攻撃の実行が困難になります。ただし、近接性チェックの実行方法によっては、攻撃者が保護を回避できる可能性があります。攻撃者は VPN を使用して、共有ネットワークをシミュレートしたり、GNSS 位置を偽装したりすることができます。たとえば、攻撃者はブラウザ API を通じてエンド ユーザーの認証デバイスの場所を要求し、多くのプラットフォームで利用可能な標準のデバッグ機能を使用して消費デバイス上の同じ場所をシミュレートしようとする可能性があります。IP アドレス マッピングに依存すると、消費デバイスまたは認証デバイスで VPN が使用されるときにユーザー エクスペリエンスが低下する可能性があります。このような場合、デバイスが異なる場所にあるように見える可能性があり、近接を確立するために追加のユーザー ガイダンスまたは代替メカニズムが必要になります。
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 is reduced, potentially increasing the cost of a successful attack. This mitigation can be implemented on the Authorization Server without changes to other system components.
QR またはユーザー コードの有効期間を短くすることで、攻撃の影響を軽減できます。攻撃者が有効期間の短いコードを入手した場合、認証されていないチャネルが悪用できる期間が短縮され、攻撃成功のコストが増加する可能性があります。この軽減策は、他のシステム コンポーネントを変更することなく、認可サーバーに実装できます。
*Limitations:* There is a practical limit to how short a user code can be valid due to network latency and user experience limitations (time taken to enter a code, time to complete authentication, or time needed 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 request the QR or user code once the user clicks on the link in the phishing email [SQPHISH].
*制限事項:* ネットワーク遅延とユーザー エクスペリエンスの制限 (コードの入力にかかる時間、認証の完了にかかる時間、またはエラーによるコードの再入力または再認証に必要な時間) により、ユーザー コードの有効期間の短縮には実質的な制限があります。より高度な CDCP 攻撃は、フィッシングメールに応答し、ユーザーがフィッシングメール内のリンクをクリックした場合にのみ QR コードまたはユーザーコードを要求するようにユーザーを誘導することで、有効期間の短いコードの有効性に対抗します [SQPHISH]。
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 is validated by the Authorization Server 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.
ユーザー コードまたは QR コードの 1 回限りの使用または限定的な使用を強制することにより、認可サーバーは、同じユーザー コードまたは QR コードが複数の被害者に送信される攻撃の影響を制限できます。1 回限りの使用は、ユーザー コードまたは QR コードにナンスまたは日付スタンプを含めることによって実現できます。ユーザーが以前に発行されたコードのリストと照合して QR コードをスキャンすると、認可サーバーによって検証されます。この軽減策は、他のシステム コンポーネントを変更することなく、認可サーバーに実装できます。
*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 may 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.
*制限事項:* 低遅延要件を備えた大規模なグローバル分散システムでは、1 回限りの使用を強制するのが難しい場合があります。その場合は、有効期間の短いトークンの方が実用的である可能性があります。使い捨てコードもユーザー エクスペリエンスに影響を与える可能性があります。たとえば、ユーザーはコードを入力できますが、アクセス要求が完了する前にセッションが中断される可能性があります。コードが 1 回限りの使用コードである場合、同じコードを 2 回入力することはできないため、セッションを再起動して新しいコードを取得する必要があります。これを避けるために、実装者は同じコードが数回提示されることを許可してもよい(MAY)。
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.
固有のユーザー コードまたは QR コードを発行することにより、認可サーバーは同じコードが繰り返し送信されているかどうかを検出できます。これは異常な動作として解釈される可能性があり、認可サーバーは、同じコードが繰り返し提示されることを検出した場合、アクセスおよびリフレッシュトークンの発行を拒否することを選択してもよい(MAY)。これは、以前に使用された QR コードまたはユーザー コードを含む拒否リストを維持することによって実現できます。有効期間が短い/期限付きのトークンが使用される場合、認可サーバーはトークンの有効期間に等しいスライディングウィンドウを使用してもよい(MAY) (セクション6.1.2を参照)。これにより、拒否リストのサイズが制限されます。この軽減策は、他のシステム コンポーネントを変更することなく、認可サーバーに実装できます。
*Limitations:* Maintaining a deny list of previously redeemed codes, even for 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.
*制限事項:* スライディング ウィンドウであっても、以前に引き換えられたコードの拒否リストを維持すると、グローバルに分散されたシステムの遅延に影響を与える可能性があります。別の方法の 1 つは、地理または地域ごとにユーザー コードをセグメント化し、ローカルの拒否リストを維持することです。
Attackers exploit the unauthenticated channel by changing the context of the user code or QR code and then sending a message to a user (email, text messaging, instant messaging, or other communication mechanisms). By deploying content filtering (e.g., anti-spam filter), these messages can be blocked and prevented from reaching the end users. It may be possible to fine-tune content-filtering solutions to detect artifacts like QR codes or user codes that are included in a message that is sent to multiple recipients in the expectation that at least one of the recipients will be convinced by the message and grant authorization to access restricted resources.
攻撃者は、ユーザー コードまたは QR コードのコンテキストを変更し、ユーザーにメッセージ (電子メール、テキスト メッセージング、インスタント メッセージング、またはその他の通信メカニズム) を送信することによって、認証されていないチャネルを悪用します。コンテンツ フィルタリング (スパム対策フィルタなど) を導入することで、これらのメッセージがブロックされ、エンド ユーザーに到達するのを防ぐことができます。コンテンツ フィルタリング ソリューションを微調整して、少なくとも 1 人の受信者がメッセージに納得し、制限されたリソースへのアクセスを許可することを期待して、複数の受信者に送信されるメッセージに含まれる QR コードやユーザー コードなどのアーティファクトを検出することが可能になる場合があります。
*Limitations:* Some scenarios may require legitimate retransmission of user data, QR codes, and authorization data (e.g., retries). To prevent the disruption of legitimate scenarios, content filters may use a threshold and allow a limited number of messages with the same QR or user codes to be transmitted before interrupting the delivery of those messages. Content filtering may also be fragmented across multiple communications systems and communication channels (email, text messaging, instant messaging, or other communication mechanisms), making it harder to detect or interrupt attacks that are executed over multiple channels, unless there is a high degree of integration between content-filtering systems.
*制限事項:* 一部のシナリオでは、ユーザー データ、QR コード、および認証データの正当な再送信 (再試行など) が必要な場合があります。正当なシナリオの中断を防ぐために、コンテンツ フィルターはしきい値を使用し、同じ QR またはユーザー コードを持つ限られた数のメッセージの送信を許可してから、それらのメッセージの配信を中断することがあります。また、コンテンツ フィルタリングは、複数の通信システムおよび通信チャネル (電子メール、テキスト メッセージング、インスタント メッセージング、またはその他の通信メカニズム) にわたって断片化される可能性があるため、コンテンツ フィルタリング システム間の高度な統合がない限り、複数のチャネル上で実行される攻撃の検出または中断が困難になります。
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.
認可サーバーは、セクション 6.1.4 で説明するように繰り返し使用することによる、またはセクション 6.1.5 で説明するコンテンツ フィルタリング エンジンからの入力として、またはエンド ユーザーからのレポートなどの他のメカニズムを通じて、コードの誤用を検出できる場合があります。ユーザーコードまたは QR コードが攻撃に使用されていると認可サーバーが判断した場合、認可サーバーは、これらのコードに応答して発行されたすべてのトークンを無効にし、その情報をトークンイントロスペクションエンドポイントを通じて利用できるようにすることを選択してもよい(MAY) ([RFC7662] を参照)。さらに、共有シグナル フレームワーク (SSF) [SSF] または同等の通知システムを使用する連続アクセス評価プロトコル (CAEP) メッセージ [CAEP] を使用して、これらのトークンの受け入れを停止するか、これらのトークンに関連付けられた既存のセッションを終了するようにリソース サーバーに通知する場合があります。
*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.
*制限事項:* 検出と修復には、リソース サーバーがセキュリティ イベント システムまたはトークン イントロスペクション サービスと統合されている必要があります。これは既存のシステムにとって必ずしも実用的であるとは限らず、環境内で最も重要なリソース サービスを対象とする必要がある場合があります。
If an attacker is unable to initiate the protocol, they are unable to obtain a QR code or user code that can be leveraged for the attacks described in this document. By restricting the protocol to only be executed on devices trusted by the Authorization Server, it prevents attackers from using arbitrary devices or mimicking devices to initiate the protocol.
攻撃者がプロトコルを開始できない場合、この文書で説明されている攻撃に利用できる QR コードまたはユーザー コードを取得できません。認可サーバーによって信頼されたデバイス上でのみプロトコルが実行されるように制限することで、攻撃者が任意のデバイスを使用したり、デバイスを模倣してプロトコルを開始したりすることを防ぎます。
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).
認可サーバーは、クロスデバイス フローに対してどのデバイスを信頼するかを確立するために、異なるメカニズムを使用してもよい(MAY)。これには、クロスデバイス フローをインタラクティブ ホワイトボードやスマート TV などの特定のデバイス タイプに制限すること、認可サーバーにデバイスを事前登録すること、またはデバイス管理システムで管理されているデバイスでのみクロスデバイス フローを許可することが含まれます。デバイス管理システムは、パッチ適用、バージョン更新、デバイス上のマルウェア対策展開、取り消しステータス、デバイスの場所などを管理するポリシーを強制する場合があります。信頼できるデバイスは、ハードウェア (たとえば、Trusted Platform Module (TPM) または同等のテクノロジー) に根ざしたアイデンティティを持つことができます (MAY)。
By only allowing trusted devices to initiate cross-device flows, it requires the attacker to have access to such a device and maintain access in a way that does not result in the device's trust status from being revoked.
信頼できるデバイスのみにクロスデバイス フローの開始を許可することで、攻撃者はそのようなデバイスにアクセスし、デバイスの信頼ステータスが取り消されない方法でアクセスを維持する必要があります。
Mechanisms that identify a specific device SHOULD be evaluated for their privacy implications within the context of a specific application or deployment.
特定のデバイスを識別するメカニズムは、特定のアプリケーションまたは展開のコンテキスト内でプライバシーへの影響について評価されるべきです(SHOULD)。
*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.
*制限事項:* 攻撃者は依然として信頼できるデバイスへのアクセスを取得し、それを使用して認可リクエストを開始できる可能性があるため、追加の制御を適用し、認可を開始するための繰り返しのリクエストや同じデバイスでの大量のサービスのアクティブ化などの不審な動作を検出できる他の脅威検出および管理システムと統合する必要があります。攻撃者は、暗号的に確立されていないか、構成証明メカニズムを通じて検証されていないデバイス ID やデバイス タイプをスプーフィングすることもあります。
An attacker can be prevented from initiating a cross-device flow protocol by only allowing the protocol to be initiated 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, which 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.
信頼されたネットワーク上またはセキュリティ境界内 (企業ネットワークなど) 内でのみプロトコルの開始を許可することで、攻撃者がクロスデバイス フロー プロトコルを開始するのを防ぐことができます。信頼できるネットワークは IP アドレスのセットとして定義でき、ネットワークへの参加はネットワーク オペレータによって管理されるセキュリティ制御の対象となります。これには、ネットワーク上で信頼できるデバイスのみを許可すること、デバイス管理、ユーザー認証、および物理アクセス ポリシーとシステムが含まれる場合があります。一部の展開では、加入者識別モジュール (SIM) またはネットワーク オペレーターによって提供される情報を使用して、信頼できるネットワークを推測することもできます。プロトコルの開始を特定のネットワークに制限することで、攻撃者はネットワーク上のデバイスにアクセスできる必要があります。この軽減策は、他のシステム コンポーネントを変更することなく、認可サーバーに実装できます。
*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.
*制限事項:* ネットワーク レベルの制御は、特にネットワークがサービス プロバイダーの制御下にない消費者シナリオを扱う場合には、常に実現可能であるとは限りません。ネットワークレベルの制御を導入できる場合でも、多層防御を達成するために、この文書で概説されている他の制御と組み合わせて使用する必要があります。
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.
認可サーバーは、2 つのデバイス間の未認証チャネルが悪用されやすいクロスデバイス フローを通じて発行されるアクセス トークンに含まれるスコープを制限することを選択してもよい(MAY)。限定されたスコープを含めることで、攻撃が成功した場合の影響を軽減します。どのスコープが含まれるかについての決定は、プロトコルが信頼できるデバイスで開始されるか、または消費デバイスの位置に対するユーザーの位置に基づいてさらに詳細化される場合があります。この軽減策は、他のシステム コンポーネントを変更することなく、認可サーバーに実装できます。
*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.
*制限事項:* 範囲を制限すると侵害の影響は軽減されますが、回避できるわけではありません。この文書で説明されている他の緩和策と組み合わせて使用する必要があります (SHOULD)。
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 serve 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 continue to request 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.
*制限事項:* 有効期間の短いトークンは、攻撃者が攻撃の成功によって利益を得ることができる時間枠を短縮します。これはアクセス トークンに対して最も効果的です。ただし、攻撃者がリフレッシュ トークンを取得すると、リフレッシュ トークンだけでなく新しいアクセス トークンも要求し続ける可能性があります。リフレッシュ トークンの有効期限を強制すると、ユーザーがアクションをより頻繁に再承認することになり、ユーザー エクスペリエンスが低下する可能性があります。
An attacker that engages in 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.
大規模な攻撃を行う攻撃者は、短期間に大量のユーザー コードを要求するか (セクション 4.3.1 で説明するエクスプロイトを参照)、または大量の承認リクエスト (セクション 4.3.4.1 および 4.3.9 で説明するエクスプロイトを参照) を開始する必要がある場合があります。認可サーバーは、限られた期間内にクライアントから受け入れるリクエスト、またはユーザーに送信するリクエストの数を最小限に抑えるために、レート制限を適用してもよい(MAY)。
*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.
*制限事項:* レート制限は、攻撃者の速度を低下させるのに効果があり、大規模な攻撃の質を低下させるのに役立ちますが、より低い量と速度で実行される、より標的を絞った攻撃を防ぐことはできません。したがって、クロスデバイス攻撃に対する多層防御を提供するには、他の技術と併用する必要があります。
Sender-constrained tokens limit the impact of a successful attack by preventing the tokens from being moved from the device on which 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 to 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 sender-constrained tokens will further reduce the ability of the attacker 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. Consequently, the main protection derived from sender-constrained tokens is preventing tokens from being moved from the Consumption Device to another device, thereby making it harder to sell stolen tokens and profit from the attack.
*制限事項:* 送信者制限付きトークン、特に所有証明を必要とする送信者制限付きトークンは、攻撃を実行し、トークンを窃取して利益を得るための基準を引き上げます。ソフトウェア所有証明キーは所有証明キーがないよりは優れていますが、それでも攻撃者がソフトウェア キーを漏洩する可能性があります。ハードウェア キーは漏洩が困難ですが、実装がさらに複雑になります。消費デバイスを制御する攻撃者は、キーがハードウェア内にある場合でも、キーを実行できる可能性があります。したがって、送信者制限付きトークンから得られる主な保護は、トークンが消費デバイスから別のデバイスに移動されることを防止することであり、これにより、盗まれたトークンを販売して攻撃から利益を得ることが困難になります。
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 request users to grant authorization, this expectation may 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.
研究によると、ユーザー教育はフィッシング攻撃のリスクを軽減するのに効果的であることが示されています[バキ2023]。サービスプロバイダーは、NIST が [NISTPhishing] で説明しているように、電子メールやその他の迷惑メッセージ内のリンクをクリックしないようにするためのガイダンスなど、より広範なフィッシング対策教育の一環として、CDCP のリスクについてユーザーを教育してもよい(MAY)。さらに、サービスプロバイダーは、認可付与が要求されるコンテキストと条件について帯域外の補強を提供してもよい(MAY)。たとえば、サービス プロバイダーがユーザーに承認を要求する QR コードを含む電子メールを送信しない場合、この期待はマーケティング コミュニケーションや不正防止啓発キャンペーンを通じて強化される可能性があります。サービスプロバイダーは、アプリ内エクスペリエンスを通じてこれらのユーザー教育メッセージを強化してもよい(MAY)。[PCRSM2023] では、たとえば、接続が TLS を使用して保護されていることや、URL が認可サーバーに属していることを確認することによって、QR コードのソースの信頼性を検証するようユーザーにアドバイスすることが提案されています。
*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.
*制限事項:* ユーザー教育は意識を高め、ユーザーに対する全体的なリスクを軽減するのに役立ちますが、それだけでは CDCP 攻撃を軽減するには不十分です。特に、慎重に設計されたフィッシング攻撃は、十分な訓練を受けたユーザーであっても、実際には無害な認証フローと区別できない場合があります。したがって、ユーザー教育は、この文書で説明されている他のコントロールと組み合わせて使用する必要があります。
The user experience SHOULD preserve the context within which the protocols were initiated and communicate this clearly to the user when they are asked to authorize, authenticate, or present a credential. In preserving the context, it should be clear to the user who invoked the flow, why it was invoked, and what the consequence of completing the authorization, authentication, or credential presentation is. The user experience SHOULD reinforce the message that unless the user initiated the authorization request, or was expecting it, they should decline the request.
ユーザーエクスペリエンスは、プロトコルが開始されたコンテキストを保存し、認可、認証、または資格情報の提示を求められたときにユーザーにこれを明確に伝えるべきです(SHOULD)。コンテキストを保持する場合、フローを呼び出したユーザー、フローが呼び出された理由、認可、認証、または資格情報の提示を完了した結果がどうなるかがユーザーに明確である必要があります。ユーザーエクスペリエンスは、ユーザーが承認リクエストを開始した場合、またはそれを予期していた場合を除き、リクエストを拒否する必要があるというメッセージを強化する必要があります。
This information MAY be communicated graphically or in a simple message (e.g., "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 department").
この情報は、グラフィックまたは単純なメッセージで伝達されてもよい(例: 「市内中心部のオフィスにあるデジタル ホワイトボード上のファイルにアクセスしようとしているようです。ファイルへのアクセスを許可するには、ここをクリックしてください。ファイルにアクセスしようとしていない場合は、この要求を拒否し、セキュリティ部門に通知する必要があります。」)。
The 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.
ユーザーインターフェースは、ユーザーがリクエストを拒否またはキャンセルするための明白かつ明確な方法を提供する必要があります。偶発的な認可付与を避けるために、「decline」オプションをデフォルトのオプションにするか、ユーザーエクスペリエンスにおいて「grant」オプションと同様の重要性を与える必要があります（SHOULD）。
If the user uses an application on a mobile device to scan a QR code, the application MAY display information advising the user under which conditions they should expect to be asked to scan a QR code and under which circumstances they should never scan a QR code (e.g., display a message that 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).
ユーザーがモバイルデバイス上のアプリケーションを使用して QR コードをスキャンする場合、そのアプリケーションは、どのような状況で QR コードのスキャンを求められることが予想されるのか、またどのような状況で QR コードをスキャンしてはいけないのかをユーザーにアドバイスする情報を表示してもよい (例: QR コードは、信頼できる場所内のキオスクまたは特定のドメインでホストされている信頼できる Web サイトにのみ表示され、電子メールやその他のメディアや場所では決して表示されないというメッセージを表示する)。
The user experience MAY include information to further educate the user on CDCP attacks and reinforce the conditions under which authorization grants may be requested.
ユーザーエクスペリエンスには、CDCP 攻撃についてユーザーをさらに教育し、認可付与が要求される条件を強化するための情報が含まれてもよい (MAY)。
*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.
*制限事項:* ユーザー エクスペリエンスを向上させるだけでは十分ではないため、このドキュメントで説明されている他のコントロールと組み合わせて使用する必要があります。
By requiring a user to authenticate on the Consumption Device with a phishing-resistant authentication method before initiating a cross-device flow, the server can prevent an attacker from initiating a cross-device flow and obtaining QR codes or user codes. For example, a banking application may initiate a cross-device authorization request using the Backchannel-Transferred Session Pattern only after the user is already authenticated and attempts a high-value transaction. This prevents the attacker from initiating a cross-device authorization request and obtaining a QR code or a user code that they can use to mislead an unsuspecting user. This requires that the Consumption Device has sufficient input capabilities to support a phishing-resistant authentication mechanism, which may in itself negate the need for a cross-device flow.
クロスデバイス フローを開始する前に、フィッシング耐性のある認証方法を使用して消費デバイスでの認証をユーザーに要求することで、サーバーは、攻撃者がクロスデバイス フローを開始して QR コードやユーザー コードを取得することを防ぐことができます。たとえば、銀行アプリケーションは、ユーザーがすでに認証され、高額のトランザクションを試行した後にのみ、バックチャネル転送セッション パターンを使用してクロスデバイス認証リクエストを開始する場合があります。これにより、攻撃者がクロスデバイス認証リクエストを開始して、疑いを持たないユーザーを誤解させるために使用できる QR コードやユーザー コードを取得することを防ぎます。これには、消費デバイスがフィッシング耐性のある認証メカニズムをサポートするのに十分な入力機能を備えていることが必要ですが、それ自体がクロスデバイス フローの必要性を無効にする可能性があります。
*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.
*制限事項:* この軽減策は、フィッシング耐性のある認証メカニズムをサポートできる消費デバイスに限定されます。クロスデバイス フローを開始する前に消費デバイスで認証を行っても、セクション 4.3.5 および 4.3.7 で説明されている攻撃は防止できません。また、クロスデバイス フローがセクション 3.3.5 および 3.3.7 で説明されているようなシナリオで使用される場合は、このドキュメントで説明されている追加の緩和策を使用することが推奨されます。
The user MAY be asked to confirm if they initiated an authentication or authorization request by sending a one-time password (OTP) or PIN to the user's Authorization Device and asking them to enter it on the Consumption Device to confirm the request. If the request was initiated without the user's consent, they would receive an OTP or PIN out of context, which may raise suspicion for the user. In addition, they would not have information on where to enter the OTP or PIN. The user experience on the Authorization Device MAY reinforce the risk of receiving an out-of-context OTP or PIN and provide information to the user on how to report an unauthorized authentication or authorization request.
ユーザーは、ワンタイムパスワード (OTP) または PIN をユーザーの認可デバイスに送信し、要求を確認するために消費デバイスにそれを入力するよう求めることで、認証または認可リクエストを開始したかどうかを確認するよう求められてもよい(MAY)。ユーザーの同意なしにリクエストが開始された場合、文脈を無視して OTP または PIN を受け取ることになり、ユーザーは疑念を抱く可能性があります。さらに、OTP または PIN を入力する場所に関する情報もありません。認可デバイスでのユーザー エクスペリエンスは、コンテキスト外の OTP または PIN を受信するリスクを強化し、不正な認証または認可リクエストを報告する方法に関する情報をユーザーに提供してもよい(MAY)。
*Limitations:* The additional verification step may reduce the overall usability of the system as it is one more thing users need to do right. Attackers may combine conventional phishing attacks and target users who respond to those messages with an interactive attack that sets the expectation with the user that they will have to provide the OTP or PIN, in addition to granting authorization for the request.
*制限事項:* 追加の検証手順は、ユーザーが正しく行う必要があるもう 1 つのことであるため、システム全体の使いやすさが低下する可能性があります。攻撃者は従来のフィッシング攻撃を組み合わせ、これらのメッセージに応答するユーザーを、要求の承認に加えて OTP または PIN を提供する必要があるという期待をユーザーに与える対話型攻撃でターゲットにする可能性があります。
In the User-Transferred Session Data Pattern, users MAY enter out-of-band information on the Consumption Device to start the authorization process. The out-of-band data entered by the user MAY then be included in the QR code, which is displayed on the Consumption Device. When the QR code is scanned by the Authorization Device, the out-of-band data is verified by the user or by the Authorization Device. The out-of-band data could be any attribute that the user or 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]).
ユーザー転送セッション データ パターンでは、ユーザーは消費デバイスに帯域外情報を入力して認証プロセスを開始してもよい(MAY)。ユーザーが入力した帯域外データは、消費デバイスに表示される QR コードに含めることができます (MAY)。QR コードが認証デバイスによってスキャンされると、帯域外データがユーザーまたは認証デバイスによって検証されます。帯域外データは、ユーザーまたは認可デバイスが認可プロセス中に取得できる任意の属性です。例には、シリアル番号、OTP または PIN、場所、またはユーザーまたは認可デバイスが認可プロセス中に呼び出したり取得したりできるその他のデータが含まれます ([MPRCS2020] および [PCRSM2023] を参照)。
*Limitations:* A sophisticated attacker may include an additional step in their attack where they create a phishing attack that gathers the out-of-band data from the user before initiating the authorization request. The additional step could also have a negative impact on the usability level of the solution.
*制限事項:* 高度な攻撃者は、承認リクエストを開始する前にユーザーから帯域外データを収集するフィッシング攻撃を作成する追加のステップを攻撃に組み込む可能性があります。追加の手順は、ソリューションの使いやすさのレベルに悪影響を与える可能性もあります。
The practical mitigations described in this section can, within the limitations described, prevent or substantially increase the difficulty of initiating attacks, disrupt attacks once they start, or reduce the impact of or remediate an attack if it succeeds. When one or more of these mitigations are combined, the overall security profile of a cross-device flow improves significantly. The following table provides a summary of these mitigations:
このセクションで説明する実際的な緩和策は、説明されている制限内で、攻撃の開始を防止または大幅に困難にすること、攻撃が開始された後に攻撃を中断すること、または攻撃が成功した場合にはその影響を軽減または修復することができます。これらの緩和策を 1 つ以上組み合わせると、クロスデバイス フローの全体的なセキュリティ プロファイルが大幅に向上します。次の表は、これらの緩和策の概要を示しています。
+=================================+=========+=========+=========+
| 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 Summary
表 1: 実際の緩和策のまとめ
Some cross-device protocols are more susceptible to the exploits described in this document than others. In this section, we will compare three different cross-device protocols in terms of their susceptibility to exploits focused on the unauthenticated channel, the prerequisites to implement and deploy them, along with guidance on when it is appropriate to use them.
一部のクロスデバイス プロトコルは、他のプロトコルに比べて、このドキュメントで説明されているエクスプロイトの影響を受けやすくなっています。このセクションでは、認証されていないチャネルに焦点を当てたエクスプロイトに対する脆弱性、実装および展開の前提条件、およびそれらを使用するのが適切な場合に関するガイダンスの観点から、3 つの異なるクロスデバイス プロトコルを比較します。
[RFC8628] is a standard to enable 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).
[RFC8628] is a standard to enable authorization on devices with constrained input capabilities (e.g., smart TVs, printers, and kiosks).このプロトコルでは、ユーザー コードまたは QR コードが消費デバイス (スマート TV) に表示または利用可能になり、2 番目のデバイス (携帯電話など) に入力されます。
There are several reports in the public domain outlining how the unauthenticated channel may be exploited to execute a CDCP attack (see [ARTDCPHISH], [DCFLOWPHISH], [NEWDCPHISH], [DEFCON29], [DCATTACK], and [SQPHISH]).
認証されていないチャネルが CDCP 攻撃を実行するためにどのように悪用されるかを概説するパブリック ドメインのレポートがいくつかあります ([ARTDCPHISH]、[DCFLOWPHISH]、[NEWDCPHISH]、[DEFCON29]、[DCATTACK]、および [SQPHISH] を参照)。
There are no assumptions in the protocol about underlying capabilities of the device, making it a "least common denominator" protocol that is expected to work on the broadest set of devices and environments.
このプロトコルには、デバイスの基礎となる機能に関する前提条件が存在しないため、最も広範なデバイスおよび環境で動作すると予想される「最小公倍数」プロトコルとなっています。
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 mitigations that can help establish proximity or prevent attackers from obtaining QR or user codes.
[RFC8628] のセキュリティに関する考慮事項のセクションに加えて、この文書で概説されている 1 つ以上の緩和策、特に近接性を確立したり、攻撃者が QR コードやユーザー コードを取得するのを防ぐのに役立つ緩和策を考慮することが推奨されます。
Only use this protocol if other cross-device protocols are not viable due to device or system constraints. Avoid using if the protected resources are sensitive, high value, or business critical. Always deploy additional mitigations like proximity or only allow with pre-registered devices. Do not use for same-device scenarios (e.g., if the Consumption Device and Authorization Device are the same device).
このプロトコルは、デバイスまたはシステムの制約により他のクロスデバイス プロトコルが実行できない場合にのみ使用してください。保護されたリソースが機密性が高い、価値が高い、またはビジネスクリティカルである場合は、使用を避けてください。近接性などの追加の緩和策を常に展開するか、事前登録されたデバイスでのみ許可します。同じデバイスのシナリオには使用しないでください (たとえば、消費デバイスと認証デバイスが同じデバイスの場合)。
CIBA [CIBA] is a standard developed in the OpenID Foundation that allows a device or service (e.g., a personal computer, smart TV, or kiosk) to request the OpenID Provider to initiate an authentication flow if it knows a valid identifier for the user. The user completes the authentication flow using a second device (e.g., a mobile phone). In this flow, the user does not scan a QR code or obtain a user code from the Consumption Device, but is instead contacted by the OpenID Provider to complete the authentication using a push notification, email, text message, or any other suitable mechanism.
CIBA [CIBA] は、OpenID Foundation で開発された標準で、ユーザーの有効な識別子を知っている場合に、デバイスまたはサービス (パーソナル コンピューター、スマート TV、キオスクなど) が OpenID プロバイダーに認証フローの開始を要求できるようにします。ユーザーは 2 番目のデバイス (携帯電話など) を使用して認証フローを完了します。このフローでは、ユーザーは QR コードをスキャンしたり消費デバイスからユーザー コードを取得したりするのではなく、代わりに OpenID プロバイダーから連絡を受け、プッシュ通知、電子メール、テキスト メッセージ、またはその他の適切なメカニズムを使用して認証を完了します。
CIBA is less susceptible to unauthenticated channel attacks, but it is still vulnerable to attackers who know or can guess the user identifier and initiate an attack as described in Section 4.3.4.1.
CIBA は未認証チャネル攻撃の影響を受けにくくなっていますが、セクション 4.3.4.1 で説明されているように、ユーザー識別子を知っているか推測できる攻撃者に対しては依然として脆弱です。
There is 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.
消費デバイスでは、特定のハードウェアをサポートする必要はありません。認可デバイスはユーザーに登録/関連付けられている必要があり、認可サーバーがこのデバイスで認可をトリガーできる必要があります。
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.
[CIBA] のセキュリティに関する考慮事項のセクションに加えて、この文書で概説されている 1 つ以上の緩和策、特に近接性を確立したり、攻撃者による認可リクエストの開始を防止したりするのに役立つ緩和策を考慮することが推奨されます。
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).
消費デバイスが消費デバイス上でユーザー識別子を取得できる場合 (入力または選択メカニズムなどを介して)、および認可サーバーが認可デバイスで認可をトリガーできる場合は、デバイス認可グラントの代わりに CIBA を使用します。同じデバイスのシナリオには使用しないでください (たとえば、消費デバイスと認証デバイスが同じデバイスの場合)。
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.
FIDO2/WebAuthn は、FIDO Alliance と W3C でそれぞれ開発された標準のスタックであり、Web ブラウザーまたはネイティブ クライアントから呼び出すことができる非対称暗号化を使用して、オリジンバインドされたフィッシング耐性のあるユーザー認証を可能にします。FIDO Client to Authenticator Protocol (CTAP) バージョン 2.2 は、「ハイブリッド トランスポート」と呼ばれる新しいクロスデバイス認証プロトコルをサポートしています。これにより、電話やタブレットなどの外部デバイスを、パーソナル コンピュータなどのプライマリ デバイスにサインインするためのローミング認証システムとして使用できるようになります。これは一般に FIDO クロスデバイス認証 (CDA) と呼ばれます。CTAP 2.2 ハイブリッド トランスポートは、クライアント プラットフォームと認証プラットフォームによって実装されます。
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.
ユーザーがモバイル デバイス (オーセンティケータ) を初めて使用して認証したい場合は、オーセンティケータをメイン デバイスにリンクする必要があります。これは、QR コードのスキャンを使用して行われます。認証者が QR コードをスキャンすると、デバイスはキーイング マテリアルとトンネル ID を含む暗号化された BLE アドバタイズメントを送信します。メイン デバイス (CTAP クライアント) と認証システムの両方が Web サービスへの接続を確立し、通常の CTAP プロトコル交換が行われます。
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.
ユーザーが認証システムをメインデバイスにリンクしたままにすることを選択した場合、その後の使用では QR コードのリンク手順は必要ありません。ユーザーは認証システムでプッシュ通知を受け取ります。
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.
CDA フローは、サービス確立に BLE アドバタイズメントを活用することで近接性を証明し、セクション 4.3 の例 B1 ～ B6 で説明されているエクスプロイトのいずれかに対する影響を大幅に軽減します。
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.
消費デバイスと認証システムの両方に、BLE サポートとインターネットへのアクセスが必要です。消費デバイスは、WebAuthn API [W3CWebAuthn] (またはネイティブ アプリのプラットフォーム固有の WebAuthn 抽象化) と FIDO CTAP、特にハイブリッド トランスポートを備えたバージョン 2.2 [FIDOCTAP22] の両方をサポートする必要があります。FIDO 認証システムとして機能するデバイスは、クロスデバイス認証システムとして使用される CTAP 2.2 以降もサポートしている必要があります。
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.
FIDO CDA は BLE の使用を通じて近接性を確立し、追加の緩和策の必要性を減らします。実装者は、このドキュメントで説明されている追加の緩和策を実装することを選択してもよい(MAY)。
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].
FIDO2/WebAuthn は、デバイスがクロスデバイス認証を実行でき、消費デバイスで適切な FIDO 資格情報が利用できない場合には、クロスデバイス認証シナリオに使用する必要があります (SHOULD)。これは、認証用の FIDO 認証器 (携帯電話など) として機能するデバイスを使用して消費デバイス (スマート TV やインタラクティブ ホワイトボードなど) に認可を与えるために、認可コードグラント [RFC6749] およびコード交換用プルーフキー (PKCE) [RFC7636] による認証方法として使用できます (MAY)。FIDO2/WebAuthn と PKCE による認可コード フローのこの組み合わせにより、デバイス認可グラント [RFC8628] によってもたらされるリスクなしに、クロスデバイス認可フローが可能になります。
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.
FIDO CDA フローは、クロスデバイス フローの未認証チャネルに対する攻撃に対する最善の保護を提供します。OAuth 2.0 および OpenID Connect プロトコルと組み合わせて、標準ベースの認可および認証フローを実現できます。FIDO2/WebAuthn サポートが利用できない場合、認可サーバーがエンド ユーザーに連絡できるチャネルがある限り、CIBA は代替手段を提供します。このようなチャネルの例には、ユーザーが自分のデバイスからアクセスできるデバイスのプッシュ通知、電子メール、テキスト メッセージなどがあります。CIBA が使用される場合、近接性を強制し、信頼できるデバイスまたは信頼できるネットワークからトランザクションを開始するための追加の緩和策を考慮する必要があります (SHOULD)。OAuth 2.0 デバイス認可グラントは最も柔軟性が高く、使用されるデバイスの要件が最も低くなりますが、デバイス間の未認証チャネルを悪用する攻撃を防ぐために追加の緩和策が展開されている場合にのみ使用することが推奨されます。
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.
OAuth や OpenID Connect などの Web 認可および認証プロトコルの経験から、これらのプロトコルのセキュリティを確保するのは難しい場合があることがわかっています。その主な理由は、ブラウザ、サーバー、基盤となるネットワークを備えた Web インフラストラクチャなど、企業が運用されている環境が複雑かつ多様で、常に進化しているためです。
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".
他の種類のプロトコルの場合と同様、この環境では脆弱性が見落とされがちです。隠れたセキュリティ問題が発生する可能性を減らす 1 つの方法は、数理論理モデルを使用してプロトコル、その環境、およびセキュリティ目標を記述し、これらのモデルを使用してセキュリティを証明しようとすることです。このアプローチは、通常「正式なセキュリティ分析」として包含されるものです。
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).
形式分析には 2 つの大きな利点があります。まず、新しい脆弱性を発見するのに創造性は必要ありません (つまり、これまで誰もこれらの攻撃を思いつかなかったとしても、新しいクラスの攻撃を発見することができます)。忠実なモデルでは、脆弱性は証明プロセス中またはそれ以前に明らかになります。第 2 に、正式な分析では、モデルの境界内での攻撃の存在を除外できます (例: モデル化されたプロトコル層、対象となる詳細レベルと機能、想定される攻撃者の能力、形式化されたセキュリティ目標)。
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.
* 「自己発行 OpenID プロバイダの形式分析」[Bauer2022] では、[OpenID.SIOPv2] のプロトコルを Web インフラストラクチャ モデル (WIM) を使用して分析しました。WIM は、Web 認証および認可プロトコルの分析用に特別に設計されています。これは手動 (ペンと紙) モデルですが、ブラウザーと Web の操作の詳細を、自動化されたモデルでは一致させるのが難しい程度にキャプチャします。以前の研究では、OAuth、OpenID Connect、および OpenID FAPI のこれまで知られていなかった欠陥が WIM を使用して発見されました。[Bauer2022] のクロスデバイス SIOPv2 フローの分析では、[OpenID.SIOPv2] のセクション 13.3 で既に説明されているリクエスト リプレイ攻撃がモデルで確認されました。緩和策は、いわゆるクロスデバイス スタブに基づいて実装されました。これは基本的に、プロトコル フローが開始する前に 2 つのデバイスをリンクする役割を果たすコンポーネントです。これは、セクション 6.1.7 で説明されている信頼できるデバイス関係の実装として見ることができます。このモデルでは緩和が効果的であることが示されました。
* 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.
* 「Grant Negotiation and Authorization Protocol のセキュリティ分析」[Helmschmidt2022] では、Grant Negotiation and Authorization Protocol (GNAP) [RFC9635] のドラフトの分析が Web インフラストラクチャ モデル (WIM) を使用して実行されました。[Bauer2022] と同じ攻撃が GNAP にも適用されることが判明しました。このケースでは、「慎重なユーザー」のモデル (セクション 6.1.13 を参照) を使用して、ユーザーによって攻撃が (少なくとも理論的には) 防止できることを示しました。
* 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.
* 「eID カードとプッシュ通知を使用したアウトオブバンド認証の良い点、悪い点、そして (それほどではない) 醜い点: 設計、形式、およびリスク分析」[MPRCS2020] で、Pernpruner et al.プライマリ デバイスでの認証試行を承認するために帯域外デバイスに配信されるプッシュ通知に依存する認証プロトコルを正式に分析しました (セクション 3.1.2 のバックチャネル転送セッション パターン)。分析は、仕様言語 ASLan++ とモデル チェッカー SATMC を使用して実行されました。分析の結果によると、彼らは「暗黙的攻撃」のカテゴリを特定および定義しました。これは、ソーシャル エンジニアリング技術を通じてユーザーをだまして悪意のある認証試行を承認させ、関連するすべての認証要素を侵害するものではありません。これらの攻撃は CDCP 攻撃の定義と一致しています。
* 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.
* 「多要素認証プロトコルの安全かつリスクを意識した設計を支援する自動化された多層手法」[PCRSM2023] では、Pernpruner et al.さまざまな粒度レベルで多要素認証プロトコルを分析するための多層手法を定義しました。彼らは、プライマリ デバイスでの認証試行を承認するためにセカンダリ デバイスでスキャンする必要がある QR コードに依存するプロトコルを正式に分析する方法論を活用しました (セクション 3.1.1 のユーザー転送セッション データ パターン)。分析の結果を考慮して、彼らは、セクション 6.1.13、6.1.16、および 6.1.17 で説明されているような、攻撃成功のリスクを防止または軽減するためのいくつかの実用的な緩和策を提案しました。
Security considerations are described in Sections 2 and 6.
セキュリティに関する考慮事項については、セクション 2 と 6 で説明します。
This document has no IANA actions.
この文書には IANA のアクションはありません。
Cross-device flows enable authorization on devices with limited input capabilities, allow for secure authentication when using public or shared devices, provide a path toward multi-factor authentication, and provide the convenience of a single, portable credential store.
クロスデバイス フローにより、入力機能が制限されたデバイスでの認証が可能になり、パブリック デバイスまたは共有デバイスを使用するときに安全な認証が可能になり、多要素認証へのパスが提供され、単一のポータブル資格情報ストアの利便性が提供されます。
The popularity of cross-device flows attracted the attention of attackers that exploit the unauthenticated channel between the Consumption Device and Authorization Device using techniques commonly used in phishing attacks. These CDCP attacks allow attackers to obtain access and refresh tokens, rather than authentication credentials, resulting in access to resources even if the user used multi-factor authentication.
クロスデバイス フローの人気は、フィッシング攻撃で一般的に使用される手法を使用して、消費デバイスと認可デバイスの間の未認証チャネルを悪用する攻撃者の注目を集めました。これらの CDCP 攻撃により、攻撃者は認証資格情報ではなくアクセス トークンやリフレッシュ トークンを取得できるようになり、その結果、ユーザーが多要素認証を使用した場合でもリソースにアクセスできるようになります。
To address these attacks, we propose a three-pronged approach that includes deploying practical mitigations to safeguard protocols that are already deployed, providing guidance on when to use different protocols (including protocols that are not susceptible to these attacks), and introducing formal methods to evaluate the impact of mitigations and find additional issues.
これらの攻撃に対処するために、私たちは、すでに展開されているプロトコルを保護するための実践的な緩和策の導入、異なるプロトコル (これらの攻撃の影響を受けにくいプロトコルを含む) をいつ使用するかについてのガイダンスの提供、緩和策の影響を評価して追加の問題を見つけるための正式な手法の導入を含む 3 つの側面からのアプローチを提案します。
[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/>.
[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/>.
The authors would like to thank 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.
著者らは、Tim Cappalli、Nick Ludwig、Adrian Frei、Nikhil Reddy Boreddy、Bjorn Hjelm、Joseph Heenan、Brian Campbell、Damien Bowden、Kristina Yasda、Tim Würtele、Karsten Meyer zu Selhausen、Maryam Mehrnezhad、Marco Pernpruner、Giada Sciaretta、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 など、この作品に対する貴重な意見、フィードバック、全般的なサポートに感謝します。
Pieter Kasselman
Defakto Security
Email: prkasselman@gmail.com
Daniel Fett
Authlete
Email: mail@danielfett.de
Filip Skokan
Okta
Email: panva.ip@gmail.com