100 spring-security 中 /oauth/token 发送请求不携带参数报错 “401 Unauthorized“

前言

最近存在这样的一个问题, 大致的复现方式是访问 /oauth/token 接口, 然后不携带任何参数, 结果服务器抛出了一个 "401 Unauthorized"

针对这个 401, 这里梳理一下这个流程, 也会衍生出一些其他的问题

测试用例

客户端这边大致的情况是构造参数, 然后发送请求, 上面两个参数封装到查询字符串的请求是可以正常处理

后面两个未携带参数的请求发送, 报错 "401 Unauthorized"

我们这里主要关心这里的未携带参数的异常场景, 以及造成这个问题的整个流程

3. 具体的 ignore-urls 的业务层面的使用

主要是在 FilterSecurityInterceptor, 这里面我们核心需要关注几个部分

    3.1 this.obtainSecurityMetadataSource().getAttributes(object) 根据当前 request 获取认证属性

    3.2 Authentication authenticated = authenticateIfRequired(); 根据请求头里面拿到的 token, 访问 auth 服务, 获取用户以及关联信息, 封装 Authentication

    3.3 accessDecisionManager.decide 结合认证属性和 Authentication 来判断是否有权限

/**
 * Test11TestRestClient
 *
 * @author Jerry.X.He
 * @version 1.0
 * @date 2022/5/19 17:44
 */
public class Test11TestRestClient {

    /// Test11TestRestClient
    public static void main(String[] args) {

        String username = "xxx";
        String password = "xxx";
        String grantType = "password";
        Map<String, String> queryParams = new LinkedHashMap<>();
        queryParams.put("username", username);
        queryParams.put("password", password);
        queryParams.put("grant_type", grantType);
        queryParams.put("scope", "server");
        queryParams.put("client_id", "xxx");
        queryParams.put("client_secret", "xxx");

        RestTemplate restTemplate = new RestTemplate();
        String queryString = Tools.encapQueryString(queryParams);

//        String loginUrl = "http://10.60.50.50:9999/auth/oauth/token?" + queryString;
//        Map result = restTemplate.postForObject(loginUrl, null, Map.class);
//        Map result = restTemplate.getForObject(loginUrl, Map.class);


        String loginUrl = "http://10.60.50.50:9999/auth/oauth/token";
        Map result = restTemplate.postForObject(loginUrl, null, Map.class);
        // todo, getForObject 的时候 查询字符串 未拼接 到 uri 中
//        Map result = restTemplate.getForObject(loginUrl, Map.class, queryParams);

        int x = 0;

    }

}

问题的调试

来到认证被拒绝的地方, 可以看到的是 /oauth/token 请求是需要 fullyAuthenticated 的

fullyAuthenticated 的条件是不是匿名用户并且 xxx, 这里我们的 authentication 因为没有携带参数信息, 然后匿名过滤器填充了一个匿名的 authentication

假设是在客户端正常携带了参数的场景下面, 是怎么过验证的呢?

这里走的是 ClientCredentialsTokenEndpointFilter 走的一个自定义的处理, 获取认证信息, 这里能够正常的拿到认证信息, 因此能够正常认证通过

我准备临时处理一下, 去掉 /oauth/token 的需要认证的处理, 于是在 WebSecurityConfigurer 中增加了 antMatchers("/oauth/token").permitAll() 但是, 从 this.obtainSecurityMetadataSource().getAttributes(object) 拿到的 attributes 还是 fullyAuthenticated, 而不是我这里配置的 permitAll

我们这里会出现几点疑问

为什么 /oauth/token 配置的是 fullyAuthenticated
为什么我配置了 antMatchers("/oauth/token").permitAll(), 但是没有生效

为什么 /oauth/token 配置的是 fullyAuthenticated

AuthorizationServerSecurityConfiguration 中 init 的时候初始化的时候配置 /oauth/token 为 fullyAuthenticated

AuthorizationServerSecurityConfiguration 是继承自 SecurityConfigurer, 是 spring-security 中自带的 XXConfiguration, 业务上面的限定一般还存在一个 WebSecurityConfigurer

为什么我配置了 antMatchers("/oauth/token").permitAll(), 但是没有生效

这里 AuthorizationServerSecurityConfiguration 的限定的是 "/oauth/token", "/oauth/token_key", "/oauth/check_token"
WebSecurityConfigurer 限定的是其他的业务上的大部分的请求, 我这里添加了一个 /oauth/token -> permitAll 但是没有生效

这里需要回溯一下 FilterSecurityInterceptor 的这一系列的整个流程

这里正向剖析一下这个流程, 反向回溯的过程着实开销不小

WebSecurityConfiguration.springSecurityFilterChain 创建了一个 FilterChainProxy, 注册于 spring 容器中

并且添加到了 tomcat 的 applicationFilterChain, 因此和具体的 http 请求处理的 TokenEndpoint 处理的过程关联起来

向 tomcat 的 applicationFilterChain 添加 filterDef 的地方来自于 SecurityFilterAutoConfiguration.securityFilterChainRegistration, 增加了一个 DelegatingFilterProxyRegistrationBean

这里 FilterChainProxy 内部组合了三个 filterChain, 然后根据 request 获取实际处理的 filterChain, 构建 filter 责任链来处理请求, 构建了一个 VirtualFilterChain, 在 tomcat 的 filter 责任链的基础上, 又嵌套了一层 filter责任链

这里我们的 /oauth/token, 匹配到了第二个 filterChain, oauth/token 对应的策略为 fullyAuthenticated

第一个 filterChain 对应的是 WebSecurityConfigurer 中构建的一个 ignoring 的策略

第二个 filterChain 对应的是 AuthorizationServerSecurityConfiguration 构建的一个 filterChain , 其中 /oauth/token 对应的策略为 fullyAuthenticated

第三个 filterChain 对应的是业务系统中自定义的 WebSecurityConfigurer 构建的一个 filterChain, 其中 /oauth/token 对应的策略为 permitAll

构建这个 FilterChainProxy 的过程是在 WebSecurity. performBuild 的过程中, 先添加的 ignoring, 然后再添加的各个 WebSecurityConfigurer 构建的 securityFilterChainBuilder

梳理一下构建 FilterChainProxy 的整个流程

WebSecurityConfiguration.springSecurityFilterChain 中创建了 WebSecurity, WebSecurity.build 创建了 tomcat 这边接入的 FilterChainProxy
这个 WebSecurity 组合了 applicationContext 中的 SecurityConfigurer, SecurityConfigurer 生成一个 HttpSecurity, HttpSecurity.build 会创建一个 DefaultFilterChain, 对应于 FilterChainProxy 组合的多个 DefaultFilterChain

在 WebWecurity init 的过程中, 各个 SecurityConfigurer 构建了相应的 HttpSecurity 然后注册到 WebWecurity 中, 这个过程会回调 SecurityConfigurer.configure(HttpSecurity http)
在 WebWecurity configure 的过程中, 会回调各个 SecurityConfigurer 的 configure(WebSecurity web)
在 WebWecurity performBuild 的过程中, 会构建 FilterChainProxy, 它组合了一系列的 DefaultFilterChain, 这个过程参见 WebWecurity.performBuild, 具体的方式是组合 WebWecurity 下面的 HttpSecurity 来构建 DefaultFilterChain

3.1 HttpSecurity performBuild 的过程中, 是直接根据已经采集的 filter 列表, 构建 DefaultFilterChain

3.2 HttpSecurity 的已经采集的 filter 是来自于 HttpSecurity 下面的 configurers 在 init, configure 的过程中处理进去的

3.3 HttpSecurity 下面的各个 configurers 来自于 SecurityConfigurer 的 configure(HttpSecurity http) 的过程中的相关业务处理, 诸如 '.authorizeRequests().antMatchers("/token/**", "/actuator/**", "/sso/**", "/test/**", "/oauth/token").permitAll()', '.formLogin().loginPage("/token/login").loginProcessingUrl("/token/form")', ".authorizeRequests()" 的相关是配置的就是请求认证的相关配置

以上一系列流程主要的目的是为 FilterSecurityInterceptor 中的 this.obtainSecurityMetadataSource().getAttributes(object) 服务

请求来了之后, 走 FilterChainProxy, FilterChainProxy 选择当前 request 需要使用的 DefaultFilterChain
DefaultFilterChain 中组合了一个责任链, 其中 FilterSecurityInterceptor 包含了如下认证步骤, 也是认证的相关问题核心需要关注的地方

引用自 "20220321_01 配置了 security.oauth2.client.ignore-urls 但是访问配置的服务依然 "用户信息已过期或已更新，请重新登录" 问题"

3. 具体的 ignore-urls 的业务层面的使用

主要是在 FilterSecurityInterceptor, 这里面我们核心需要关注几个部分

    3.1 this.obtainSecurityMetadataSource().getAttributes(object) 根据当前 request 获取认证属性

    3.2 Authentication authenticated = authenticateIfRequired(); 根据请求头里面拿到的 token, 访问 auth 服务, 获取用户以及关联信息, 封装 Authentication

    3.3 accessDecisionManager.decide 结合认证属性和 Authentication 来判断是否有权限

另外还有一个细节是可以看到拿到的 filterChain, 相比于我们 SecurityConfigurer 的 configure(HttpSecurity http) 中配置的处理会多一些

这部分 filter 来自于 SecurityConfigurer.getHttp 的过程中初始化的一部分 Configurer, 诸如 AnonymousAuthenticationFilter, ExceptionTranslationFilter 等等