メソッドでDefaultTokenServicesチェックを行う理由：clientIdloadAuthentication
if (clientDetailsService != null) {
String clientId = result.getOAuth2Request().getClientId();
try {
clientDetailsService.loadClientByClientId(clientId);
}
catch (ClientRegistrationException e) {
throw new InvalidTokenException("Client not valid: " + clientId, e);
}
}
上記は質問です。以下は、なぜ私がそれを思いついたのかを説明するための背景です。私が質問する理由は特別なシナリオです。たとえば、認可サーバーがすべてのクライアントに対して責任があるわけではなく、リソースサーバーが責任を負う場合、リソースサーバーと認可サーバーであるSpring Bootアプリケーションでチェックが問題を引き起こします。すべてのクライアントにサービスを提供する必要があります。
純粋な Resource Server では、clientDetailsService を null にすることができます。リソース サーバーは、登録されたクライアントを知らなくても動作できますが、リソース ID やアクセス トークンの有効性など、アクセス トークンの他のプロパティにセキュリティを適用することもできます。
純粋な認可サーバーでは問題はありません。認可サーバーには、トークンを発行できるすべてのクライアントを認識する clientDetailsService が必要だからです。
ただし、混合サーバーでは、他の承認サーバーが存在する可能性があるため、承認サーバーはすべての可能なクライアントを認識していない場合があります。Resource Server コンポーネントは、上記のコード内のすべての clientId をチェックし、この Authorization Server が認識していないクライアントからのすべてのリクエストを拒否します。
シナリオをわかりやすくするための例:
ビジネス ユーザーにトークンを発行し、ビジネス ユーザーを管理するためのサービス (作成、ロック、ロック解除など) を提供する混合サーバー (承認サーバーとリソース サーバーが 1 つ) があります。
管理ユーザー用のトークンを発行する別の承認サーバーもあります。管理ユーザーは、UI を使用してビジネス ユーザーを管理 (作成、ロック、ロック解除など) します。つまり、2. によって発行されたトークンで 1. のサービスを使用します。