要約

  • RFC 9728 は保護リソースが相互運用に必要なメタデータを公開する方法を定めるが、その文書自体はリソースへの権利を与えない。
  • resource の厳密な一致がメタデータ利用の前提であり、その後のトークン発行、受入、実行効果は別々に判断される。

「このリソースはこの認可サーバーを使う」と読める文書は、便利であるほど過大に解釈されやすい。そこから分かるのは、クライアントが発見文書を取得し、次の候補となる issuer を得たことまでだ。その issuer がこのクライアントにトークンを発行するか、発行されたトークンが当該リソース向けか、リソースサーバーが受け入れるかは、まだ決まっていない。

RFC 9728 はこの最初の段階を整える。リソースは自らの識別子から導かれた .well-known の場所に JSON を置き、認可サーバー、scope、提示方式などを公開できる。これは探索の不確実性を減らす仕組みであり、リソース所有者の許可判断を代行する仕組みではない。

境界を支えるのは文字列の正確さである。通常の取得では必須の resource 値が、メタデータ URL を導いたリソース識別子と完全に一致しなければならない。WWW-Authenticate が URL を示した場合は、クライアントがリソースサーバーに実際に要求した URL と一致しなければならない。不一致なら、そのデータは使ってはならない。同じホストや似たパスでは足りない。

この規則は、一つのホストに複数のパスやテナントがある場面で特に重要だ。well-known の接尾辞はパスの前に挿入され、同じホストでも異なるリソースが異なる文書を公開できる。RFC 9728 は、それがホスト全体の情報ではないと明言する。発見文書をホスト全体の権限表として扱えば、トークン要求の前にすでにポリシー境界を取り違える。

公開された列挙も完全な権利台帳ではない。authorization_servers と scopes_supported は省略可能であり、対応する項目をあえて載せないことができる。署名付きメタデータも、誰が発見情報を保証したかを強めるだけで、クライアント認証、同意、トークン検証、業務上の実行判断を強めない。RFC 8414、RFC 8707、RFC 6750 は、それぞれ別の検証面を担う。

Sources