メインコンテンツまでスキップ

7. Receiving the Authorization Response in a Native App (ネイティブアプリでの認可レスポンスの受信)

ネイティブアプリがブラウザから認可レスポンスを受信するために利用できるリダイレクト URI (Redirect URI) オプションがいくつかあり、その可用性とユーザーエクスペリエンスはプラットフォームによって異なります。

この最良現行慣行を完全にサポートするために、認可サーバー (Authorization Server) は、以下のサブセクションで説明される少なくとも3つのリダイレクト URI オプションをネイティブアプリに提供しなければなりません (MUST)。ネイティブアプリは、プラットフォーム固有の実装詳細を考慮して、ニーズに最も適したリダイレクトオプションを使用してもかまいません (MAY)。

7.1. Private-Use URI Scheme Redirection (プライベート使用 URI スキームリダイレクション)​

多くのモバイルおよびデスクトップコンピューティングプラットフォームは、アプリがプライベート使用 URI スキーム (Private-Use URI Schemes)（俗に「カスタム URL スキーム」と呼ばれることもあります）を登録できるようにすることで、URI を介したアプリ間通信をサポートしています。例えば「com.example.app」のようなものです。ブラウザまたは別のアプリがプライベート使用 URI スキームを持つ URI をロードしようとすると、それを登録したアプリが起動され、リクエストを処理します。

プライベート使用 URI スキームリダイレクトで OAuth 2.0 認可リクエストを実行するには、ネイティブアプリが標準の認可リクエストでブラウザを起動しますが、リダイレクト URI はオペレーティングシステムに登録したプライベート使用 URI スキームを利用します。

アプリに関連付ける URI スキームを選択する場合、アプリは、[RFC7595] の第3.8節でプライベート使用 URI スキームに推奨されているように、自分の管理下にあるドメイン名に基づく URI スキームを逆順で表現したものを使用しなければなりません (MUST)。

例えば、ドメイン名「app.example.com」を管理するアプリは、「com.example.app」をスキームとして使用できます。一部の認可サーバーは、ドメイン名に基づいてクライアント識別子を割り当てます。例えば「client1234.usercontent.example.net」は、同様に逆順にした場合にスキームのドメイン名として使用できます。ただし、「myapp」のようなスキームは、ドメイン名に基づいていないため、この要件を満たしません。

同じ発行者による複数のアプリがある場合、各スキームがそのグループ内で一意であるように注意する必要があります。逆順ドメイン名に基づくアプリ識別子を使用するプラットフォームでは、これらの識別子を OAuth リダイレクトのプライベート使用 URI スキームとして再利用して、この問題を回避できます。

[RFC3986] の第3.2節の要件に従って、プライベート使用 URI スキームリダイレクトには命名権限がないため、スキームコンポーネントの後には単一のスラッシュ（"/"）のみが表示されます。プライベート使用 URI スキームを利用したリダイレクト URI の完全な例は次のとおりです:

com.example.app:/oauth2redirect/example-provider

認可サーバーがリクエストを完了すると、通常どおりクライアントのリダイレクト URI にリダイレクトします。リダイレクト URI はプライベート使用 URI スキームを使用するため、オペレーティングシステムがネイティブアプリを起動し、URI を起動パラメータとして渡します。その後、ネイティブアプリは認可レスポンスに対して通常の処理を使用します。

7.2. Claimed "https" Scheme URI Redirection (主張された "https" スキーム URI リダイレクション)​

一部のオペレーティングシステムでは、アプリが自分の管理下にあるドメインの "https" スキーム [RFC7230] URI を主張できます。ブラウザが主張された URI に遭遇すると、ページがブラウザにロードされる代わりに、ネイティブアプリが URI を起動パラメータとして供給されて起動されます。

このような URI は、ネイティブアプリによるリダイレクト URI として使用できます。これらは、認可サーバーにとって通常のウェブベースのクライアントリダイレクト URI と区別がつきません。例は次のとおりです:

https://app.example.com/oauth2redirect/example-provider

リダイレクト URI だけでは、パブリックネイティブアプリクライアント (Public Native App Client) と機密ウェブクライアント (Confidential Web Client) を区別するのに十分ではないため、第8.4節では、サーバーがクライアントタイプを決定して適切に動作できるようにするために、クライアント登録時にクライアントタイプを記録することが要求されています (REQUIRED)。

アプリが主張する "https" スキームリダイレクト URI は、他のネイティブアプリリダイレクトオプションと比較して、宛先アプリの ID がオペレーティングシステムによって認可サーバーに保証されるという点でいくつかの利点があります。このため、ネイティブアプリは、可能な場合は他のオプションよりもこれらを使用すべきです (SHOULD)。

7.3. Loopback Interface Redirection (ループバックインターフェースリダイレクション)​

特別な権限を必要とせずにループバックネットワークインターフェース上でポートを開くことができるネイティブアプリ（通常、デスクトップオペレーティングシステム上のもの）は、ループバックインターフェースを使用して OAuth リダイレクトを受信できます。

ループバックリダイレクト URI は "http" スキームを使用し、ループバック IP リテラルとクライアントがリッスンしているポートで構築されます。

つまり、IPv4 の場合は http://127.0.0.1:{port}/{path}、IPv6 の場合は http://[::1]:{port}/{path} です。ランダムに割り当てられたポートで IPv4 ループバックインターフェースを使用するリダイレクトの例:

http://127.0.0.1:51004/oauth2redirect/example-provider

ランダムに割り当てられたポートで IPv6 ループバックインターフェースを使用するリダイレクトの例:

http://[::1]:61023/oauth2redirect/example-provider

認可サーバーは、リクエスト時にオペレーティングシステムから利用可能なエフェメラルポートを取得するクライアントに対応するために、ループバック IP リダイレクト URI のリクエスト時に任意のポートを指定できるようにしなければなりません (MUST)。

クライアントは、デバイスが特定のバージョンのインターネットプロトコルをサポートしていると仮定すべきではありません (SHOULD NOT)。クライアントは、IPv4 と IPv6 の両方を使用してループバックインターフェースにバインドを試み、利用可能な方を使用することが推奨されます (RECOMMENDED)。

に最終更新