[要約] RFC 8252は、ネイティブアプリケーション向けのOAuth 2.0の仕様であり、セキュアな認証と認可を提供することを目的としています。この仕様は、ネイティブアプリケーションがユーザーの認証情報を安全に取得し、APIへのアクセスを管理するためのガイドラインを提供します。
Internet Engineering Task Force (IETF) W. Denniss
Request for Comments: 8252 Google
BCP: 212 J. Bradley
Updates: 6749 Ping Identity
Category: Best Current Practice October 2017
ISSN: 2070-1721
OAuth 2.0 for Native Apps
ネイティブアプリのOAuth 2.0
Abstract
概要
OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice.
ネイティブアプリからのOAuth 2.0承認リクエストは、外部のユーザーエージェント、主にユーザーのブラウザーを介してのみ行う必要があります。この仕様では、セキュリティと使いやすさの理由と、ネイティブアプリと承認サーバーがこのベストプラクティスを実装する方法について詳しく説明します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It 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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8252.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8252で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Authorization Flow for Native Apps Using the Browser . . 5
5. Using Inter-App URI Communication for OAuth . . . . . . . . . 6
6. Initiating the Authorization Request from a Native App . . . 6
7. Receiving the Authorization Response in a Native App . . . . 7
7.1. Private-Use URI Scheme Redirection . . . . . . . . . . . 8
7.2. Claimed "https" Scheme URI Redirection . . . . . . . . . 9
7.3. Loopback Interface Redirection . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Protecting the Authorization Code . . . . . . . . . . . . 10
8.2. OAuth Implicit Grant Authorization Flow . . . . . . . . . 11
8.3. Loopback Redirect Considerations . . . . . . . . . . . . 11
8.4. Registration of Native App Clients . . . . . . . . . . . 12
8.5. Client Authentication . . . . . . . . . . . . . . . . . . 12
8.6. Client Impersonation . . . . . . . . . . . . . . . . . . 13
8.7. Fake External User-Agents . . . . . . . . . . . . . . . . 13
8.8. Malicious External User-Agents . . . . . . . . . . . . . 14
8.9. Cross-App Request Forgery Protections . . . . . . . . . . 14
8.10. Authorization Server Mix-Up Mitigation . . . . . . . . . 14
8.11. Non-Browser External User-Agents . . . . . . . . . . . . 15
8.12. Embedded User-Agents . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Server Support Checklist . . . . . . . . . . . . . . 18
Appendix B. Platform-Specific Implementation Details . . . . . . 18
B.1. iOS Implementation Details . . . . . . . . . . . . . . . 18
B.2. Android Implementation Details . . . . . . . . . . . . . 19
B.3. Windows Implementation Details . . . . . . . . . . . . . 19
B.4. macOS Implementation Details . . . . . . . . . . . . . . 20
B.5. Linux Implementation Details . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Section 9 of the OAuth 2.0 authorization framework [RFC6749] documents two approaches for native apps to interact with the authorization endpoint: an embedded user-agent and an external user-agent.
OAuth 2.0承認フレームワーク[RFC6749]のセクション9には、ネイティブアプリが承認エンドポイントと対話するための2つのアプローチ、つまり埋め込みユーザーエージェントと外部ユーザーエージェントが記載されています。
This best current practice requires that only external user-agents like the browser are used for OAuth by native apps. It documents how native apps can implement authorization flows using the browser as the preferred external user-agent as well as the requirements for authorization servers to support such usage.
このベストプラクティスでは、ネイティブアプリによるOAuthには、ブラウザーなどの外部ユーザーエージェントのみを使用する必要があります。ネイティブアプリがブラウザを優先外部ユーザーエージェントとして使用して認証フローを実装する方法と、そのような使用をサポートする認証サーバーの要件について説明します。
This practice is also known as the "AppAuth pattern", in reference to open-source libraries [AppAuth] that implement it.
この手法は、それを実装するオープンソースライブラリ[AppAuth]に関連して、「AppAuthパターン」としても知られています。
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]で説明されているように解釈されます。
In addition to the terms defined in referenced specifications, this document uses the following terms:
参照仕様で定義されている用語に加えて、このドキュメントでは次の用語を使用しています。
"native app" An app or application that is installed by the user to their device, as distinct from a web app that runs in the browser context only. Apps implemented using web-based technology but distributed as a native app, so-called "hybrid apps", are considered equivalent to native apps for the purpose of this specification.
「ネイティブアプリ」ブラウザコンテキストでのみ実行されるウェブアプリとは異なり、ユーザーがデバイスにインストールするアプリまたはアプリケーション。ウェブベースのテクノロジーを使用して実装されているが、ネイティブアプリとして配布されるアプリ、いわゆる「ハイブリッドアプリ」は、この仕様ではネイティブアプリと同等と見なされます。
"app" A "native app" unless further specified.
「アプリ」特に指定のない限り、「ネイティブアプリ」。
"app store" An e-commerce store where users can download and purchase apps.
「アプリストア」ユーザーがアプリをダウンロードして購入できるeコマースストア。
"OAuth" Authorization protocol specified by the OAuth 2.0 Authorization Framework [RFC6749].
OAuth 2.0 Authorization Framework [RFC6749]によって指定された「OAuth」認証プロトコル。
"external user-agent" A user-agent capable of handling the authorization request that is a separate entity or security domain to the native app making the request, such that the app cannot access the cookie storage, nor inspect or modify page content.
「外部ユーザーエージェント」アプリがCookieストレージにアクセスしたり、ページコンテンツを検査または変更したりできないように、リクエストを行うネイティブアプリとは別のエンティティまたはセキュリティドメインである承認リクエストを処理できるユーザーエージェント。
"embedded user-agent" A user-agent hosted by the native app making the authorization request that forms a part of the app or shares the same security domain such that the app can access the cookie storage and/or inspect or modify page content.
「組み込みユーザーエージェント」アプリの一部を形成する、または同じセキュリティドメインを共有してアプリがCookieストレージにアクセスしたり、ページコンテンツを検査または変更したりできるように、ネイティブアプリによってホストされるユーザーエージェント。
"browser" The default application launched by the operating system to handle "http" and "https" scheme URI content.
"browser" "http"および "https"スキームのURIコンテンツを処理するためにオペレーティングシステムによって起動されるデフォルトのアプリケーション。
"in-app browser tab" A programmatic instantiation of the browser that is displayed inside a host app but that retains the full security properties and authentication state of the browser. It has different platform-specific product names, several of which are detailed in Appendix B.
「アプリ内ブラウザータブ」ホストアプリ内に表示されるが、ブラウザーの完全なセキュリティプロパティと認証状態を保持する、ブラウザーのプログラムによるインスタンス化。異なるプラットフォーム固有の製品名があり、そのいくつかは付録Bで詳しく説明されています。
"web-view" A web browser UI (user interface) component that is embedded in apps to render web pages under the control of the app.
"web-view"アプリの制御下でWebページをレンダリングするためにアプリに埋め込まれたWebブラウザーUI（ユーザーインターフェイス）コンポーネント。
"inter-app communication" Communication between two apps on a device.
「アプリ間通信」デバイス上の2つのアプリ間の通信。
"claimed "https" scheme URI" Some platforms allow apps to claim an "https" scheme URI after proving ownership of the domain name. URIs claimed in such a way are then opened in the app instead of the browser.
「要求された「https」スキームURI」一部のプラットフォームでは、アプリがドメイン名の所有権を証明した後に「https」スキームURIを要求できます。このようにして要求されたURIは、ブラウザーではなくアプリで開かれます。
"private-use URI scheme" As used by this document, a URI scheme defined by the app (following the requirements of Section 3.8 of [RFC7595]) and registered with the operating system. URI requests to such schemes launch the app that registered it to handle the request.
「私用URIスキーム」このドキュメントで使用されているように、アプリによって定義され（[RFC7595]のセクション3.8の要件に従って）、オペレーティングシステムに登録されたURIスキーム。そのようなスキームへのURIリクエストは、リクエストを処理するためにそれを登録したアプリを起動します。
"reverse domain name notation" A naming convention based on the domain name system, but one where the domain components are reversed, for example, "app.example.com" becomes "com.example.app".
「逆ドメイン名表記」ドメイン名システムに基づく命名規則。ただし、ドメインコンポーネントが逆になっているもの、たとえば、「app.example.com」は「com.example.app」になります。
For authorizing users in native apps, the best current practice is to perform the OAuth authorization request in an external user-agent (typically the browser) rather than an embedded user-agent (such as one implemented with web-views).
ネイティブアプリでユーザーを承認するための現在のベストプラクティスは、埋め込みユーザーエージェント（Webビューで実装されたものなど）ではなく、外部ユーザーエージェント（通常はブラウザー）でOAuth承認リクエストを実行することです。
Previously, it was common for native apps to use embedded user-agents (commonly implemented with web-views) for OAuth authorization requests. That approach has many drawbacks, including the host app being able to copy user credentials and cookies as well as the user needing to authenticate from scratch in each app. See Section 8.12
以前は、ネイティブアプリがOAuth承認リクエストに埋め込みユーザーエージェント（通常はWebビューで実装）を使用するのが一般的でした。このアプローチには多くの欠点があります。たとえば、ホストアプリがユーザーの資格情報とCookieをコピーできることや、ユーザーが各アプリで最初から認証する必要があることです。セクション8.12を参照
for a deeper analysis of the drawbacks of using embedded user-agents for OAuth.
OAuthに組み込みのユーザーエージェントを使用することの欠点をより深く分析するため。
Native app authorization requests that use the browser are more secure and can take advantage of the user's authentication state. Being able to use the existing authentication session in the browser enables single sign-on, as users don't need to authenticate to the authorization server each time they use a new app (unless required by the authorization server policy).
ブラウザーを使用するネイティブアプリ承認リクエストはより安全で、ユーザーの認証状態を利用できます。ユーザーは新しいアプリを使用するたびに承認サーバーに認証する必要がないため、ブラウザーで既存の認証セッションを使用できるため、シングルサインオンが可能になります（承認サーバーポリシーで要求されない限り）。
Supporting authorization flows between a native app and the browser is possible without changing the OAuth protocol itself, as the OAuth authorization request and response are already defined in terms of URIs. This encompasses URIs that can be used for inter-app communication. Some OAuth server implementations that assume all clients are confidential web clients will need to add an understanding of public native app clients and the types of redirect URIs they use to support this best practice.
OAuth認証のリクエストとレスポンスはURIで既に定義されているため、OAuthプロトコル自体を変更せずに、ネイティブアプリとブラウザ間の認証フローをサポートできます。これには、アプリ間通信に使用できるURIが含まれます。すべてのクライアントが機密Webクライアントであると想定する一部のOAuthサーバー実装は、パブリックネイティブアプリクライアントと、クライアントがこのベストプラクティスをサポートするために使用するリダイレクトURIのタイプについての理解を追加する必要があります。
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| User Device |
| |
| +--------------------------+ | (5) Authorization +---------------+
| | | | Code | |
| | Client App |---------------------->| Token |
| | |<----------------------| Endpoint |
| +--------------------------+ | (6) Access Token, | |
| | ^ | Refresh Token +---------------+
| | | |
| | | |
| | (1) | (4) |
| | Authorizat- | Authoriza- |
| | ion Request | tion Code |
| | | |
| | | |
| v | |
| +---------------------------+ | (2) Authorization +---------------+
| | | | Request | |
| | Browser |--------------------->| Authorization |
| | |<---------------------| Endpoint |
| +---------------------------+ | (3) Authorization | |
| | Code +---------------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Figure 1: Native App Authorization via an External User-Agent
図1：外部ユーザーエージェントを介したネイティブアプリの承認
Figure 1 illustrates the interaction between a native app and the browser to authorize the user.
図1は、ユーザーを認証するためのネイティブアプリとブラウザー間の対話を示しています。
(1) Client app opens a browser tab with the authorization request.
（1）クライアントアプリが承認リクエストを含むブラウザータブを開きます。
(2) Authorization endpoint receives the authorization request, authenticates the user, and obtains authorization. Authenticating the user may involve chaining to other authentication systems.
（2）許可エンドポイントは、許可要求を受け取り、ユーザーを認証し、許可を取得します。ユーザーの認証には、他の認証システムへのチェーンが含まれる場合があります。
(3) Authorization server issues an authorization code to the redirect URI.
（3）承認サーバーは、リダイレクトURIに承認コードを発行します。
(4) Client receives the authorization code from the redirect URI.
（4）クライアントはリダイレクトURIから認証コードを受け取ります。
(5) Client app presents the authorization code at the token endpoint.
（5）クライアントアプリは、トークンエンドポイントで認証コードを提示します。
(6) Token endpoint validates the authorization code and issues the tokens requested.
（6）トークンエンドポイントは認証コードを検証し、要求されたトークンを発行します。
Just as URIs are used for OAuth 2.0 [RFC6749] on the web to initiate the authorization request and return the authorization response to the requesting website, URIs can be used by native apps to initiate the authorization request in the device's browser and return the response to the requesting native app.
URIがWeb上のOAuth 2.0 [RFC6749]に使用されて認証リクエストを開始し、認証レスポンスをリクエスト元のウェブサイトに返すのと同じように、ネイティブアプリはURIを使用してデバイスのブラウザーで認証リクエストを開始し、レスポンスをリクエストしているネイティブアプリ。
By adopting the same methods used on the web for OAuth, benefits seen in the web context like the usability of a single sign-on session and the security of a separate authentication context are likewise gained in the native app context. Reusing the same approach also reduces the implementation complexity and increases interoperability by relying on standards-based web flows that are not specific to a particular platform.
WebでOAuthに使用されているものと同じ方法を採用することにより、シングルサインオンセッションの使いやすさや個別の認証コンテキストのセキュリティなど、Webコンテキストで見られる利点がネイティブアプリコンテキストでも得られます。同じアプローチを再利用すると、特定のプラットフォームに固有ではない標準ベースのWebフローに依存することにより、実装の複雑さが軽減され、相互運用性が向上します。
To conform to this best practice, native apps MUST use an external user-agent to perform OAuth authorization requests. This is achieved by opening the authorization request in the browser (detailed in Section 6) and using a redirect URI that will return the authorization response back to the native app (defined in Section 7).
このベストプラクティスに準拠するには、ネイティブアプリが外部ユーザーエージェントを使用してOAuth承認リクエストを実行する必要があります。これは、ブラウザーで承認リクエストを開き（セクション6で詳しく説明）、承認応答をネイティブアプリに返すリダイレクトURI（セクション7で定義）を使用して実現されます。
Native apps needing user authorization create an authorization request URI with the authorization code grant type per Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being received by the native app.
ユーザー認証を必要とするネイティブアプリは、OAuth 2.0 [RFC6749]のセクション4.1に従って、ネイティブアプリが受信できるリダイレクトURIを使用して、認証コード付与タイプの認証リクエストURIを作成します。
The function of the redirect URI for a native app authorization request is similar to that of a web-based authorization request. Rather than returning the authorization response to the OAuth client's server, the redirect URI used by a native app returns the response to the app. Several options for a redirect URI that will return the authorization response to the native app in different platforms are documented in Section 7. Any redirect URI that allows the app to receive the URI and inspect its parameters is viable.
ネイティブアプリの認証リクエストのリダイレクトURIの機能は、ウェブベースの認証リクエストの機能に似ています。承認応答をOAuthクライアントのサーバーに返すのではなく、ネイティブアプリが使用するリダイレクトURIが応答をアプリに返します。さまざまなプラットフォームのネイティブアプリに承認応答を返すリダイレクトURIのいくつかのオプションは、セクション7に記載されています。アプリがURIを受信してそのパラメーターを検査できるようにするリダイレクトURIはすべて有効です。
Public native app clients MUST implement the Proof Key for Code Exchange (PKCE [RFC7636]) extension to OAuth, and authorization servers MUST support PKCE for such clients, for the reasons detailed in Section 8.1.
パブリックネイティブアプリクライアントは、OAuthのコード交換（PKCE [RFC7636]）拡張機能を実装する必要があり、承認サーバーは、セクション8.1に詳述されている理由により、そのようなクライアントのPKCEをサポートする必要があります。
After constructing the authorization request URI, the app uses platform-specific APIs to open the URI in an external user-agent. Typically, the external user-agent used is the default browser, that is, the application configured for handling "http" and "https" scheme URIs on the system; however, different browser selection criteria and other categories of external user-agents MAY be used.
承認リクエストURIを作成した後、アプリはプラットフォーム固有のAPIを使用して、外部ユーザーエージェントでURIを開きます。通常、使用される外部ユーザーエージェントはデフォルトのブラウザです。つまり、システム上の「http」および「https」スキームURIを処理するように構成されたアプリケーションです。ただし、異なるブラウザ選択基準やその他の外部ユーザーエージェントのカテゴリを使用してもよい（MAY）。
This best practice focuses on the browser as the RECOMMENDED external user-agent for native apps. An external user-agent designed specifically for user authorization and capable of processing authorization requests and responses like a browser MAY also be used. Other external user-agents, such as a native app provided by the authorization server may meet the criteria set out in this best practice, including using the same redirection URI properties, but their use is out of scope for this specification.
このベストプラクティスは、ネイティブアプリに推奨される外部ユーザーエージェントとしてのブラウザーに焦点を当てています。ユーザー認証用に特別に設計され、ブラウザのような認証リクエストとレスポンスを処理できる外部ユーザーエージェントも使用できます。承認サーバーによって提供されるネイティブアプリなどの他の外部ユーザーエージェントは、同じリダイレクトURIプロパティの使用など、このベストプラクティスで設定された基準を満たしている可能性がありますが、その使用はこの仕様の範囲外です。
Some platforms support a browser feature known as "in-app browser tabs", where an app can present a tab of the browser within the app context without switching apps, but still retain key benefits of the browser such as a shared authentication state and security context. On platforms where they are supported, it is RECOMMENDED, for usability reasons, that apps use in-app browser tabs for the authorization request.
一部のプラットフォームは、「アプリ内ブラウザータブ」と呼ばれるブラウザー機能をサポートしています。このアプリでは、アプリを切り替えることなく、アプリのコンテキスト内でブラウザーのタブを表示できますが、共有認証状態やセキュリティなどのブラウザーの主要な利点は保持されます。環境。サポートされているプラットフォームでは、使いやすさの理由から、アプリが承認リクエストにアプリ内ブラウザのタブを使用することをお勧めします。
There are several redirect URI options available to native apps for receiving the authorization response from the browser, the availability and user experience of which varies by platform.
ブラウザから承認応答を受信するためにネイティブアプリで使用できるいくつかのリダイレクトURIオプションがあり、その可用性とユーザーエクスペリエンスはプラットフォームによって異なります。
To fully support this best practice, authorization servers MUST offer at least the three redirect URI options described in the following subsections to native apps. Native apps MAY use whichever redirect option suits their needs best, taking into account platform-specific implementation details.
このベストプラクティスを完全にサポートするには、承認サーバーが、次のサブセクションで説明する少なくとも3つのリダイレクトURIオプションをネイティブアプリに提供する必要があります。ネイティブアプリは、プラットフォーム固有の実装の詳細を考慮して、ニーズに最も適したリダイレクトオプションを使用できます。
Many mobile and desktop computing platforms support inter-app communication via URIs by allowing apps to register private-use URI schemes (sometimes colloquially referred to as "custom URL schemes") like "com.example.app". When the browser or another app attempts to load a URI with a private-use URI scheme, the app that registered it is launched to handle the request.
多くのモバイルおよびデスクトップコンピューティングプラットフォームは、アプリが「com.example.app」のような私用のURIスキーム（口語的に「カスタムURLスキーム」と呼ばれることもある）を登録できるようにすることで、URIを介したアプリ間通信をサポートします。ブラウザーまたは別のアプリが専用URIスキームでURIをロードしようとすると、それを登録したアプリが起動され、リクエストを処理します。
To perform an OAuth 2.0 authorization request with a private-use URI scheme redirect, the native app launches the browser with a standard authorization request, but one where the redirection URI utilizes a private-use URI scheme it registered with the operating system.
プライベート使用のURIスキームリダイレクトでOAuth 2.0承認リクエストを実行するには、ネイティブアプリが標準の認証リクエストでブラウザーを起動しますが、リダイレクトURIは、オペレーティングシステムに登録されたプライベート使用のURIスキームを利用します。
When choosing a URI scheme to associate with the app, apps MUST use a URI scheme based on a domain name under their control, expressed in reverse order, as recommended by Section 3.8 of [RFC7595] for private-use URI schemes.
アプリに関連付けるURIスキームを選択する場合、アプリは自分の制御下にあるドメイン名に基づくURIスキームを使用する必要があります。これは、[RFC7595]のセクション3.8の私的使用URIスキームで推奨されているように、逆順で表されます。
For example, an app that controls the domain name "app.example.com" can use "com.example.app" as their scheme. Some authorization servers assign client identifiers based on domain names, for example, "client1234.usercontent.example.net", which can also be used as the domain name for the scheme when reversed in the same manner. A scheme such as "myapp", however, would not meet this requirement, as it is not based on a domain name.
たとえば、ドメイン名「app.example.com」を制御するアプリは、スキームとして「com.example.app」を使用できます。一部の認証サーバーは、「client1234.usercontent.example.net」などのドメイン名に基づいてクライアント識別子を割り当てます。これは、同じ方法で逆にした場合にスキームのドメイン名としても使用できます。ただし、「myapp」などのスキームは、ドメイン名に基づいていないため、この要件を満たしません。
When there are multiple apps by the same publisher, care must be taken so that each scheme is unique within that group. On platforms that use app identifiers based on reverse-order domain names, those identifiers can be reused as the private-use URI scheme for the OAuth redirect to help avoid this problem.
同じパブリッシャーによる複数のアプリがある場合、各スキームがそのグループ内で一意になるように注意する必要があります。逆順ドメイン名に基づくアプリ識別子を使用するプラットフォームでは、これらの識別子をOAuthリダイレクトのプライベート使用URIスキームとして再利用して、この問題を回避できます。
Following the requirements of Section 3.2 of [RFC3986], as there is no naming authority for private-use URI scheme redirects, only a single slash ("/") appears after the scheme component. A complete example of a redirect URI utilizing a private-use URI scheme is:
[RFC3986]のセクション3.2の要件に従い、プライベート使用のURIスキームリダイレクトには命名機関がないため、スキームコンポーネントの後には単一のスラッシュ（ "/"）のみが表示されます。私用URIスキームを利用したリダイレクトURIの完全な例は次のとおりです。
com.example.app:/oauth2redirect/example-provider
When the authorization server completes the request, it redirects to the client's redirection URI as it would normally. As the redirection URI uses a private-use URI scheme, it results in the operating system launching the native app, passing in the URI as a launch parameter. Then, the native app uses normal processing for the authorization response.
認可サーバーがリクエストを完了すると、通常どおり、クライアントのリダイレクトURIにリダイレクトします。リダイレクトURIは私用のURIスキームを使用するため、オペレーティングシステムがネイティブアプリを起動し、起動パラメーターとしてURIを渡します。次に、ネイティブアプリは認証応答に通常の処理を使用します。
Some operating systems allow apps to claim "https" scheme [RFC7230] URIs in the domains they control. When the browser encounters a claimed URI, instead of the page being loaded in the browser, the native app is launched with the URI supplied as a launch parameter.
一部のオペレーティングシステムでは、アプリが制御するドメインで「https」スキーム[RFC7230] URIを要求できます。ブラウザが要求されたURIを検出すると、ブラウザにロードされているページの代わりに、起動パラメータとして指定されたURIでネイティブアプリが起動されます。
Such URIs can be used as redirect URIs by native apps. They are indistinguishable to the authorization server from a regular web-based client redirect URI. An example is:
このようなURIは、ネイティブアプリでリダイレクトURIとして使用できます。これらは、通常のWebベースのクライアントリダイレクトURIと承認サーバーを区別できません。例は次のとおりです。
https://app.example.com/oauth2redirect/example-provider
As the redirect URI alone is not enough to distinguish public native app clients from confidential web clients, it is REQUIRED in Section 8.4 that the client type be recorded during client registration to enable the server to determine the client type and act accordingly.
リダイレクトURIだけでは、パブリックネイティブアプリクライアントと機密Webクライアントを区別するのに十分ではないため、8.4節では、クライアントの登録時にクライアントタイプを記録して、サーバーがクライアントタイプを判別し、それに応じて動作できるようにする必要があります。
App-claimed "https" scheme redirect URIs have some advantages compared to other native app redirect options in that the identity of the destination app is guaranteed to the authorization server by the operating system. For this reason, native apps SHOULD use them over the other options where possible.
アプリが要求する「https」スキームのリダイレクトURIには、他のネイティブアプリのリダイレクトオプションと比較して、宛先アプリのIDがオペレーティングシステムによって承認サーバーに保証されるという利点があります。このため、可能な場合、ネイティブアプリは他のオプションよりもそれらを使用する必要があります（SHOULD）。
Native apps that are able to open a port on the loopback network interface without needing special permissions (typically, those on desktop operating systems) can use the loopback interface to receive the OAuth redirect.
特別な権限を必要とせずにループバックネットワークインターフェースでポートを開くことができるネイティブアプリ（通常、デスクトップオペレーティングシステム上のもの）は、ループバックインターフェースを使用してOAuthリダイレクトを受信できます。
Loopback redirect URIs use the "http" scheme and are constructed with the loopback IP literal and whatever port the client is listening on.
ループバックリダイレクトURIは「http」スキームを使用し、ループバックIPリテラルとクライアントがリッスンしているポートで構成されます。
That is, "http://127.0.0.1:{port}/{path}" for IPv4, and "http://[::1]:{port}/{path}" for IPv6. An example redirect using the IPv4 loopback interface with a randomly assigned port:
つまり、IPv4の場合は「http://127.0.0.1:{port}/{path}」、IPv6の場合は「http：// [:: 1]：{port} / {path}」です。ランダムに割り当てられたポートでIPv4ループバックインターフェイスを使用したリダイレクトの例：
http://127.0.0.1:51004/oauth2redirect/example-provider
An example redirect using the IPv6 loopback interface with a randomly assigned port:
ランダムに割り当てられたポートでIPv6ループバックインターフェイスを使用したリダイレクトの例：
http://[::1]:61023/oauth2redirect/example-provider
The authorization server MUST allow any port to be specified at the time of the request for loopback IP redirect URIs, to accommodate clients that obtain an available ephemeral port from the operating system at the time of the request.
承認サーバーは、リクエスト時にオペレーティングシステムから使用可能な一時ポートを取得するクライアントに対応するために、ループバックIPリダイレクトURIのリクエスト時に任意のポートを指定できるようにする必要があります。
Clients SHOULD NOT assume that the device supports a particular version of the Internet Protocol. It is RECOMMENDED that clients attempt to bind to the loopback interface using both IPv4 and IPv6 and use whichever is available.
クライアントは、デバイスが特定のバージョンのインターネットプロトコルをサポートしていることを前提にしないでください。クライアントがIPv4とIPv6の両方を使用してループバックインターフェイスにバインドし、使用可能な方を使用することをお勧めします。
The redirect URI options documented in Section 7 share the benefit that only a native app on the same device or the app's own website can receive the authorization code, which limits the attack surface. However, code interception by a different native app running on the same device may be possible.
セクション7に記載されているリダイレクトURIオプションは、同じデバイス上のネイティブアプリまたはアプリの独自のWebサイトのみが認証コードを受信できるという利点を共有し、攻撃対象を制限します。ただし、同じデバイスで実行されている別のネイティブアプリによるコードのインターセプトは可能です。
A limitation of using private-use URI schemes for redirect URIs is that multiple apps can typically register the same scheme, which makes it indeterminate as to which app will receive the authorization code. Section 1 of PKCE [RFC7636] details how this limitation can be used to execute a code interception attack.
リダイレクトURIに私用URIスキームを使用する場合の制限は、通常、複数のアプリが同じスキームを登録できるため、どのアプリが認証コードを受け取るかが不確定になることです。 PKCE [RFC7636]のセクション1では、この制限を使用してコード傍受攻撃を実行する方法について詳しく説明しています。
Loopback IP-based redirect URIs may be susceptible to interception by other apps accessing the same loopback interface on some operating systems.
ループバックIPベースのリダイレクトURIは、一部のオペレーティングシステムで同じループバックインターフェースにアクセスする他のアプリによる傍受の影響を受ける可能性があります。
App-claimed "https" scheme redirects are less susceptible to URI interception due to the presence of the URI authority, but the app is still a public client; further, the URI is sent using the operating system's URI dispatch handler with unknown security properties.
アプリが要求する「https」スキームのリダイレクトは、URI機関の存在により、URIインターセプトの影響を受けにくくなっていますが、アプリは引き続きパブリッククライアントです。さらに、URIは、オペレーティングシステムのURIディスパッチハンドラーを使用して、未知のセキュリティプロパティで送信されます。
The PKCE [RFC7636] protocol was created specifically to mitigate this attack. It is a proof-of-possession extension to OAuth 2.0 that protects the authorization code from being used if it is intercepted. To provide protection, this extension has the client generate a secret verifier; it passes a hash of this verifier in the initial authorization request, and must present the unhashed verifier when redeeming the authorization code. An app that intercepted the authorization code would not be in possession of this secret, rendering the code useless.
PKCE [RFC7636]プロトコルは、この攻撃を軽減するために特別に作成されました。これはOAuth 2.0の所有証明の拡張であり、認証コードが傍受された場合に使用されるのを防ぎます。保護を提供するために、この拡張機能ではクライアントに秘密の検証を生成させます。最初の認証リクエストでこのベリファイアのハッシュを渡し、認証コードを引き換えるときにハッシュされていないベリファイアを提示する必要があります。認証コードを傍受したアプリはこの秘密を保持しておらず、コードは役に立たなくなります。
Section 6 requires that both clients and servers use PKCE for public native app clients. Authorization servers SHOULD reject authorization requests from native apps that don't use PKCE by returning an error message, as defined in Section 4.4.1 of PKCE [RFC7636].
セクション6では、クライアントとサーバーの両方がパブリックネイティブアプリクライアントにPKCEを使用する必要があります。承認サーバーは、PKCE [RFC7636]のセクション4.4.1で定義されているエラーメッセージを返すことにより、PKCEを使用しないネイティブアプリからの承認リクエストを拒否する必要があります（SHOULD）。
The OAuth 2.0 implicit grant authorization flow (defined in Section 4.2 of OAuth 2.0 [RFC6749]) generally works with the practice of performing the authorization request in the browser and receiving the authorization response via URI-based inter-app communication. However, as the implicit flow cannot be protected by PKCE [RFC7636] (which is required in Section 8.1), the use of the Implicit Flow with native apps is NOT RECOMMENDED.
OAuth 2.0の暗黙の許可承認フロー（OAuth 2.0 [RFC6749]のセクション4.2で定義）は、通常、ブラウザーで承認要求を実行し、URIベースのアプリ間通信を介して承認応答を受信する方法で機能します。ただし、暗黙的フローはPKCE [RFC7636]（セクション8.1で必要）で保護できないため、ネイティブアプリでの暗黙的フローの使用は推奨されません。
Access tokens granted via the implicit flow also cannot be refreshed without user interaction, making the authorization code grant flow -- which can issue refresh tokens -- the more practical option for native app authorizations that require refreshing of access tokens.
暗黙的なフローを介して付与されたアクセストークンも、ユーザーの操作なしでは更新できないため、承認コード付与フロー（更新トークンを発行できる）が、アクセストークンの更新を必要とするネイティブアプリの承認のより実用的なオプションになります。
Loopback interface redirect URIs use the "http" scheme (i.e., without Transport Layer Security (TLS)). This is acceptable for loopback interface redirect URIs as the HTTP request never leaves the device.
ループバックインターフェースリダイレクトURIは「http」スキームを使用します（トランスポート層セキュリティ（TLS）なし）。 HTTP要求がデバイスを出ることはないため、これはループバックインターフェイスリダイレクトURIで許容されます。
Clients should open the network port only when starting the authorization request and close it once the response is returned.
クライアントは、承認リクエストを開始するときにのみネットワークポートを開き、レスポンスが返されたらネットワークポートを閉じる必要があります。
Clients should listen on the loopback network interface only, in order to avoid interference by other network actors.
クライアントは、他のネットワークアクターによる干渉を回避するために、ループバックネットワークインターフェイスでのみリッスンする必要があります。
While redirect URIs using localhost (i.e., "http://localhost:{port}/{path}") function similarly to loopback IP redirects described in Section 7.3, the use of localhost is NOT RECOMMENDED. Specifying a redirect URI with the loopback IP literal rather than localhost avoids inadvertently listening on network interfaces other than the loopback interface. It is also less susceptible to client-side firewalls and misconfigured host name resolution on the user's device.
localhost（つまり、「http：// localhost：{port} / {path}」）を使用したリダイレクトURIは、7.3節で説明したループバックIPリダイレクトと同様に機能しますが、localhostの使用は推奨されません。 localhostではなくループバックIPリテラルを使用してリダイレクトURIを指定すると、ループバックインターフェース以外のネットワークインターフェースで誤ってリッスンすることを回避できます。また、クライアント側のファイアウォールや、ユーザーのデバイスでのホスト名解決の設定ミスの影響も受けにくくなっています。
Except when using a mechanism like Dynamic Client Registration [RFC7591] to provision per-instance secrets, native apps are classified as public clients, as defined by Section 2.1 of OAuth 2.0 [RFC6749]; they MUST be registered with the authorization server as such. Authorization servers MUST record the client type in the client registration details in order to identify and process requests accordingly.
動的クライアント登録[RFC7591]などのメカニズムを使用してインスタンスごとのシークレットをプロビジョニングする場合を除き、ネイティブアプリはOAuth 2.0 [RFC6749]のセクション2.1で定義されているように、パブリッククライアントとして分類されます。それらは、認証サーバーに登録する必要があります。承認サーバーは、要求を識別して処理するために、クライアント登録の詳細にクライアントタイプを記録する必要があります。
Authorization servers MUST require clients to register their complete redirect URI (including the path component) and reject authorization requests that specify a redirect URI that doesn't exactly match the one that was registered; the exception is loopback redirects, where an exact match is required except for the port URI component.
承認サーバーは、クライアントに完全なリダイレクトURI（パスコンポーネントを含む）を登録し、登録されたものと正確に一致しないリダイレクトURIを指定する承認リクエストを拒否する必要があります。例外はループバックリダイレクトで、ポートURIコンポーネントを除いて完全一致が必要です。
For private-use URI scheme-based redirects, authorization servers SHOULD enforce the requirement in Section 7.1 that clients use schemes that are reverse domain name based. At a minimum, any private-use URI scheme that doesn't contain a period character (".") SHOULD be rejected.
私用のURIスキームベースのリダイレクトの場合、承認サーバーは、クライアントが逆ドメイン名ベースのスキームを使用するというセクション7.1の要件を適用する必要があります（SHOULD）。少なくとも、ピリオド文字（ "。"）を含まない私用URIスキームは拒否する必要があります。
In addition to the collision-resistant properties, requiring a URI scheme based on a domain name that is under the control of the app can help to prove ownership in the event of a dispute where two apps claim the same private-use URI scheme (where one app is acting maliciously). For example, if two apps claimed "com.example.app", the owner of "example.com" could petition the app store operator to remove the counterfeit app. Such a petition is harder to prove if a generic URI scheme was used.
衝突耐性のあるプロパティに加えて、アプリの制御下にあるドメイン名に基づくURIスキームを要求すると、2つのアプリが同じ私用URIスキームを主張する紛争が発生した場合に所有権を証明するのに役立ちます（ここで1つのアプリが悪意を持って動作しています）。たとえば、2つのアプリが「com.example.app」を要求した場合、「example.com」の所有者は、App Storeオペレーターに偽造アプリの削除を申請することができます。このような請願は、一般的なURIスキームが使用されたかどうかを証明するのが困難です。
Authorization servers MAY request the inclusion of other platform-specific information, such as the app package or bundle name, or other information that may be useful for verifying the calling app's identity on operating systems that support such functions.
承認サーバーは、アプリパッケージやバンドル名など、他のプラットフォーム固有の情報や、そのような機能をサポートするオペレーティングシステムで呼び出し元アプリのIDを確認するのに役立つ可能性のあるその他の情報を含めるよう要求する場合があります。
Secrets that are statically included as part of an app distributed to multiple users should not be treated as confidential secrets, as one user may inspect their copy and learn the shared secret. For this reason, and those stated in Section 5.3.1 of [RFC6819], it is NOT RECOMMENDED for authorization servers to require client authentication of public native apps clients using a shared secret, as this serves little value beyond client identification which is already provided by the "client_id" request parameter.
複数のユーザーに配布されるアプリの一部として静的に含まれるシークレットは、1人のユーザーが自分のコピーを検査して共有シークレットを学習する可能性があるため、機密シークレットとして扱わないでください。この理由と、[RFC6819]のセクション5.3.1に記載されている理由により、承認サーバーが共有シークレットを使用してパブリックネイティブアプリクライアントのクライアント認証を要求することはお勧めしません。 「client_id」リクエストパラメータ。
Authorization servers that still require a statically included shared secret for native app clients MUST treat the client as a public client (as defined by Section 2.1 of OAuth 2.0 [RFC6749]), and not accept the secret as proof of the client's identity. Without additional measures, such clients are subject to client impersonation (see Section 8.6).
ネイティブアプリクライアントに静的に含まれる共有シークレットを必要とする承認サーバーは、クライアントをパブリッククライアント（OAuth 2.0 [RFC6749]のセクション2.1で定義）として扱い、クライアントのIDの証明としてシークレットを受け入れないようにする必要があります。追加の手段がない場合、そのようなクライアントはクライアントのなりすましの影響を受けます（セクション8.6を参照）。
As stated in Section 10.2 of OAuth 2.0 [RFC6749], the authorization server SHOULD NOT process authorization requests automatically without user consent or interaction, except when the identity of the client can be assured. This includes the case where the user has previously approved an authorization request for a given client id -- unless the identity of the client can be proven, the request SHOULD be processed as if no previous request had been approved.
OAuth 2.0 [RFC6749]のセクション10.2で述べられているように、認証サーバーは、クライアントのIDが保証できる場合を除いて、ユーザーの同意や相互作用なしに自動的に認証リクエストを処理するべきではありません。これには、ユーザーが特定のクライアントIDの承認リクエストを以前に承認した場合も含まれます。クライアントのIDを証明できない場合、リクエストは、以前のリクエストが承認されなかったかのように処理する必要があります。
Measures such as claimed "https" scheme redirects MAY be accepted by authorization servers as identity proof. Some operating systems may offer alternative platform-specific identity features that MAY be accepted, as appropriate.
要求された「https」スキームのリダイレクトなどの手段は、IDの証拠として承認サーバーによって受け入れられる場合があります。一部のオペレーティングシステムは、必要に応じて受け入れることができる代替のプラットフォーム固有のID機能を提供する場合があります。
The native app that is initiating the authorization request has a large degree of control over the user interface and can potentially present a fake external user-agent, that is, an embedded user-agent made to appear as an external user-agent.
承認リクエストを開始するネイティブアプリは、ユーザーインターフェースを大幅に制御しており、偽の外部ユーザーエージェント、つまり、外部ユーザーエージェントとして表示されるように作成された埋め込みユーザーエージェントを提示する可能性があります。
When all good actors are using external user-agents, the advantage is that it is possible for security experts to detect bad actors, as anyone faking an external user-agent is provably bad. On the other hand, if good and bad actors alike are using embedded user-agents, bad actors don't need to fake anything, making them harder to detect. Once a malicious app is detected, it may be possible to use this knowledge to blacklist the app's signature in malware scanning software, take removal action (in the case of apps distributed by app stores) and other steps to reduce the impact and spread of the malicious app.
すべての優れたアクターが外部ユーザーエージェントを使用している場合、利点は、外部ユーザーエージェントになりすました誰もが明らかに悪いため、セキュリティの専門家が悪いアクターを検出できることです。一方、善良なアクターが埋め込まれたユーザーエージェントを使用している場合、悪意のあるアクターは何も偽造する必要がないため、検出が困難になります。悪意のあるアプリが検出されると、この知識を利用して、マルウェアスキャンソフトウェアでアプリの署名をブラックリストに登録し、削除アクション（アプリストアによって配布されたアプリの場合）およびその他の手順を実行して、悪意のあるアプリ。
Authorization servers can also directly protect against fake external user-agents by requiring an authentication factor only available to true external user-agents.
承認サーバーは、真の外部ユーザーエージェントのみが利用できる認証要素を要求することにより、偽の外部ユーザーエージェントから直接保護することもできます。
Users who are particularly concerned about their security when using in-app browser tabs may also take the additional step of opening the request in the full browser from the in-app browser tab and complete the authorization there, as most implementations of the in-app browser tab pattern offer such functionality.
アプリ内ブラウザのタブを使用する際のセキュリティに特に関心があるユーザーは、アプリ内ブラウザのタブからフルブラウザでリクエストを開き、そこで承認を完了するという追加の手順を実行することもできます。ブラウザのタブパターンはそのような機能を提供します。
If a malicious app is able to configure itself as the default handler for "https" scheme URIs in the operating system, it will be able to intercept authorization requests that use the default browser and abuse this position of trust for malicious ends such as phishing the user.
悪意のあるアプリがオペレーティングシステムの「https」スキームURIのデフォルトハンドラーとしてそれ自体を設定できる場合、デフォルトのブラウザーを使用する認証リクエストを傍受し、フィッシングなどの悪意のある目的でこの信頼の位置を悪用することができます。ユーザー。
This attack is not confined to OAuth; a malicious app configured in this way would present a general and ongoing risk to the user beyond OAuth usage by native apps. Many operating systems mitigate this issue by requiring an explicit user action to change the default handler for "http" and "https" scheme URIs.
この攻撃はOAuthに限定されません。このように構成された悪意のあるアプリは、ネイティブアプリによるOAuthの使用を超えて、ユーザーに一般的かつ継続的なリスクをもたらします。多くのオペレーティングシステムは、「http」および「https」スキームURIのデフォルトハンドラーを変更する明示的なユーザーアクションを要求することにより、この問題を軽減します。
Section 5.3.5 of [RFC6819] recommends using the "state" parameter to link client requests and responses to prevent CSRF (Cross-Site Request Forgery) attacks.
[RFC6819]のセクション5.3.5では、「state」パラメータを使用してクライアントのリクエストとレスポンスをリンクし、CSRF（Cross-Site Request Forgery）攻撃を防止することを推奨しています。
To mitigate CSRF-style attacks over inter-app URI communication channels (so called "cross-app request forgery"), it is similarly RECOMMENDED that native apps include a high-entropy secure random number in the "state" parameter of the authorization request and reject any incoming authorization responses without a state value that matches a pending outgoing authorization request.
アプリ間URI通信チャネル（いわゆる「クロスアプリリクエストフォージェリ」）を介したCSRFスタイルの攻撃を緩和するには、同様に、ネイティブアプリの承認リクエストの「状態」パラメーターに高エントロピーの安全な乱数を含めることをお勧めします保留中の発信承認リクエストと一致する状態値のない着信承認応答を拒否します。
To protect against a compromised or malicious authorization server attacking another authorization server used by the same app, it is REQUIRED that a unique redirect URI is used for each authorization server used by the app (for example, by varying the path component), and that authorization responses are rejected if the redirect URI they were received on doesn't match the redirect URI in an outgoing authorization request.
侵害された、または悪意のある承認サーバーが同じアプリで使用される別の承認サーバーを攻撃するのを防ぐには、アプリで使用される各承認サーバーに一意のリダイレクトURIを使用する必要があります（たとえば、パスコンポーネントを変更する）。承認応答は、受信したリダイレクトURIが送信承認リクエストのリダイレクトURIと一致しない場合、拒否されます。
The native app MUST store the redirect URI used in the authorization request with the authorization session data (i.e., along with "state" and other related data) and MUST verify that the URI on which the authorization response was received exactly matches it.
ネイティブアプリは、承認リクエストで使用されるリダイレクトURIを承認セッションデータとともに（つまり、「状態」およびその他の関連データとともに）保存し、承認応答を受信したURIがそれと正確に一致することを確認する必要があります。
The requirement of Section 8.4, specifically that authorization servers reject requests with URIs that don't match what was registered, is also required to prevent such attacks.
セクション8.4の要件、特に、承認サーバーが、登録されたものと一致しないURIを持つ要求を拒否することも、このような攻撃を防ぐために必要です。
This best practice recommends a particular type of external user-agent: the user's browser. Other external user-agent patterns may also be viable for secure and usable OAuth. This document makes no comment on those patterns.
このベストプラクティスでは、特定のタイプの外部ユーザーエージェントであるユーザーのブラウザを推奨しています。安全で使いやすいOAuthには、他の外部ユーザーエージェントパターンも使用できる場合があります。このドキュメントでは、これらのパターンについてはコメントしていません。
Section 9 of OAuth 2.0 [RFC6749] documents two approaches for native apps to interact with the authorization endpoint. This best current practice requires that native apps MUST NOT use embedded user-agents to perform authorization requests and allows that authorization endpoints MAY take steps to detect and block authorization requests in embedded user-agents. The security considerations for these requirements are detailed herein.
OAuth 2.0 [RFC6749]のセクション9には、ネイティブアプリが認証エンドポイントとやり取りするための2つのアプローチが記載されています。現在のベストプラクティスでは、ネイティブアプリが埋め込みユーザーエージェントを使用して承認リクエストを実行してはならず、承認エンドポイントが埋め込みユーザーエージェントの承認リクエストを検出してブロックできるようにする必要があります。ここでは、これらの要件のセキュリティに関する考慮事項について詳しく説明します。
Embedded user-agents are an alternative method for authorizing native apps. These embedded user-agents are unsafe for use by third parties to the authorization server by definition, as the app that hosts the embedded user-agent can access the user's full authentication credential, not just the OAuth authorization grant that was intended for the app.
組み込みのユーザーエージェントは、ネイティブアプリを承認するための代替方法です。埋め込みユーザーエージェントをホストするアプリは、アプリ向けのOAuth承認付与だけでなく、ユーザーの完全な認証資格情報にアクセスできるため、これらの埋め込みユーザーエージェントは、定義上、承認サーバーのサードパーティによる使用には安全ではありません。
In typical web-view-based implementations of embedded user-agents, the host application can record every keystroke entered in the login form to capture usernames and passwords, automatically submit forms to bypass user consent, and copy session cookies and use them to perform authenticated actions as the user.
組み込みのユーザーエージェントの一般的なWebビューベースの実装では、ホストアプリケーションはログインフォームに入力されたすべてのキーストロークを記録してユーザー名とパスワードを取得し、フォームを自動的に送信してユーザーの同意をバイパスし、セッションCookieをコピーしてそれらを使用して認証を実行できますユーザーとしてのアクション。
Even when used by trusted apps belonging to the same party as the authorization server, embedded user-agents violate the principle of least privilege by having access to more powerful credentials than they need, potentially increasing the attack surface.
許可サーバーと同じ当事者に属する信頼できるアプリで使用された場合でも、埋め込まれたユーザーエージェントは、必要以上に強力な資格情報にアクセスすることにより、最小限の特権の原則に違反し、攻撃対象を増やす可能性があります。
Encouraging users to enter credentials in an embedded user-agent without the usual address bar and visible certificate validation features that browsers have makes it impossible for the user to know if they are signing in to the legitimate site; even when they are, it trains them that it's OK to enter credentials without validating the site first.
通常のアドレスバーとブラウザに表示される証明書の検証機能を使用せずに、組み込みのユーザーエージェントに資格情報を入力するようユーザーに勧めると、ユーザーは正当なサイトにサインインしているかどうかをユーザーが知ることができなくなります。彼らがそうである場合でも、最初にサイトを検証せずに資格情報を入力してもよいことを彼らに訓練します。
Aside from the security concerns, embedded user-agents do not share the authentication state with other apps or the browser, requiring the user to log in for every authorization request, which is often considered an inferior user experience.
セキュリティの問題は別として、埋め込まれたユーザーエージェントは他のアプリやブラウザと認証状態を共有しないため、承認リクエストごとにユーザーにログインを要求します。これは、ユーザーエクスペリエンスの低下と見なされることがよくあります。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
Section 7.1 specifies how private-use URI schemes are used for inter-app communication in OAuth protocol flows. This document requires in Section 7.1 that such schemes are based on domain names owned or assigned to the app, as recommended in Section 3.8 of [RFC7595]. Per Section 6 of [RFC7595], registration of domain-based URI schemes with IANA is not required.
セクション7.1では、OAuthプロトコルフローでアプリ間通信に私用URIスキームを使用する方法を指定しています。 [RFC7595]のセクション3.8で推奨されているように、このドキュメントではセクション7.1で、このようなスキームがアプリに所有または割り当てられているドメイン名に基づいていることを要求しています。 [RFC7595]のセクション6に従い、ドメインベースのURIスキームをIANAに登録する必要はありません。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[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>.
[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<https://www.rfc-editor.org/info/rfc6749>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/info/rfc7595>.
[RFC7595] Thaler、D.、Ed。、Hansen、T。、およびT. Hardie、「URIスキームのガイドラインと登録手順」、BCP 35、RFC 7595、DOI 10.17487 / RFC7595、2015年6月、<https：// www.rfc-editor.org/info/rfc7595>。
[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>.
[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>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, <https://www.rfc-editor.org/info/rfc6819>.
[RFC6819] Lodderstedt、T.、Ed。、McGloin、M。、およびP. Hunt、「OAuth 2.0脅威モデルとセキュリティの考慮事項」、RFC 6819、DOI 10.17487 / RFC6819、2013年1月、<https：//www.rfc -editor.org/info/rfc6819>。
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/info/rfc7591>.
[RFC7591] Richer、J.、Ed。、Jones、M.、Bradley、J.、Machulak、M。、およびP. Hunt、「OAuth 2.0 Dynamic Client Registration Protocol」、RFC 7591、DOI 10.17487 / RFC7591、2015年7月、<https://www.rfc-editor.org/info/rfc7591>。
[AppAuth] OpenID Connect Working Group, "AppAuth", September 2017, <https://openid.net/code/AppAuth>.
[AppAuth] OpenID Connectワーキンググループ、「AppAuth」、2017年9月、<https://openid.net/code/AppAuth>。
[AppAuth.iOSmacOS] Wright, S., Denniss, W., et al., "AppAuth for iOS and macOS", February 2016, <https://openid.net/code/AppAuth-iOS>.
[AppAuth.iOSmacOS] Wright、S.、Denniss、W。他、「AppAuth for iOS and macOS」、2016年2月、<https://openid.net/code/AppAuth-iOS>。
[AppAuth.Android] McGinniss, I., Denniss, W., et al., "AppAuth for Android", February 2016, <https://openid.net/code/AppAuth-Android>.
[AppAuth.Android] McGinniss、I.、Denniss、W.、et al。、 "AppAuth for Android"、February 2016、<https://openid.net/code/AppAuth-Android>。
[SamplesForWindows] Denniss, W., "OAuth for Apps: Samples for Windows", July 2016, <https://openid.net/code/sample-oauth-apps-for-windows>.
[SamplesForWindows] Denniss、W。、「OAuth for Apps：Samples for Windows」、2016年7月、<https://openid.net/code/sample-oauth-apps-for-windows>。
OAuth servers that support native apps must:
ネイティブアプリをサポートするOAuthサーバーは次の条件を満たす必要があります。
1. Support private-use URI scheme redirect URIs. This is required to support mobile operating systems. See Section 7.1.
1. 専用URIスキームのリダイレクトURIをサポートします。これは、モバイルオペレーティングシステムをサポートするために必要です。セクション7.1を参照してください。
2. Support "https" scheme redirect URIs for use with public native app clients. This is used by apps on advanced mobile operating systems that allow app-claimed "https" scheme URIs. See Section 7.2.
2. パブリックネイティブアプリクライアントで使用する「https」スキームのリダイレクトURIをサポートします。これは、アプリが要求する「https」スキームのURIを許可する高度なモバイルオペレーティングシステム上のアプリで使用されます。セクション7.2を参照してください。
3. Support loopback IP redirect URIs. This is required to support desktop operating systems. See Section 7.3.
3. ループバックIPリダイレクトURIをサポートします。これは、デスクトップオペレーティングシステムをサポートするために必要です。セクション7.3を参照してください。
4. Not assume that native app clients can keep a secret. If secrets are distributed to multiple installs of the same native app, they should not be treated as confidential. See Section 8.5.
4. ネイティブアプリクライアントが秘密を守ることができるとは限りません。シークレットが同じネイティブアプリの複数のインストールに配布されている場合、それらは機密情報として扱われるべきではありません。セクション8.5を参照してください。
5. Support PKCE [RFC7636]. Required to protect authorization code grants sent to public clients over inter-app communication channels. See Section 8.1
5. PKCE [RFC7636]をサポートします。アプリ間通信チャネルを介してパブリッククライアントに送信される認証コード付与を保護するために必要です。セクション8.1を参照
This document primarily defines best practices in a generic manner, referencing techniques commonly available in a variety of environments. This non-normative section documents implementation details of the best practice for various operating systems.
このドキュメントでは、主に一般的な方法でベストプラクティスを定義し、さまざまな環境で一般的に利用できる手法を参照しています。この非規範的なセクションでは、さまざまなオペレーティングシステムのベストプラクティスの実装の詳細について説明します。
The implementation details herein are considered accurate at the time of publishing but will likely change over time. It is hoped that such a change won't invalidate the generic principles in the rest of the document and that those principles should take precedence in the event of a conflict.
ここでの実装の詳細は、公開時には正確と見なされますが、時間の経過とともに変更される可能性があります。このような変更によって、残りのドキュメントの一般的な原則が無効になることはなく、競合が発生した場合はこれらの原則が優先されることが望まれます。
Apps can initiate an authorization request in the browser, without the user leaving the app, through the "SFSafariViewController" class or its successor "SFAuthenticationSession", which implement the in-app browser tab pattern. Safari can be used to handle requests on old versions of iOS without in-app browser tab functionality.
アプリは、ユーザーがアプリを離れることなく、アプリ内ブラウザーのタブパターンを実装する「SFSafariViewController」クラスまたはその後続の「SFAuthenticationSession」を介して、ブラウザーで承認リクエストを開始できます。 Safariを使用すると、アプリ内ブラウザのタブ機能がなくても、iOSの古いバージョンのリクエストを処理できます。
To receive the authorization response, both private-use URI scheme (referred to as "custom URL scheme") redirects and claimed "https" scheme URIs (known as "Universal Links") are viable choices. Apps can claim private-use URI schemes with the "CFBundleURLTypes" key in the application's property list file, "Info.plist", and "https" scheme URIs using the Universal Links feature with an entitlement file in the app and an association file hosted on the domain.
承認応答を受信するには、プライベート使用のURIスキーム（「カスタムURLスキーム」と呼ばれる）リダイレクトと要求された「https」スキームURI（「ユニバーサルリンク」と呼ばれる）の両方が実行可能な選択肢です。アプリは、アプリケーションのプロパティファイルとホストされている関連付けファイルのユニバーサルリンク機能を使用して、アプリケーションのプロパティリストファイルの「CFBundleURLTypes」キー、「Info.plist」、および「https」スキームURIで私用URIスキームを要求できます。ドメイン上。
Claimed "https" scheme URIs are the preferred redirect choice on iOS 9 and above due to the ownership proof that is provided by the operating system.
オペレーティングシステムによって提供される所有権の証明により、iOS 9以降では、「https」スキームのURIが推奨されます。
A complete open-source sample is included in the AppAuth for iOS and macOS [AppAuth.iOSmacOS] library.
完全なオープンソースのサンプルは、iOSおよびmacOS用のAppAuth [AppAuth.iOSmacOS]ライブラリに含まれています。
Apps can initiate an authorization request in the browser, without the user leaving the app, through the Android Custom Tab feature, which implements the in-app browser tab pattern. The user's default browser can be used to handle requests when no browser supports Custom Tabs.
アプリは、アプリ内ブラウザーのタブパターンを実装するAndroidカスタムタブ機能を使用して、ユーザーがアプリを離れることなく、ブラウザーで承認リクエストを開始できます。ユーザーのデフォルトのブラウザを使用して、カスタムタブをサポートするブラウザがない場合にリクエストを処理できます。
Android browser vendors should support the Custom Tabs protocol (by providing an implementation of the "CustomTabsService" class), to provide the in-app browser tab user-experience optimization to their users. Chrome is one such browser that implements Custom Tabs.
Androidブラウザーベンダーは、（「CustomTabsService」クラスの実装を提供することにより）カスタムタブプロトコルをサポートし、ユーザーにアプリ内ブラウザータブのユーザーエクスペリエンスの最適化を提供する必要があります。 Chromeは、カスタムタブを実装するブラウザの1つです。
To receive the authorization response, private-use URI schemes are broadly supported through Android Implicit Intents. Claimed "https" scheme redirect URIs through Android App Links are available on Android 6.0 and above. Both types of redirect URIs are registered in the application's manifest.
承認応答を受信するために、プライベート使用のURIスキームがAndroid Implicit Intentsを通じて広くサポートされています。 Androidアプリリンクを介した「https」スキームのリダイレクトURIは、Android 6.0以降で使用できます。どちらのタイプのリダイレクトURIもアプリケーションのマニフェストに登録されています。
A complete open-source sample is included in the AppAuth for Android [AppAuth.Android] library.
完全なオープンソースのサンプルは、AppAuth for Android [AppAuth.Android]ライブラリに含まれています。
Both traditional and Universal Windows Platform (UWP) apps can perform authorization requests in the user's browser. Traditional apps typically use a loopback redirect to receive the authorization response, and listening on the loopback interface is allowed by default firewall rules. When creating the loopback network socket, apps SHOULD set the "SO_EXCLUSIVEADDRUSE" socket option to prevent other apps binding to the same socket.
従来のアプリとユニバーサルWindowsプラットフォーム（UWP）アプリはどちらも、ユーザーのブラウザーで承認要求を実行できます。従来のアプリは通常、ループバックリダイレクトを使用して承認応答を受信し、デフォルトのファイアウォールルールではループバックインターフェースでのリッスンが許可されています。ループバックネットワークソケットを作成するとき、アプリは「SO_EXCLUSIVEADDRUSE」ソケットオプションを設定して、他のアプリが同じソケットにバインドしないようにする必要があります。
UWP apps can use private-use URI scheme redirects to receive the authorization response from the browser, which will bring the app to the foreground. Known on the platform as "URI Activation", the URI scheme is limited to 39 characters in length, and it may include the "." character, making short reverse domain name based schemes (as required in Section 7.1) possible.
UWPアプリは、プライベート使用のURIスキームリダイレクトを使用して、ブラウザーから承認応答を受信できます。これにより、アプリが前面に表示されます。プラットフォームで「URIアクティベーション」として知られているURIスキームは、長さが39文字に制限されており、「。」が含まれる場合があります。文字、短い逆ドメイン名ベースのスキーム（セクション7.1で必要）を可能にします。
UWP apps can alternatively use the Web Authentication Broker API in Single Sign-on (SSO) mode, which is an external user-agent designed for authorization flows. Cookies are shared between invocations of the broker but not the user's preferred browser, meaning the user will need to log in again, even if they have an active session in their browser; but the session created in the broker will be available to subsequent apps that use the broker. Personalizations the user has made to their browser, such as configuring a password manager, may not be available in the broker. To qualify as an external user-agent, the broker MUST be used in SSO mode.
UWPアプリは、シングルサインオン（SSO）モードでWeb認証ブローカーAPIを使用することもできます。SSOモードは、承認フロー用に設計された外部ユーザーエージェントです。 Cookieはブローカーの呼び出し間で共有されますが、ユーザーの優先ブラウザーでは共有されません。つまり、ブラウザーにアクティブなセッションがある場合でも、ユーザーは再度ログインする必要があります。ただし、ブローカーで作成されたセッションは、ブローカーを使用する後続のアプリで使用できます。パスワードマネージャーの構成など、ユーザーがブラウザーに対して行った個人用設定は、ブローカーでは使用できない場合があります。外部ユーザーエージェントとしての資格を得るには、ブローカーをSSOモードで使用する必要があります。
To use the Web Authentication Broker in SSO mode, the redirect URI must be of the form "msapp://{appSID}" where "{appSID}" is the app's security identifier (SID), which can be found in the app's registration information or by calling the "GetCurrentApplicationCallbackUri" method. While Windows enforces the URI authority on such redirects, ensuring that only the app with the matching SID can receive the response on Windows, the URI scheme could be claimed by apps on other platforms without the same authority present; thus, this redirect type should be treated similarly to private-use URI scheme redirects for security purposes.
Web認証ブローカーをSSOモードで使用するには、リダイレクトURIの形式は "msapp：// {appSID}"である必要があります。ここで、 "{appSID}"はアプリのセキュリティ識別子（SID）であり、アプリの登録にあります。情報または「GetCurrentApplicationCallbackUri」メソッドを呼び出します。 WindowsはこのようなリダイレクトにURI権限を適用し、SIDが一致するアプリのみがWindowsで応答を受信できるようにしますが、URIスキームは、同じ権限が存在しない他のプラットフォーム上のアプリによって要求される可能性があります。したがって、このリダイレクトタイプは、セキュリティ上の理由から、プライベート使用のURIスキームリダイレクトと同様に扱う必要があります。
An open-source sample demonstrating these patterns is available [SamplesForWindows].
これらのパターンを示すオープンソースのサンプルが利用可能です[SamplesForWindows]。
Apps can initiate an authorization request in the user's default browser using platform APIs for opening URIs in the browser.
アプリは、ブラウザーでURIを開くためのプラットフォームAPIを使用して、ユーザーのデフォルトブラウザーで承認リクエストを開始できます。
To receive the authorization response, private-use URI schemes are a good redirect URI choice on macOS, as the user is returned right back to the app they launched the request from. These are registered in the application's bundle information property list using the "CFBundleURLSchemes" key. Loopback IP redirects are another viable option, and listening on the loopback interface is allowed by default firewall rules.
承認応答を受信するには、ユーザーがリクエストを起動したアプリに直接戻るため、macOSでのプライベートURIスキームはリダイレクトURIとして適切な選択肢です。これらは、「CFBundleURLSchemes」キーを使用してアプリケーションのバンドル情報プロパティリストに登録されます。ループバックIPリダイレクトは別の実行可能なオプションであり、ループバックインターフェイスでのリッスンはデフォルトのファイアウォールルールで許可されています。
A complete open-source sample is included in the AppAuth for iOS and macOS [AppAuth.iOSmacOS] library.
完全なオープンソースのサンプルは、iOSおよびmacOS用のAppAuth [AppAuth.iOSmacOS]ライブラリに含まれています。
Opening the authorization request in the user's default browser requires a distro-specific command: "xdg-open" is one such tool.
ユーザーのデフォルトのブラウザで認証リクエストを開くには、ディストリビューション固有のコマンドが必要です。「xdg-open」はそのようなツールの1つです。
The loopback redirect is the recommended redirect choice for desktop apps on Linux to receive the authorization response. Apps SHOULD NOT set the "SO_REUSEPORT" or "SO_REUSEADDR" socket options in order to prevent other apps binding to the same socket.
ループバックリダイレクトは、Linux上のデスクトップアプリが承認応答を受信するために推奨されるリダイレクト選択です。アプリは、他のアプリが同じソケットにバインドするのを防ぐために、「SO_REUSEPORT」または「SO_REUSEADDR」ソケットオプションを設定しないでください。
Acknowledgements
謝辞
The authors would like to acknowledge the work of Marius Scurtescu and Ben Wiley Sittler, whose design for using private-use URI schemes in native app OAuth 2.0 clients at Google formed the basis of Section 7.1.
著者は、GoogleのネイティブアプリOAuth 2.0クライアントで私用URIスキームを使用するための設計がセクション7.1の基礎を形成したMarius ScurtescuとBen Wiley Sittlerの業績を認めたいと思います。
The following individuals contributed ideas, feedback, and wording that shaped and formed the final specification:
以下の個人が、最終的な仕様を形成および形成するアイデア、フィードバック、および表現を提供しました。
Andy Zmolek, Steven E. Wright, Brian Campbell, Nat Sakimura, Eric Sachs, Paul Madsen, Iain McGinniss, Rahul Ravikumar, Breno de Medeiros, Hannes Tschofenig, Ashish Jain, Erik Wahlstrom, Bill Fisher, Sudhi Umarji, Michael B. Jones, Vittorio Bertocci, Dick Hardt, David Waite, Ignacio Fiorentino, Kathleen Moriarty, and Elwyn Davies.
アンディズモレク、スティーブンE.ライト、ブライアンキャンベル、ナットサキムラ、エリックサックス、ポールマドセン、イアンマクギニス、ラフルラビクマール、ブレノデメデイロス、ハンネススコフェニグ、アシッシュジェイン、エリックウォールストロム、ビルフィッシャー、スディウマルジ、マイケルB.ジョーンズ、ヴィットリオベルトッチ、ディックハード、デビッドウェイト、イグナシオフィオレンティーノ、キャスリーンモリアーティ、エルウィンデイヴィス。
Authors' Addresses
著者のアドレス
William Denniss Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 United States of America
William Denniss Google 1600 Amphitheatre Pkwy Mountain View、CA 94043アメリカ合衆国
Email: rfc8252@wdenniss.com
URI: http://wdenniss.com/appauth
John Bradley Ping Identity
ジョンブラッドリーピンアイデンティティ
Phone: +1 202-630-5272
Email: rfc8252@ve7jtb.com
URI: http://www.thread-safe.com/p/appauth.html