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

3. クライアント登録エンドポイント

クライアント登録エンドポイントは、このドキュメントで定義されている OAuth 2.0 エンドポイントであり、クライアントを認可サーバーに登録できるように設計されています。クライアント登録エンドポイントは、"application/json" 形式を使用してエンティティ本体にエンコードされたリクエストパラメータを含む HTTP POST メッセージを受け入れる必要があります（MUST）。セクション 5 で説明されているように、クライアント登録エンドポイントはトランスポート層セキュリティメカニズムによって保護されなければなりません（MUST）。

クライアント登録エンドポイントは、OAuth 2.0 [RFC6749] で保護されたリソースである場合があり（MAY）、以前に認可された関係者のみに登録を制限するために、OAuth 2.0 アクセストークンの形式で初期アクセストークンを受け入れる場合があります（MAY）。クライアントまたは開発者が初期アクセストークンを取得する方法は、通常、帯域外であり、この仕様の範囲外です。クライアント登録エンドポイントによって初期アクセストークンが検証および検証される方法は、この仕様の範囲外です。

オープン登録をサポートし、より広範な相互運用性を促進するために、クライアント登録エンドポイントは、認可なし（つまり、リクエストに初期アクセストークンがない）の登録リクエストを許可する必要があります（SHOULD）。これらのリクエストは、クライアント登録エンドポイントに対するサービス拒否攻撃を防ぐために、レート制限またはその他の制限が行われる場合があります（MAY）。

3.1. クライアント登録リクエスト​

この操作は、クライアントを認可サーバーに登録します。認可サーバーは、このクライアントに一意のクライアント識別子を割り当て、オプションでクライアントシークレットを割り当て、リクエストで提供されたメタデータを、発行されたクライアント識別子に関連付けます。リクエストには、登録中にクライアントに指定されているクライアントメタデータパラメータが含まれます。認可サーバーは、クライアントメタデータで省略されたアイテムのデフォルト値を提供する場合があります（MAY）。

登録するには、クライアントまたは開発者は、コンテンツタイプ "application/json" で HTTP POST をクライアント登録エンドポイントに送信します。HTTP エンティティペイロードは、JSON オブジェクトと、その JSON オブジェクトのトップレベルメンバーとしてのすべての要求されたクライアントメタデータ値で構成される JSON [RFC7159] ドキュメントです。

たとえば、サーバーがオープン登録（初期アクセストークンなし）をサポートしている場合、クライアントは次の登録リクエストをクライアント登録エンドポイントに送信できます。

以下は、初期アクセストークンを使用しない非規範的なリクエストの例です。

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com

{
 "redirect_uris": [
   "https://client.example.org/callback",
   "https://client.example.org/callback2"],
 "client_name": "My Example Client",
 "client_name#ja-Jpan-JP":
    "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "token_endpoint_auth_method": "client_secret_basic",
 "logo_uri": "https://client.example.org/logo.png",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "example_extension_parameter": "example_value"
}

あるいは、サーバーが認可された登録をサポートしている場合、開発者またはクライアントには初期アクセストークンが提供されます。（初期アクセストークンを取得する方法は、この仕様の範囲外です。）開発者またはクライアントは、次の認可された登録リクエストをクライアント登録エンドポイントに送信します。この例では初期アクセストークンが OAuth 2.0 Bearer トークン [RFC6750] として送信されていますが、OAuth 2.0 トークンタイプは認可サーバーで使用できます。

以下は、初期アクセストークンを使用し、JWK Set を値で登録する非規範的なリクエストの例です（表示のみを目的として値内に改行が含まれています）。

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Bearer ey23f2.adfj230.af32-developer321
Host: server.example.com

{
 "redirect_uris": ["https://client.example.org/callback",
    "https://client.example.org/callback2"],
 "client_name": "My Example Client",
 "client_name#ja-Jpan-JP":
    "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "token_endpoint_auth_method": "client_secret_basic",
 "policy_uri": "https://client.example.org/policy.html",
 "jwks": {"keys": [{
    "e": "AQAB",
    "n": "nj3YJwsLUFl9BmpAbkOswCNVx17Eh9wMO-_AReZwBqfaWFcfG
HrZXsIV2VMCNVNU8Tpb4obUaSXcRcQ-VMsfQPJm9IzgtRdAY8NN8Xb7PEcYyk
lBjvTtuPbpzIaqyiUepzUXNDFuAOOkrIol3WmflPUUgMKULBN0EUd1fpOD70p
RM0rlp_gg_WNUKoW1V-3keYUJoXH9NztEDm_D2MQXj9eGOJJ8yPgGL8PAZMLe
2R7jb9TxOCPDED7tY_TU4nFPlxptw59A42mldEmViXsKQt60s1SLboazxFKve
qXC_jpLUt22OC6GUG63p-REw-ZOr3r845z50wMuzifQrMI9bQ",
    "kty": "RSA"
 }]},
 "example_extension_parameter": "example_value"
}

3.1.1. ソフトウェアステートメントを使用したクライアント登録リクエスト​

JSON 要素に加えて、セクション 2.3 で説明されているように、クライアントメタデータ値をソフトウェアステートメントで提供することもできます（MAY）。認可サーバーは、この機能をサポートしていない場合、ソフトウェアステートメントを無視する場合があります（MAY）。サーバーがソフトウェアステートメントをサポートしている場合、ソフトウェアステートメントで伝達されるクライアントメタデータ値は、単純な JSON 要素を使用して伝達される値よりも優先されなければなりません（MUST）。

ソフトウェアステートメントは、次の OPTIONAL メンバーを使用して、要求する JSON オブジェクトに含まれます。

software_statement クレームとしてクライアントソフトウェアに関するクライアントメタデータ値を含むソフトウェアステートメント。これは、署名された JWT 全体を含む文字列値です。

次の例では、一部の登録パラメータはセクション 2.3 の例のソフトウェアステートメントのクレームとして伝達され、クライアントインスタンスに固有の一部の値は通常のパラメータとして伝達されます（表示のみを目的として値内に改行が含まれています）。

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com

{
  "redirect_uris": [
    "https://client.example.org/callback",
    "https://client.example.org/callback2"
  ],
  "software_statement": "eyJhbGciOiJSUzI1NiJ9.
eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA",
  "scope": "read write",
  "example_extension_parameter": "example_value"
}

3.2. レスポンス​

登録リクエストが成功すると、認可サーバーはクライアントのクライアント識別子を返します。サーバーは、HTTP 201 Created ステータスコードと、セクション 3.2.1 で説明されている内容の "application/json" タイプの本文で応答します。

登録リクエストが失敗すると、認可サーバーはセクション 3.2.2 で説明されているようにエラーで応答します。

3.2.1. クライアント情報レスポンス​

レスポンスには、クライアント識別子と、クライアントが機密クライアントである場合はクライアントシークレットが含まれます。レスポンスには、この仕様の拡張によって指定された追加のフィールドが含まれる場合があります（MAY）。

client_id REQUIRED。OAuth 2.0 クライアント識別子文字列。認可サーバーは独自の裁量で登録されたクライアントの複数のインスタンスに同じクライアント識別子を発行する場合がありますが（MAY）、現在他の登録されたクライアントに対して有効であってはなりません（SHOULD NOT）。

client_secret OPTIONAL。OAuth 2.0 クライアントシークレット文字列。発行される場合、これは "client_id" ごとに一意でなければならず（MUST）、同じ "client_id" を使用するクライアントの複数のインスタンスに対して一意である必要があります（SHOULD）。この値は、OAuth 2.0 [RFC6749]、セクション 2.3.1 で説明されているように、機密クライアントがトークンエンドポイントに対して認証するために使用されます。

client_id_issued_at OPTIONAL。クライアント識別子が発行された時刻。時刻は、1970-01-01T00:00:00Z から UTC で測定された発行日時までの秒数として表されます。

client_secret_expires_at "client_secret" が発行される場合は REQUIRED。クライアントシークレットの有効期限が切れる時刻、または有効期限が切れない場合は 0。時刻は、1970-01-01T00:00:00Z から UTC で測定された有効期限の日時までの秒数として表されます。

さらに、認可サーバーは、認可サーバー自体によってプロビジョニングされたフィールドを含む、このクライアントに関するすべての登録済みメタデータを返さなければなりません（MUST）。認可サーバーは、登録中に送信されたクライアントのリクエストされたメタデータ値を拒否または置換し、適切な値に置き換える場合があります（MAY）。クライアントまたは開発者は、レスポンス内の値を確認して、登録が使用に十分であるかどうか（たとえば、登録された "token_endpoint_auth_method" がクライアントソフトウェアでサポートされているかどうか）を判断し、クライアントソフトウェアに適した行動方針を決定できます。このような状況への対応はこの仕様の範囲外ですが、アプリケーション開発者または認可サーバープロバイダーへのレポートの提出、異なるメタデータ値での再登録の試行、またはその他のさまざまな方法が含まれる可能性があります。たとえば、サーバーが [RFC7592] で定義されているような登録管理メカニズムもサポートしている場合、クライアントまたは開発者は、異なるメタデータ値で登録を更新しようとする可能性があります。このプロセスは、サーバーの機能を一覧表示できる [OpenID.Discovery] などのサービス検出プロトコルによっても支援され、クライアントがより多くの情報に基づいた登録リクエストを行えるようになります。このような管理システムまたは検出システムの使用は任意であり、この仕様の範囲外です。

成功した登録レスポンスは、HTTP 201 Created ステータスコードを使用し、オブジェクトのトップレベルメンバーとしてすべてのパラメータを持つ単一の JSON オブジェクト [RFC7159] で構成される "application/json" タイプの本文を使用します。

ソフトウェアステートメントが登録の一部として使用された場合、その値は、"software_statement" メンバー名を使用して他のメタデータとともにレスポンスで変更されずに返されなければなりません（MUST）。ソフトウェアステートメントから使用されるクライアントメタデータ要素も、登録レスポンスのトップレベルのクライアントメタデータ値として直接返されなければなりません（MUST）（リクエストされた値と使用される値が異なる場合があるため、値が異なる可能性があります）。

以下は、成功した登録の非規範的なレスポンスの例です。

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "client_id": "s6BhdRkqt3",
 "client_secret": "cf136dc3c1fc93f31185e5885805d",
 "client_id_issued_at": 2893256800,
 "client_secret_expires_at": 2893276800,
 "redirect_uris": [
   "https://client.example.org/callback",
   "https://client.example.org/callback2"],
 "grant_types": ["authorization_code", "refresh_token"],
 "client_name": "My Example Client",
 "client_name#ja-Jpan-JP":
    "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "token_endpoint_auth_method": "client_secret_basic",
 "logo_uri": "https://client.example.org/logo.png",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "example_extension_parameter": "example_value"
}

3.2.2. クライアント登録エラーレスポンス​

クライアントが無効な初期アクセストークンを提示するなどの OAuth 2.0 エラー状態が発生した場合、認可サーバーは OAuth 2.0 トークンタイプに適したエラーレスポンスを返します。

登録エラー状態が発生すると、認可サーバーは、レスポンス本文のエラーを記述する JSON オブジェクト [RFC7159] で構成されるコンテンツタイプ "application/json" を含む HTTP 400 ステータスコード（特に指定がない限り）を返します。

JSON オブジェクトに含めるために 2 つのメンバーが定義されています。

error REQUIRED。単一の ASCII エラーコード文字列。

error_description OPTIONAL。デバッグに使用されるエラーの人間が読める ASCII テキストの説明。

他のメンバーも含まれる場合があり（MAY）、理解できない場合は無視しなければなりません（MUST）。

この仕様では、次のエラーコードが定義されています。

invalid_redirect_uri 1 つ以上のリダイレクト URI の値が無効です。

invalid_client_metadata いずれかのクライアントメタデータフィールドの値が無効であり、サーバーはこのリクエストを拒否しました。認可サーバーは、クライアントのメタデータの任意のリクエストされたパラメータに有効な値を代入することを選択できることに注意してください（MAY）。

invalid_software_statement 提示されたソフトウェアステートメントが無効です。

unapproved_software_statement 提示されたソフトウェアステートメントは、この認可サーバーによる使用が承認されていません。

以下は、認可サーバーによってブラックリストに登録されているリダイレクト URI に起因するエラーレスポンスの非規範的な例です（表示のみを目的として値内に改行が含まれています）。

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "error": "invalid_redirect_uri",
 "error_description": "The redirection URI
   http://sketchy.example.com is not allowed by this server."
}

以下は、"response_types" 値と "grant_types" 値の矛盾した組み合わせに起因するエラーレスポンスの非規範的な例です（表示のみを目的として値内に改行が含まれています）。

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "error": "invalid_client_metadata",
 "error_description": "The grant type 'authorization_code' must be
   registered along with the response type 'code' but found only
  'implicit' instead."
}
に最終更新