为什么Spring Security OAuth2 DefaultTokenServices在加载身份验证时检查clientId?

为什么Spring Security OAuth2 DefaultTokenServices在加载身份验证时检查clientId?,oauth,spring-security,oauth-2.0,spring-security-oauth2,Oauth,Spring Security,Oauth 2.0,Spring Security Oauth2,为什么DefaultTokenServices在方法loadAuthentication中检查clientId: if (clientDetailsService != null) { String clientId = result.getOAuth2Request().getClientId(); try { clientDetailsService.loadClientByClientId(clientId);

为什么
DefaultTokenServices
在方法
loadAuthentication
中检查
clientId

    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应用程序中,如果授权服务器不是对所有客户机负责,但资源服务器必须为所有客户机服务,那么检查会带来问题

在纯资源服务器上,clientDetailsService可以为null。资源服务器可以在不知道已注册客户端的情况下工作,而安全性仍然可以在访问令牌的其他属性上实施,例如资源ID和访问令牌的有效性

在纯授权服务器上,没有问题,因为授权服务器必须有一个clientDetailsService,它知道可以为其颁发令牌的所有客户端

但是,在混合服务器上,授权服务器可能不知道所有可能的客户端,因为可能存在其他授权服务器。然后,资源服务器组件将检查上述代码中的每个clientId,并拒绝来自该授权服务器不知道的客户端的所有请求

让场景易于理解的示例:

  • 有一个混合服务器(授权和资源服务器合二为一),为业务用户颁发令牌,并提供管理业务用户的服务(例如创建、锁定、解锁等)

  • 还有一个单独的授权服务器,为管理用户颁发令牌。管理用户使用UI管理(如创建、锁定、解锁等)业务用户,即他们使用1的服务。使用2发行的代币


  • 我想我并没有真正遵循将客户隔离的逻辑。在任何情况下,我不认为资源服务器和授权端点必须共享相同的
    *TokenServices
    (它们甚至不使用相同的接口)