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

4. Overview (概要)

ネイティブアプリでユーザーを認可する場合、最良現行慣行 (Best Current Practice) は、埋め込みユーザーエージェント (Embedded User-Agent)（ウェブビューで実装されるようなもの）ではなく、外部ユーザーエージェント (External User-Agent)（通常はブラウザ）で OAuth 認可リクエストを実行することです。

以前は、ネイティブアプリが OAuth 認可リクエストに埋め込みユーザーエージェント（通常はウェブビューで実装）を使用することが一般的でした。そのアプローチには、ホストアプリがユーザー認証情報とクッキーをコピーできることや、ユーザーが各アプリで最初から認証する必要があることなど、多くの欠点があります。OAuth に埋め込みユーザーエージェントを使用することの欠点についての詳細な分析は、第8.12節を参照してください。

ブラウザを使用するネイティブアプリの認可リクエストは、より安全であり、ユーザーの認証状態を活用できます。ブラウザ内の既存の認証セッションを使用できることで、シングルサインオン (Single Sign-On) が可能になり、ユーザーは新しいアプリを使用するたびに認可サーバーに認証する必要がなくなります（認可サーバーのポリシーで要求されない限り）。

ネイティブアプリとブラウザ間の認可フローのサポートは、OAuth プロトコル自体を変更することなく可能です。OAuth 認可リクエストとレスポンスはすでに URI の観点から定義されているためです。これには、アプリ間通信 (Inter-App Communication) に使用できる URI が含まれます。すべてのクライアントが機密ウェブクライアントであると仮定する一部の OAuth サーバー実装では、この最良現行慣行をサポートするために、パブリックネイティブアプリクライアントと、それらが使用するリダイレクト URI のタイプについての理解を追加する必要があります。

4.1. Authorization Flow for Native Apps Using the Browser (ブラウザを使用したネイティブアプリの認可フロー)​

 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
 |          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           +---------------+
 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+

図1: 外部ユーザーエージェントを介したネイティブアプリの認可

図1は、ユーザーを認可するためのネイティブアプリとブラウザ間の相互作用を示しています。

(1) クライアントアプリが認可リクエストを含むブラウザタブを開きます。

(2) 認可エンドポイント (Authorization Endpoint) が認可リクエストを受信し、ユーザーを認証し、認可を取得します。ユーザーの認証には、他の認証システムへの連鎖が含まれる場合があります。

(3) 認可サーバー (Authorization Server) がリダイレクト URI (Redirect URI) に認可コード (Authorization Code) を発行します。

(4) クライアントがリダイレクト URI から認可コードを受信します。

(5) クライアントアプリがトークンエンドポイント (Token Endpoint) に認可コードを提示します。

(6) トークンエンドポイントが認可コードを検証し、要求されたトークンを発行します。

に最終更新