Skip to content

OAuth Client ID Metadata Document

Web Authorization Protocol                                    A. Parecki
Internet-Draft                                                      Okta
Intended status: Standards Track                                E. Smith
Expires: 11 April 2026                                    8 October 2025


                   OAuth Client ID Metadata Document
            draft-ietf-oauth-client-id-metadata-document-00

Abstract

この仕様は、事前の動的クライアント登録やその他の既存登録を行わなくても、OAuth クライアントが authorization servers に対して自分自身を識別できる仕組みを定義する。これは、OAuth フローにおいて URL を client_id として用い、その URL が必要なクライアントメタデータを含む文書を参照することで実現する。これにより authorization server は、必要に応じてクライアントに関するメタデータを取得できる。

About This Document

この注記は、RFC として公開する前に削除される。

このドラフトの最新版は、draft-ietf-oauth-client-id-metadata-document.html で参照できる。本文書のステータス情報は datatracker 上で参照できる。

本文書に関する議論は、Web Authorization Protocol Working Group のメーリングリスト（oauth@ietf.org）で行われ、アーカイブは mailarchive.ietf.org で参照できる。購読は ietf.org の案内ページから行える。

このドラフトのソースおよび issue tracker は、GitHub 上の oauth-wg リポジトリにある。

Status of This Memo

この Internet-Draft は、BCP 78 および BCP 79 の規定に完全に準拠して提出されている。

Internet-Drafts は、Internet Engineering Task Force（IETF）の作業文書である。他のグループも Internet-Drafts として作業文書を配布することがある。現在の Internet-Drafts の一覧は datatracker の current drafts ページにある。

Internet-Drafts は最大 6 か月間有効なドラフト文書であり、いつでも更新・置換・廃止され得る。Internet-Drafts を参考資料として扱ったり、「作業中（work in progress）」以外として引用することは不適切である。

この Internet-Draft は 11 April 2026 に失効する。

Copyright (c) 2025 IETF Trust および文書の著者として識別される者。All rights reserved.

本文書は、公開日に有効な IETF Trust の「IETF 文書に関する法的規定（Legal Provisions Relating to IETF Documents）」の適用を受ける。これらの文書には、本文書に関する権利と制限が記述されているため、注意深く確認すること。本文書から抽出された Code Components には、Trust Legal Provisions の Section 4.e に記述された Revised BSD License の文面を含めなければならず、また Revised BSD License に記載のとおり無保証で提供される。

Table of Contents

1. Introduction

OAuth 2.0（[RFC6749]）のクライアントが OAuth 2.0 の authorization server を利用するには、クライアントは一意の識別子を確立し、アプリケーション名・アイコン・redirect URIs といったアプリケーションのメタデータを server に提供する必要がある。クライアントが、関係性のない authorization servers とやり取りする場合、手動登録は不可能である。

Dynamic Client Registration（[RFC7591]）は、未知のクライアントが authorization server において自身を確立し、クライアント識別子を取得するための方法を提供できる。しかし、これはデプロイによっては常に実用的とは限らず、登録データの管理や非アクティブなクライアントのクリーンアップに関する追加の課題を生み得る。

本仕様は、OAuth 2.0 のクライアントが自身の登録情報を公開し、各 authorization server で事前登録する必要を避ける方法を説明する。

2. Conventions and Definitions

本文書におけるキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、すべて大文字で表記されている場合に限り、BCP 14（[RFC2119] および [RFC8174]）で記述されているとおりに解釈される。

3. Client Identifier

本仕様は、クライアント識別子を、以下の制約を満たす URL として定義する。クライアント識別子の URL は、「https」スキームでなければならず、パス要素を含まなければならず、単一ドットまたは二重ドットのパスセグメントを含んではならず、フラグメント要素を含んではならず、ユーザー名またはパスワードを含んではならない。クライアント識別子の URL は、クエリ文字列要素を含めないことが望ましく（SHOULD NOT）、ポートを含んでもよい（MAY）。

本仕様は、どの URL をクライアント識別子として用いるかについて制約を置かない。URL は、認可インターフェースや管理インターフェースで End-User に表示される可能性があるため、短い URL が推奨される（RECOMMENDED）。また、クライアントに対して頻繁に変更されない安定した URL を用いることも推奨される（RECOMMENDED）。

4. Client Information Discovery

authorization server にクライアントを登録する目的の 1 つは、OAuth フロー中に利用できるクライアントに関する追加情報を authorization server が持てるようにすることである。たとえば、同意画面においてクライアント名やロゴなど、ユーザーにクライアントの情報を提示する場合がある。

authorization server は、クライアント登録情報を取得するために、client_id が指し示す文書を取得することが望ましい（SHOULD）。

4.1. Client Metadata

クライアントメタデータ文書の URL は、クライアントのメタデータを含む JSON 文書である。クライアントメタデータの値は、OAuth Dynamic Client Registration Metadata の OAuth Parameters registry に定義された値である（IANA の oauth-parameters レジストリの client-metadata 節）。

クライアントメタデータ文書には client_id プロパティを含めなければならず（MUST）、その値は、[RFC3986] Section 6.2.1 で定義される単純な文字列比較により、当該文書の URL と一致しなければならない（MUST）。

クライアントメタデータ文書は、レスポンス内で追加のプロパティを定義してもよい（MAY）。また、レスポンスが JSON であり application/+json に適合している限り、より特定の content types で提供されてもよい（MAY）。

クライアントメタデータ文書で使用する共有秘密を確立する方法がないため、クライアントメタデータ文書の内容には、次の制約が適用される。

  • token_endpoint_auth_method プロパティには、client_secret_post、client_secret_basic、client_secret_jwt、または共有の対称鍵（shared symmetric secret）に基づく他の方法を含めてはならない（MUST NOT）。
  • client_secret および client_secret_expires_at プロパティは使用してはならない（MUST NOT）。

詳細は Section 6.2 を参照のこと。

他の仕様は、当該仕様を実装する authorization servers が受け入れるクライアントメタデータ文書の内容に、追加の制約を置いてもよい（MAY）。たとえば、token_endpoint_auth_method プロパティを "none" に設定することを要求することで、confidential clients の登録を防ぐ、といった制約である。

TBD: 特に開発用途のサービスが発行する文書において、クライアントが一時的であり、特定のタイムスタンプ以降は無効であることを示すために、client_id_expires_at のようなプロパティが必要になるかもしれない。

4.2. Client Metadata Documents for Development Purposes

authorization server は、有効な redirect_uris として受け入れるものに制約を設ける場合がある。たとえば、redirect_uris を client_id または client_uri プロパティと同一オリジン（same-origin）に限定することがある。しかし、authorization server が受け入れる redirect_uris に追加の制約を設ける場合には、それらの制約が適用されない Client ID Metadata Document Service（後述）を少なくとも 1 つ提供することが望ましい（SHOULD）。

本仕様を用いる authorization server に対してアプリケーションを開発する際、開発者はしばしば「localhost 上でアプリを開発しているのに、公開アクセス可能な https URL で Client ID Metadata Document をどうやって提供すればよいのか？」という問題に直面する。

開発者が自分のマシンを公開インターネットに露出させることなく、自分のマシン上でアプリケーションを作成できるようにするため、authorization server による Client ID Metadata Document Services の利用が推奨される（RECOMMENDED）。

Client ID Metadata Document Service は、開発者が Client ID Metadata Document の安定した URL を取得できる web service である。このサービスは、ときどきクライアントを失効させてもよく（MAY）、開発中のクライアントに関して追加情報の提供を開発者に求めてもよい（MAY）。

authorization server が少なくとも 1 つの Client ID Metadata Document Service を提供することで、開発者はアプリケーションを作成でき、同時に、これから認可しようとしているクライアントが現在開発中であり、信頼できない、または安全でない可能性があることを、技術に詳しくない人々にも示せる。

4.3. Metadata Discovery Errors

メタデータ文書の取得に失敗した場合、authorization server は認可リクエストを中止することが望ましい（SHOULD）。

4.4. Metadata Caching

authorization server は、クライアントメタデータ文書の URL で発見したクライアントメタデータをキャッシュしてもよい（MAY）。

authorization server は、クライアントメタデータをキャッシュする際に HTTP cache headers（[RFC9111]）を尊重することが望ましい（SHOULD）が、許容されるキャッシュ寿命について独自の上限および／または下限を定義してもよい（MAY）。

authorization server は、エラーレスポンスをキャッシュしてはならない（MUST NOT）。また、無効または不正な形式の文書もキャッシュしてはならない（MUST NOT）。

4.5. Redirect URL Registration

[RFC9700] によれば、authorization server は redirect URIs の登録を要求しなければならず（MUST）、またリクエストに含まれる redirect URI が登録済み redirect URI のいずれかと完全一致であることを保証しなければならない（MUST）。

このクライアント情報発見（discovery）の方法は、authorization server に登録済みの redirect URI を確立し、それを用いて認可リクエスト内の redirect URI と登録済み redirect URIs を比較する。

5. Authorization Server Metadata

Authorization Server Metadata（[RFC8414]）を公開する authorization servers は、本仕様で説明するクライアントメタデータ文書のサポートを示すために、次のプロパティを含めなければならない（MUST）。

client_id_metadata_document_supported: OPTIONAL。authorization server が、本仕様で説明するように client_id URL からクライアントメタデータを取得することをサポートしているかどうかを示す Boolean 値。

これによりクライアントは、本仕様をサポートする authorization server にのみユーザーをリダイレクトすることで、ユーザーが行き止まりに誘導されることを避けられる。そうでなければ、クライアントはユーザーをリダイレクトし、ユーザーは [RFC6749] の Section 4.1.2.1 に記述されるように、無効なクライアントに関するエラーに直面することになる。

6. Security Considerations

OAuth 2.0 Core（[RFC6749]）、OAuth 2.0 Threat Model and Security Considerations（[RFC6819]）、および [RFC9700] のセキュリティ考慮事項に加えて、以下の追加の考慮事項が適用される。

6.1. Relationship between redirect_uris and client_id or client_uri

authorization server は、redirect_uris と client_id または client_uri プロパティとの間に制約や関係性を課してもよい（MAY）。たとえば、redirect_uri を Client ID Metadata Document と同一オリジンに限定する、といった制約である。このような制約がない場合、クライアントがより有名なクライアントになりすましたり、その他悪意ある行為をしたり、End-User を危険にさらしたりする、といった信頼・安全上の問題が起こり得る。

redirect_uris と client_id または client_uri との関係に制約を設けないことは、[Solid-OIDC] の Client ID Documents において一般的な慣行であったため、[Solid-OIDC] と本仕様との後方互換性のために、この能力は保持されている。

redirect_uris に対する一部の制約は、開発者にとって Client ID Metadata Documents の利用を難しくし得る。Section 4.2 には、redirect_uri に制約を課す authorization servers に対して、開発用途での Client ID Metadata Documents を可能にするための推奨事項が含まれる。

6.2. Client Authentication

クライアントは authorization server に対して自身の登録データを確立するため、クライアント認証情報の事前調整は不可能である。しかし、クライアントは、公開鍵／秘密鍵のペアを用いる認証方法を利用し、公開鍵をメタデータ文書で公開することで、authorization server に認証情報を確立してもよい（MAY）。

たとえばクライアントは、メタデータ文書に次のプロパティを含めることで公開鍵を確立し、[OpenID] で定義される private_key_jwt 認証方法を広告できる（advertise）。

{
  ...
  "token_endpoint_auth_method": "private_key_jwt",
  "jwks_uri": "https://client.example.com/jwks.json"
  ...
}

これにより、このクライアントは Confidential client として確立され、authorization server とのあらゆる通信には、登録された種類の client authentication を含めなければならない（MUST）。

クライアントが秘密鍵をどのように管理するかという具体的な方法は、本仕様のスコープ外であるが、手動でのプロビジョニングや、Attestation Based Client Authentication（[I-D.draft-ietf-oauth-attestation-based-client-auth]）のような方法を含み得る。たとえば、クライアント開発者は Client Attester Backend を運用できる。そこでは Native App のプラットフォーム固有 API を用いて Backend service に対して認証を行い、jwks_uri の鍵に対応する秘密鍵は Backend service により管理される。この場合、モバイル app は Backend service に対して JWT の発行を要求し、その JWT を authorization server に対する client authentication として利用できる。

6.3. Changes in Client Keys

authorization server が、jwks_uri または jwks_uri の内容が、前回メタデータを取得したときと比べて変更されていることに気づいた場合、authorization server は、このクライアントに発行されたトークンの失効、またはこのクライアントに対するユーザーの同意（consent）の失効などの措置を取ってもよい（MAY）。どの措置を取るかは、authorization server が自身のリスク評価に基づいて裁量で決定する。

6.4. OAuth Phishing Attacks

authorization servers は、認可リクエストで提供された client_id のメタデータ文書を取得し、アプリケーション名やロゴなど、リクエストに関する追加情報をユーザーに提供することが望ましい（SHOULD）。server がクライアントメタデータ文書を取得しない場合、ユーザーに可能な限り多くのリクエスト情報が提供されるように、追加の対策を講じることが望ましい（SHOULD）。

authorization server は、取得したクライアント情報（もしあれば）を表示することに加えて、認可インターフェース上で client_id の hostname を表示することが望ましい（SHOULD）。hostname を表示することで、ユーザーは想定どおりのアプリケーションを認可していることを把握しやすくなる。

クライアントメタデータ文書の取得が何らかの理由で失敗した場合、ユーザーがどのアプリケーションを認可しているかを示す情報として、client_id の URL だけが唯一の手がかりになる。

6.5. Server Side Request Forgery (SSRF) Attacks

authorization servers がクライアントメタデータ文書を取得し、メタデータ文書内にある URL を解決する際には、SSRF 攻撃の可能性を考慮すべきである。authorization servers は、プライベートアドレスまたはループバックアドレスを用いて URL を取得することを避け（SHOULD）、ネットワークポリシーやその他の手段により、これらのアドレスへのリクエストを防ぐことを検討すべきである。authorization servers は、URL が http 以外の URI scheme である可能性にも注意すべきであり（SHOULD）、それが他の SSRF 攻撃ベクトルにつながる可能性がある。

6.6. Maximum Response Size for Client Metadata Documents

authorization servers は、クライアントメタデータ文書を取得する際のレスポンスサイズを制限し、過剰なリソース（メモリ、ディスク、データベース）消費によるサービス拒否攻撃を避けることが望ましい（SHOULD）。クライアントメタデータ文書の推奨最大レスポンスサイズは 5 キロバイトである。

6.7. Displaying Logos to End-Users

authorization servers が、クライアントメタデータ文書内の logo_uri プロパティを利用したい場合、logo_uri が指すファイルを事前取得し、クライアントメタデータ文書のキャッシュ期間の間キャッシュすることが望ましい（SHOULD）。これにより、（たとえば他のロゴに似せたロゴの使用を防ぐなど）ファイル内容を検証するためのモデレーションツールが利用でき、また End-User を混乱させるためにロゴが動的に差し替えられることを防げる。

さらに、logo_uri のレスポンスをキャッシュすることで、logo_uri がクライアントによりリクエストされることを通じたクロスドメイン追跡を防ぐことにもつながる。キャッシュされたファイルはリモート URI からではなく、authorization server が信頼する URI から提供されるためである。

6.8. Client ID Domain Trust

authorization server は、client IDs として使われるドメイン名の信頼に関して、独自のヒューリスティクスやポリシーを持つことを選んでもよい（MAY）。

たとえば authorization server は、最初の 100 人のユーザーが client_id を認可する際に、OAuth 同意画面の前に追加の警告画面を表示することを要求できる。authorization server は、ドメインがいつ登録されたかなど、ドメイン評判（domain reputation）の属性を確認し、新しいドメインに対して追加の警告を表示できる。

7. IANA Considerations

7.1. OAuth Authorization Server Metadata Registry

次の authorization server metadata 値は、本仕様により定義され、OAuth 2.0 Authorization Server Metadata（[RFC8414]）で確立された IANA の「OAuth Authorization Server Metadata」レジストリに登録される。

  • Metadata Name: client_id_metadata_document_supported:
  • Metadata Description: authorization server が client_id URL からクライアントメタデータを取得することをサポートしているかどうかを示す JSON boolean 値。
  • Change Controller: IETF
  • Specification Document: [draft-ietf-oauth-client-id-metadata-document-00] の Section 5

8. References

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.

[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012.

[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013.

[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018.

[RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025.

8.2. Informative References

[I-D.draft-ietf-oauth-attestation-based-client-auth] Looker, T., Bastian, P., and C. Bormann, "OAuth 2.0 Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-attestation-based-client-auth-07, 15 September 2025.

[IndieAuth] Parecki, A., "IndieAuth", 12 February 2022.

[OpenID] Sakimura, N., Bradley, J., Jones, M., Medeiros, B. de., and C. Mortimore, "OpenID Connect Core 1.0", 15 December 2023.

[OpenID.Federation] Hedberg, R., Jones, M.B., Solberg, A.Å., Bradley, J., Marco, G. D., and V. Dzhuvinov, "OpenID Federation 1.0", 17 May 2024.

[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015.

[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022.

[Solid-OIDC] Coburn, A., elf Pavlik, and D. Zagidulin, "Solid-OIDC", 28 March 2022.

Acknowledgments

OAuth ベースの認可リクエストで URIs を client_id として利用するという考え方は新しいものではなく、[IndieAuth]、[Solid-OIDC]、および [OpenID.Federation] により、これまでにもさまざまな形で仕様化されてきた。本仕様は、参照可能な Client Identifier Documents を定義した [Solid-OIDC] 仕様における Aaron Coburn、elf Pavlik、Dmitri Zagidulin の成果から大きな着想を得ている。

著者は、本仕様への貢献とレビューを行った次の人々に感謝する。Brian Campbell、Dick Hardt、Leif Johansson、Pieter Kasselman、Bryan Newbold、Matthieu Sieben、Filip Skokan。

Document History

（この付録は、最終仕様では RFC editor により削除される。）

-00

  • 初期ドラフト

Authors' Addresses

Aaron Parecki
Okta
Email: aaron@parecki.com
URI: aaronparecki.com

Emelia Smith
Email: emelia@brandedcode.com
URI: thisismissem.social