是的，这在一般情况下和OAuth2中都是可能的。我认为首先了解如何在没有OAuth2的情况下做到这一点会有所帮助，因为相同的技术适用于OAuth2和保护资源服务器中的资源。
同样重要的是要注意，资源服务器上的“主体”（包含在Authentication中）的概念被Map到授予对客户端的访问权限的用户（通常是访问令牌的主题或"sub"声明），而不是客户端（通常是访问令牌的受众或"aud"声明）。
事实上，您可以使用授权方案的组合（分层方法），从URL和范围（粗粒度）开始，并在请求/URL级别或方法级别（细粒度）添加其他约束。请考虑以下示例：

@Configuration
@EnableWebSecurity
@EnableMethodSecurity
public class ResourceServerConfig {

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        // @formatter:off
        http
            .authorizeHttpRequests((authorize) -> authorize
                .requestMatchers("/*/messages").hasAuthority("SCOPE_message.read")
                .anyRequest().denyAll()
            )
            .oauth2ResourceServer((oauth2) -> oauth2
                .jwt(Customizer.withDefaults())
            );
        // @formatter:on

        return http.build();
    }

}

个字符
这是一个人为的例子（userId是没有意义的），但希望您能理解这一点。访问令牌的作用域为message.read，因此/{userId}/messages端点需要用户授予该权限，但资源服务器还需要资源所有者的名称与使用@PreAuthorize注解的路径变量相匹配，从而保护用户的资源。
根据应用程序的域和端点结构，还有很多其他方法可以完成任务，但基本原理是相同的。OpenID Connect不是必需的，因为资源服务器不关心用户是如何被认证的。