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

1. はじめに

OAuth 2.0 [RFC6749] クライアントが OAuth 2.0 認可サーバーを利用するには、クライアントはそのサーバーで使用する OAuth 2.0 クライアント識別子など、サーバーと対話するための特定の情報を必要とします。この仕様は、OAuth 2.0 クライアントがこの情報を取得するために認可サーバーに動的に登録する方法を説明しています。

登録プロセスの一環として、この仕様は、一連の有効なリダイレクト URI などのメタデータのセットをクライアントが認可サーバーに提示するためのメカニズムも定義します。このメタデータは、自己主張された方法で通信することも、デジタル署名またはメッセージ認証コード (MAC) で保護されたソフトウェアステートメントと呼ばれるメタデータのセットとして通信することもできます。ソフトウェアステートメントの場合、発行者はクライアントに関するデータの有効性を保証します。

従来、認可サーバーへのクライアントの登録は手動で行われていました。この仕様で定義されているメカニズムは、クライアントが認可サーバーに動的に登録するため、またはクライアント開発者がプログラムで認可サーバーにクライアントを登録するために使用できます。OAuth 2.0 を使用する複数のアプリケーションは、これまで、このような登録を行うためのメカニズムを開発してきました。この仕様は、「OpenID Connect Dynamic Client Registration 1.0」 [OpenID.Registration] で定義され、「User Managed Access (UMA) Profile of OAuth 2.0」 [UMA-Core] で使用されている登録メカニズムを、両方と互換性がありながら、より広範な OAuth 2.0 のユースケースに適用できる方法で一般化しています。

1.1. 表記規則​

この文書のキーワード 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', および 'OPTIONAL' は、[RFC2119] で説明されているように解釈されるべきです。

特に明記しない限り、すべてのプロトコルパラメータ名と値は大文字と小文字が区別されます。

1.2. 用語​

この仕様では、OAuth 2.0 [RFC6749] で定義されている用語「アクセストークン」、「認可コード」、「認可エンドポイント」、「認可グラント」、「認可サーバー」、「クライアント」、「クライアント識別子」、「クライアントシークレット」、「グラントタイプ」、「保護されたリソース」、「リダイレクト URI」、「リフレッシュトークン」、「リソース所有者」、「リソースサーバー」、「レスポンスタイプ」、「トークンエンドポイント」を使用し、JSON Web Token (JWT) [RFC7519] で定義されている用語「クレーム (Claim)」を使用します。

この仕様では、以下の用語を定義します。

Client Software (クライアントソフトウェア) OAuth 2.0 クライアントを実装するソフトウェア。

Client Instance (クライアントインスタンス) クライアントソフトウェアのデプロイされたインスタンス。

Client Developer (クライアント開発者) クライアントソフトウェアパッケージを構築し、配布の準備をする人または組織。クライアントが構築される時点では、開発者は通常、デプロイするサービスプロバイダー組織が誰になるかを認識していません。クライアント開発者は、デプロイ URL などのソフトウェアの側面をコンパイル時に予測できない場合、動的登録を使用する必要があります。たとえば、これはソフトウェア API パブリッシャーとデプロイ組織が同一でない場合に発生する可能性があります。

Client Registration Endpoint (クライアント登録エンドポイント) クライアントが認可サーバーに登録できる OAuth 2.0 エンドポイント。このエンドポイントの URL を取得する手段は、この仕様の範囲外です。

Initial Access Token (初期アクセストークン) 認可サーバーによって開発者またはクライアントにオプションで発行され、クライアント登録エンドポイントへの呼び出しを認可するために使用される OAuth 2.0 アクセストークン。このトークンのタイプと形式はサービス固有である可能性が高く、この仕様の範囲外です。認可サーバーがこのトークンを発行する手段、および登録エンドポイントがこのトークンを検証する手段は、この仕様の範囲外です。認可サーバーがクライアントを登録できる当事者を制限する場合、初期アクセストークンの使用が必要です。

Deployment Organization (デプロイ組織) ソフトウェア API（サービス）がデプロイされ、OAuth 2.0 フレームワークによって保護されている管理セキュリティドメイン。一部の OAuth シナリオでは、デプロイ組織とソフトウェア API パブリッシャーは同じです。これらのケースでは、デプロイ組織は多くの場合、クライアントソフトウェア開発者と密接な関係を持ちます。他の多くのケースでは、サービスの定義者は独立したサードパーティのパブリッシャーまたは標準化団体である場合があります。API の公開仕様に基づいて作業する場合、クライアントソフトウェア開発者は、ソフトウェア API（サービス）をデプロイする可能性のある多くのデプロイ組織と事前に関係を持つことができません。

Software API Deployment (ソフトウェア API デプロイメント) 特定のデプロイ組織ドメイン内の OAuth 2.0（保護されたリソース）によって保護されているソフトウェア API のデプロイされたインスタンス。特定のソフトウェア API については、1 つ以上のデプロイメントが存在する場合があります。ソフトウェア API デプロイメントには、通常、関連付けられた OAuth 2.0 認可サーバーとクライアント登録エンドポイントがあります。エンドポイントを取得する手段は、この仕様の範囲外です。

Software API Publisher (ソフトウェア API パブリッシャー) 1 つ以上のデプロイ環境にデプロイできる特定の Web アクセス可能な API を定義する組織。パブリッシャーは、OAuth 2.0 を介して保護される可能性のあるソフトウェアおよび API 仕様の発行および配布を担当する、標準化団体、営利、公共、民間、またはオープンソースの組織である場合があります。場合によっては、ソフトウェア API パブリッシャーとクライアント開発者が同じ組織であることがあります。Web アクセス可能な API の公開時点では、ソフトウェアパブリッシャーは多くの場合、デプロイ組織と事前に関係を持っていません。

Software Statement (ソフトウェアステートメント) クライアントソフトウェアに関するメタデータ値をアサートする、デジタル署名または MAC された JSON Web Token (JWT) [RFC7519]。場合によっては、ソフトウェアステートメントはクライアント開発者によって直接発行されます。他のケースでは、ソフトウェアステートメントは、クライアント開発者が使用するためにサードパーティ組織によって発行されます。どちらの場合も、認可サーバーがソフトウェアステートメントの発行者と持つ信頼関係は、登録リクエストが受け入れられるかどうかの評価への入力として使用されることを意図しています。ソフトウェアステートメントは、クライアント登録リクエストの一部として認可サーバーに提示できます。

1.3. プロトコルフロー​

    +--------(A)- 初期アクセストークン (オプション)
    |
    |   +----(B)- ソフトウェアステートメント (オプション)
    |   |
    v   v
+-----------+                                      +---------------+
|           |--(C)- クライアント登録リクエスト ---->|  クライアント |
|クライアント|                                      |      登録     |
| または    |<-(D)- クライアント情報レスポンス -----|  エンドポイント |
| 開発者    |        またはクライアントエラーレスポンス +---------------+
+-----------+

図 1: 抽象的な動的クライアント登録フロー

図 1 に示されている抽象的な OAuth 2.0 クライアント動的登録フローは、クライアントまたは開発者と、この仕様で定義されているエンドポイントとの間の相互作用を説明しています。この図はエラー状態を示していません。このフローには、次の手順が含まれています。

(A) オプションで、クライアントまたは開発者に、クライアント登録エンドポイントへのアクセスを許可する初期アクセストークンが発行されます。初期アクセストークンがクライアントまたは開発者に発行される方法は、この仕様の範囲外です。

(B) オプションで、クライアントまたは開発者に、クライアント登録エンドポイントで使用するためのソフトウェアステートメントが発行されます。ソフトウェアステートメントがクライアントまたは開発者に発行される方法は、この仕様の範囲外です。

(C) クライアントまたは開発者は、クライアントの希望する登録メタデータを使用してクライアント登録エンドポイントを呼び出します。認可サーバーによって要求される場合は、(A) の初期アクセストークンを含めます。

(D) 認可サーバーはクライアントを登録し、以下を返します。

  *  クライアントの登録済みメタデータ、

  *  サーバーで一意のクライアント識別子、および

  *  このクライアントに適用可能な場合、クライアントシークレットなどの一連のクライアント認証情報。

さまざまな構成と使用例の例は、付録 A に含まれています。

に最終更新