Skip to content

MS_OIDCDynamicClientRegistration

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

OpenID Connect - Dynamic Client Registration

概要

Final を参照して記述。

Client（RP）が、（Discovery で発見した）IdP/STS（OP）に、
動的な登録を行う、
「クライアント登録エンドポイント」の仕様について記載してある。

補足（Discovery と対になる仕様）: Discovery が
「RP が OP を見つけて、その能力を知る」仕様であるのに対し、
本仕様は「RP が OP に自分を登録して client_id を得る」仕様である。
2 つを組み合わせると、
事前の人手による申請なしに RP と OP を接続できる。
実務では、事業者間の契約が前提になるため
手動登録のほうが一般的だが、
端末上のアプリ（SIOP）や
多数の RP を抱えるプラットフォームで効いてくる。

詳細

TLS サポートと、TLS 証明書のチェックが必要。

クライアント・メタデータ

クライアント・メタデータの用途

クライアント・メタデータの値は、次の 2 つの方法で使用される。

  • 入出力値

    • 入力値: 登録要求時の
    • 出力値: 登録応答および読み取り応答の

  • OpenID Connect によって使用される。

多言語化

  • client_name、tos_uri、policy_uri、logo_uri、および client_uri などの値は、
    一部のクライアント登録で複数のロケール固有の値を持つことがある。

  • この場合、同様に、言語タグを使用する。

クライアント・メタデータの一覧

  • 基本パラメタ
# パラメタ 要件 説明
1 redirect_uris REQUIRED 登録したクライアントの redirect_uri の JSON 配列
2 response_types OPTIONAL response_type 値の JSON 配列。既定値は「code」。
3 grant_types OPTIONAL grant_type 値の JSON 配列。既定値は「authorization_code」。
4 subject_type OPTIONAL subject_types_supported に対応するsub クレームの種類（public or pairwise）
5 sector_identifier_uri OPTIONAL pairwise 値の計算に利用する（pairwise をサポートする場合はあると良い）。
  • その他パラメタ
# パラメタ 要件 説明
1 default_max_age OPTIONAL デフォルトの最大認証期間。max_age 要求パラメタの既定値。
2 require_auth_time OPTIONAL ID トークンの auth_time 要求の要否
3 token_endpoint_auth_method OPTIONAL クライアント認証のタイプ。
既定値は client_secret_basic。
4 default_acr_values OPTIONAL デフォルトの認証コンテキスト クラス参照値。acr_values 要求パラメタの既定値。
5 request_uris OPTIONAL 事前に登録された request_uri 値の配列。
Discovery の require_request_uri_registration で事前登録要求可能
6 initiate_login_uri OPTIONAL ログイン開始エンドポイントの URL
  • クライアント情報パラメタ
# パラメタ 要件 説明
1 application_type OPTIONAL native or web の JSON 配列。既定値は「web」。
2 contacts OPTIONAL クライアントを担当する担当者の電子メールアドレスの配列。
3 client_name OPTIONAL クライアントがエンドユーザに提示する、クライアント名。
4 logo_uri OPTIONAL クライアントがエンドユーザに提示する、アプリケーションのロゴの URL。
5 client_uri OPTIONAL クライアントがエンドユーザに提示する、ホームページの URL。
6 policy_uri OPTIONAL クライアントがエンドユーザに提示する、プロファイル利用規約の URL。
7 tos_uri OPTIONAL クライアントがエンドユーザに提示する、サービス利用規約の URL。
  • 暗号関連パラメタ
# 対象 パラメタ 要件 説明
1 JWK
1-1 〃 jwks OPTIONAL JWK Set
1-2 〃 jwks_uri OPTIONAL jwks_uri
2 クライアント認証
2-1 〃 token_endpoint_auth_signing_alg OPTIONAL クライアント認証署名アルゴリズム
（Discovery の token_endpoint_auth_signing_alg_values_supported に対応）
既定値は RS256, 署名なし不可。
3 ID トークン
3-1 〃 id_token_signed_response_alg OPTIONAL ID トークン署名アルゴリズム
（Discovery の id_token_signing_alg_values_supported に対応）
既定値は RS256。
3-2 〃 id_token_encrypted_response_alg OPTIONAL ID トークン暗号化アルゴリズム
（Discovery の id_token_encryption_alg_values_supported に対応）
既定値は暗号化なし。
3-3 〃 id_token_encrypted_response_enc OPTIONAL ID トークン暗号化アルゴリズム
（Discovery の id_token_encryption_enc_values_supported に対応）
既定値は A128CBC-HS256（alg があれば必要）。
4 ユーザー属性エンドポイント
4-1 〃 userinfo_signed_response_alg OPTIONAL ユーザー属性エンドポイント署名アルゴリズム
（Discovery の userinfo_signing_alg_values_supported に対応）
既定値は署名なし。
4-2 〃 userinfo_encrypted_response_alg OPTIONAL ユーザー属性エンドポイント暗号化アルゴリズム
（Discovery の userinfo_encryption_alg_values_supported に対応）
既定値は暗号化なし。
4-3 〃 userinfo_encrypted_response_enc OPTIONAL ユーザー属性エンドポイント暗号化アルゴリズム
（Discovery の userinfo_encryption_enc_values_supported に対応）
既定値は A128CBC-HS256（alg があれば必要）。
5 Request オブジェクト
5-1 〃 request_object_signing_alg OPTIONAL Request オブジェクト署名アルゴリズム
（Discovery の request_object_signing_alg_values_supported に対応）
既定値は RS256, 署名なし可。
5-2 〃 request_object_encryption_alg OPTIONAL Request オブジェクト暗号化アルゴリズム
（Discovery の request_object_encryption_alg_values_supported に対応）
既定値は RP の宣言なし。
5-3 〃 request_object_encryption_enc OPTIONAL Request オブジェクト暗号化アルゴリズム
（Discovery の request_object_encryption_enc_values_supported に対応）
既定値は A128CBC-HS256（alg があれば必要）。

移行メモ（表の体裁）: 暗号関連パラメタの表は、元ページでは
PukiWiki のセル結合で「対象」の行と個々のパラメタ行を表現していた。
GitHub の Markdown はセル結合に対応していないため、
「対象」列を追加して見出し行（1・2・3…）と
明細行（1-1・1-2…）を分け、縦の結合は 〃 に置き換えた。

補足（Discovery と対称になっている）: 上の暗号関連パラメタは、
すべて Discovery の *_supported（OP が対応できるもの）と
対になっている。
OP が「対応可能なアルゴリズムの一覧」を Discovery で公開し、
RP が「実際に使うアルゴリズム」を Registration で 1 つ選ぶ、
という関係である。

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

初期アクセス トークン

  • 公開動的登録をサポートする場合、
    エンドポイントは初期アクセス トークンなしで登録要求を受け入れるべき。
  • （この仕様の範囲外の方法で）初期アクセス トークンを要求し、
    許可されたクライアントだけに登録要求を制限することができる。

補足（無制限の公開登録は現実的でない）: 初期アクセス トークンを
要求しない「公開動的登録」は、誰でも client_id を作れることを意味し、
大量登録やフィッシング用クライアントの作成に悪用され得る
（後述の「偽装」も参照）。
このため実運用では、初期アクセス トークンや
ソフトウェア ステートメント（RFC 7591）で登録者を制限する。

登録リクエスト

  • パラメタ一覧
    任意のクライアント・メタデータのパラメタを使用して、
    HTTP POST メッセージをクライアント登録エンドポイントに送信

  • 例

POST /connect/register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ...
{
 "application_type": "web",
 "redirect_uris":
   ["https://client.example.org/callback",
    "https://client.example.org/callback2"],
 "client_name": "My Example",
 "client_name#ja-Jpan-JP":
   "クライアント名",
 "logo_uri": "https://client.example.org/logo.png",
 "subject_type": "pairwise",
 "sector_identifier_uri":
   "https://other.example.net/file_of_redirect_uris.json",
 "token_endpoint_auth_method": "client_secret_basic",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "userinfo_encrypted_response_alg": "RSA1_5",
 "userinfo_encrypted_response_enc": "A128CBC-HS256",
 "contacts": ["ve7jtb@example.org", "mary@example.org"],
 "request_uris":
   ["https://client.example.org/rf.txt
     #qpXaRLh_n93TTR9F252ValdatUQvQiJi5BDub2BeznA"]
}

登録レスポンス

登録メタデータとともに、プロビジョニングされたフィールドを含めて返す。

  • パラメタ一覧

    • 成功
# パラメタ 要件 説明
1 client_id REQUIRED 登録したクライアントの client_id
2 client_id_issued_at OPTIONAL client_id が発行された時刻。
3 client_secret OPTIONAL 登録したクライアントの client_secret
（PKCE や private_key_jwt などのケースがあるので）
4 client_secret_expires_at REQUIRED client_secret が期限切れになる時刻。
（client_secret が発行された場合は必須）
5 registration_access_token OPTIONAL 後続のクライアント登録操作を実行するための登録アクセス トークン。
6 registration_client_uri OPTIONAL 前述の registration_access_token を使用して、
後続のクライアント登録操作を実行するための構成エンドポイントの場所。		 
HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "client_id": "s6BhdRkqt3",
 "client_secret":
   "ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk",
 "client_secret_expires_at": 1577858400,
 "registration_access_token":
   "this.is.an.access.token.value.ffx83",
 "registration_client_uri":
   "https://server.example.com/connect/register?client_id=s6BhdRkqt3",
 "token_endpoint_auth_method":
   "client_secret_basic",
 "application_type": "web",
 "redirect_uris":
   ["https://client.example.org/callback",
    "https://client.example.org/callback2"],
 "client_name": "My Example",
 "client_name#ja-Jpan-JP":
   "クライアント名",
 "logo_uri": "https://client.example.org/logo.png",
 "subject_type": "pairwise",
 "sector_identifier_uri":
   "https://other.example.net/file_of_redirect_uris.json",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "userinfo_encrypted_response_alg": "RSA1_5",
 "userinfo_encrypted_response_enc": "A128CBC-HS256",
 "contacts": ["ve7jtb@example.org", "mary@example.org"],
 "request_uris":
   ["https://client.example.org/rf.txt
     #qpXaRLh_n93TTR9F252ValdatUQvQiJi5BDub2BeznA"]
}
  • 失敗
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "error": "invalid_redirect_uri",
 "error_description": "One or more redirect_uri values are invalid"
}

クライアント構成エンドポイント

定義された仕様は HTTP GET メソッドのみ

登録アクセス トークン

registration_access_token で返された登録アクセス トークンを使用

構成の更新リクエスト・レスポンス

  • リクエスト
    registration_client_uri で返された URL と QueryString を使用して、
    任意のクライアント・メタデータのパラメタを送る。

  • レスポンス
    登録レスポンスと同じ形式で、更新後のクライアント・メタデータを返す。
    未指定のパラメタは既定値に戻る（差分更新ではない）点に注意する。

  • 参考: OAuth 2.0 の Registration

移行メモ（補完）: 元ページはレスポンスが「・・・」のみで
書かれていなかったため、参考にある RFC 7592 の
Client Update Request の挙動に沿って補った。
なお、OpenID Connect の Dynamic Client Registration 1.0 が
定義しているのは GET（読み取り）だけで、
更新（PUT）と削除（DELETE）は RFC 7592 側の仕様である。
著者による本文が加筆された場合は置き換えること。

構成の読取リクエスト・レスポンス

  • リクエスト
GET /connect/register?client_id=s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer this.is.an.access.token.value.ffx83

  • レスポンス

    • 成功
      更新されていない限り、registration_access_token または
      registration_client_uri 値を含める必要はない。
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
 "client_id": "s6BhdRkqt3",
 "client_secret":
   "OylyaC56ijpAQ7G5ZZGL7MMQ6Ap6mEeuhSTFVps2N4Q",
 "client_secret_expires_at": 17514165600,
 "registration_client_uri":
   "https://server.example.com/connect/register?client_id=s6BhdRkqt3",
 "token_endpoint_auth_method":
   "client_secret_basic",
 "application_type": "web",
 "redirect_uris":
   ["https://client.example.org/callback",
    "https://client.example.org/callback2"],
 "client_name": "My Example",
 "client_name#ja-Jpan-JP":
   "クライアント名",
 "logo_uri": "https://client.example.org/logo.png",
 "subject_type": "pairwise",
 "sector_identifier_uri":
   "https://other.example.net/file_of_redirect_uris.json",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "userinfo_encrypted_response_alg": "RSA1_5",
 "userinfo_encrypted_response_enc": "A128CBC-HS256",
 "contacts": ["ve7jtb@example.org", "mary@example.org"],
 "request_uris":
   ["https://client.example.org/rf.txt
     #qpXaRLh_n93TTR9F252ValdatUQvQiJi5BDub2BeznA"]
}
  • 失敗
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token",
  error_description="The access token expired"
Cache-Control: no-store
Pragma: no-cache

sector_identifier_uri検証

sector_identifier_uri値

  • https スキームを使用する URL

    • redirect_uri 値の配列を含む JSON ファイルを参照できる。
      これにより、クライアントの再登録をせずに、redirect_uri 値を変更可能。
    • また、pairwise の sub クレーム値を計算するのにも使用する。

  • この値は、登録時に検証されなければならない。

補足（sector_identifier_uri が要る理由）: pairwise の sub は
RP ごとに異なる値にして名寄せを防ぐ仕組みだが、
素朴に redirect_uri のホスト名から算出すると
同一事業者が複数ドメインを持つ場合に sub が別々になってしまう。
sector_identifier_uri は「これらのドメインは同じ事業者のものだ」と
宣言するためのもので、算出のキーをこの URI のホスト名に固定できる。

sector_identifier_uri のリクエスト・レスポンス

  • リクエスト
GET /file_of_redirect_uris.json HTTP/1.1
Accept: application/json
Host: other.example.net
  • レスポンス
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
[ "https://client.example.org/callback",
  "https://client.example.org/callback2",
  "https://client.other_company.example.net/callback" ]

考慮事項

実装

OAuth 2.0 の Registration

必要に応じて以下をサポートしても良い。

プレファイナルIETF仕様

－

ステートレス動的クライアント登録

  • client_id 値にクライアントに関する必要な登録情報をエンコード
  • クライアントの初期登録によって、以下は返されないため、読み取り操作は不可能。
    • 登録アクセストークン
    • クライアント構成エンドポイント

補足（サーバに状態を持たない登録）: client_id 自体に
redirect_uris などを署名付きで埋め込んでしまえば、
OP 側にクライアントのレコードを保存しなくてよい。
大量の RP を抱える場合に有効だが、
登録内容を後から変更・失効できないという制約が付く。

セキュリティ

偽装

  • クライアント情報パラメタの情報でクライアント偽装がされる可能性がある。
  • IdP/STS（OP）はフィッシングのリスクを軽減するために措置を講じる必要がある。

ネイティブ・コード・リーク

  • カスタム URI スキームの利用によってリークする可能性がある。
  • この問題は、IETF OAuth ワーキンググループで議論されており、
    標準的な解決策が開発されることが期待される。

補足（その後の解決策）: 「標準的な解決策が開発されることが期待される」と
書かれていた課題については、その後

  • OAuth PKCE（RFC 7636）… 認可コードの横取り対策
  • クレーム済みの HTTPS スキーム（App Links / Universal Links）…
    カスタム URI スキームの乗っ取り対策

が OAuth 2.0 for Native Apps（RFC 8252）で
ベスト プラクティスとして整理された。

参考

本 Wiki 内

Tags: IT国際標準, 認証基盤, クレームベース認証, OAuth

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally