アクセストークンを介した認証と承認にOAuth2を使用する(httpsのみ)APIがあります。
APIへのリクエストには、Authorizationヘッダーへのアクセストークンが必要です。 APIは、このアクセストークンが特定のテナント(googleなど)によって署名され、特定の対象ユーザーを対象とし、特定のスコープを持っていることを検証します。
ユーザー/サービスとして、APIがパブリックエンドポイントでそのような情報を公開し、どこから(たとえば、PKCEを介して)アクセストークンをフェッチする必要があるか、およびどのスコープを必要とするかがわかると、非常に役立ちます。トークンをリクエストします。
これの自然なメカニズムは、APIが以下のようなパブリックエンドポイントを持つことです。
{
"provider_uri": "https://accounts.google.com/.well-known/openid-configuration",
"client_id":"...apps.googleusercontent.com",
"scope":"openid ..."
}
これは有効なアプローチですか?そのような問題に対処するために他に関連するイディオムは何ですか?
はい、それは有効なアプローチです。メタデータは公開情報です。
実装は、APIでサポートされているプロトコルによって異なります。プロトコルとしてOpenID Connectの場合、OpenID Connect Discovery仕様は、サービスの実装のさまざまな側面を記述するためにサービスが公開できるメタデータについて話します。 OIDC Discovery 仕様から:
OpenIDプロバイダーが識別されると、そのOPの構成情報が、そのOAuth 2.0エンドポイントの場所を含む、JSONドキュメントとして既知の場所から取得されます。[...]
応答は、必要なすべてのエンドポイントと公開鍵の場所情報を含む、OpenIDプロバイダーの構成に関する一連のクレームです。