转载

Spring Security 解析(二) —— 认证过程

在学习Spring Cloud 时，遇到了授权服务oauth 相关内容时，总是一知半解，因此决定先把Spring Security 、Spring Security Oauth2 等权限、认证相关的内容、原理及设计学习并整理一遍。本系列文章就是在学习的过程中加强印象和理解所撰写的，如有侵权请告知。

项目环境:

JDK1.8
Spring boot 2.x
Spring Security 5.x

一、@EnableGlobalAuthentication 配置解析

还记得上一篇讲解授权过程中提到@EnableWebSecurity 引用了 WebSecurityConfiguration 配置类和 @EnableGlobalAuthentication 注解吗？当时只是讲解了下 WebSecurityConfiguration 配置类，这次该轮到 @EnableGlobalAuthentication 配置了。

查看 @EnableGlobalAuthentication 注解源码，我们可以看到其引用了AuthenticationConfiguration 配置类。其中有一个方法值得我们注意，那就是 getAuthenticationManager() （还记得授权过程中调用了 AuthenticationManager().authenticate() 进行认证么？）, 我们来看下其源码内部大致逻辑：

public AuthenticationManager getAuthenticationManager() throws Exception {

        ......
        // 1 调用 authenticationManagerBuilder 方法获取 authenticationManagerBuilder 对象，用于 build  authenticationManager 对象
        AuthenticationManagerBuilder authBuilder = authenticationManagerBuilder(
                this.objectPostProcessor, this.applicationContext);
        .....
        // 2  build 方法调用同授权过程中的 webSecurity.build()  一样，都是通过父类 AbstractConfiguredSecurityBuilder.doBuild() 方法中的 performBuild() 方法进行 build, 只是这里不再是通过其子类 HttpSecurity.performBuild() ，而是通过 AuthenticationManagerBuilder.performBuild() 
        authenticationManager = authBuilder.build();

        .......
        
        return authenticationManager;
    }

根据源码我们可以概括其逻辑分2部分：

1、通过调用 authenticationManagerBuilder() 方法获取 authenticationManagerBuilder 对象
2、调用authenticationManagerBuilder 对象的 build() 创建 authenticationManager 对象并返回

我们再详细看下这个build的过程，可以发现其 build 调用跟授权过程中build securityFilterChain 一样都是通过 AbstractConfiguredSecurityBuilder.doBuild() 方法中的 performBuild() 进行构建，不过这次不再是调用其子类 HttpSecurity.performBuild() 而是 AuthenticationManagerBuilder.performBuild() 。

我们来看下 AuthenticationManagerBuilder.performBuild() 方法内部实现：

protected ProviderManager performBuild() throws Exception {
        if (!isConfigured()) {
            logger.debug("No authenticationProviders and no parentAuthenticationManager defined. Returning null.");
            return null;
        }
        // 1  创建了一个包含  authenticationProviders  参数 的 ProviderManager 对象
        ProviderManager providerManager = new ProviderManager(authenticationProviders,
                parentAuthenticationManager);
        if (eraseCredentials != null) {
            providerManager.setEraseCredentialsAfterAuthentication(eraseCredentials);
        }
        if (eventPublisher != null) {
            providerManager.setAuthenticationEventPublisher(eventPublisher);
        }
        providerManager = postProcess(providerManager);
        return providerManager;
    }

这里我们主要关注其内部创建了一个包含 authenticationProviders 参数的 ProviderManager （ProviderManager 是 AuthenticationManager 的实现类）对象并返回。

回过头，我们来看下 AuthenticationManager 接口源码：

public interface AuthenticationManager {
    // 认证接口
    Authentication authenticate(Authentication authentication)
            throws AuthenticationException;
}

可以看到，内部就只有一个我们在授权过程中提到过的 authenticate()，其接口接收一个 Authentication （这个对象我们也不陌生，之前授权过程中提到过的 UsernamePasswordAuthrnticationToken 等都是其实现子类）对象作为参数。

至此认证的 部分关键类或接口 已经浮出水面了，它们分别是 AuthenticationManager 、ProviderManager、AuthenticationProvider、Authentication ，接下来我们就围绕这几个类或接口进行剖析。

二、AuthenticationManager

正如我们之前看到的一项，它是整个认证的入口，其定义的认证接口 authenticate() 接收一个 Authentication 对象作为参数。 AuthenticationManager 它只是提供了一个认证接口方法，因为在实际使用中，我们不仅有账户密码的登录方式，还有短信验证码登录、邮箱登录等等，所以它本身不做任何认证，其具体做认证的是 ProviderManager 子类，但正如我们说过的认证方式有很多，如果仅仅依靠 ProviderManager 本身来实现 authenticate() 接口，那我们要支持这么多认证方式不得写多少个 if 判断，而且以后如果我们想要支持指纹登录，那又不得不在这个方法内部加个if，这种不利于系统扩展的写法肯定是不可取的，所以 ProviderManager 本身会维护一个List< AuthenticationProvider >列表，用于存放多种认证方式，然后通过委托的方式，调用 AuthenticationProvider 来真正实现认证逻辑的。而 Authentication 就是我们需要认证的信息（当然不仅仅只包括账户信息），通过authenticate() 接口认证成功后返回的 Authentication 就是一个被标识认证成功的对象。这里为什么要解释下 AuthenticationManager、ProviderManager、AuthenticationProvider 的关系，主要是一开始容易搞混它们，相信经过这样一段描述更容易理解了吧。。。

三、Authentication

如果没有看过源码的同学可能会认为 Authentication 是一个类吧，可实际上它是一个接口，其内部并未存在任何属性字段，它仅仅定义了和规范好了认证对象需要的接口方法，我们来看看其定义的接口方法有哪些，分别又什么作用：

public interface Authentication extends Principal, Serializable { 

    // 1  获取权限信息（不能仅仅理解未角色权限，还有菜单权限等等），默认是GrantedAuthority接口的实现类
    Collection<? extends GrantedAuthority> getAuthorities();

    // 2 获取用户密码信息 ，认证成功后会被删除掉
    Object getCredentials();
    
    // 3  主要存放访问着的ip等信息
    Object getDetails();

    // 4  重点！！ 最重要的身份信息。 大部分情况下是 UserDetails 接口的实现 类，比如 我们 之前配置的 User 对象   
    Object getPrincipal();

    // 5  是否认证（成功）
    boolean isAuthenticated();

    // 6  设置认证标识 
    void setAuthenticated(boolean isAuthenticated) throws IllegalArgumentException;
}

既然 Authentication 定义了这些接口方法，那么其子类实现肯定都按照这个标准或者称之为规范定制了实现，这里就不罗列出其子类的具体实现了，有兴趣的同学可以去看下我们最常用的 UsernamePasswordAuthenticationToken 实现（包括其父类 AbstractAuthenticationToken）

四、ProviderManager

它是 AuthenticationManager 的实现子类之一，也是我们最常用的一个实现。正如我们前面提到过的，其内部维护了一个 List< AuthenticationProvider > 对象，用于支持和扩展多种形式的认证方式。我们来看下其实现 authenticate() 的源码：

public Authentication authenticate(Authentication authentication)
            throws AuthenticationException {
            
        ......
        
        // 1 通过 getProviders() 方法获取到内部维护的 List<AuthenticationProvider> 对象 并 通过遍历的方式 去 认证，只要认证成功 就 break 
        for (AuthenticationProvider provider : getProviders()) {
            //  2 正如前面看到的有 很多 AuthenticationProvider 实现，如果每次都是验证失败后再掉用下一个 AuthenticationProvider 这种实现是不是很不高效？ 所以 这里通过  supports() 方法来验证是否可以使用 该 AuthenticationProvider 进行验证，不可以就直接换下一个 
            if (!provider.supports(toTest)) {
                continue;
            }
            try {
                // 3  重点，这里是 调用真实的认证方法
                result = provider.authenticate(authentication);
                if (result != null) {
                    copyDetails(authentication, result);
                    break;
                }
            }
            catch (AccountStatusException e) {
                prepareException(e, authentication);
                throw e;
            }
            catch (InternalAuthenticationServiceException e) {
                prepareException(e, authentication);
                throw e;
            }
            catch (AuthenticationException e) {
                lastException = e;
            }
        }
        
        if (result == null && parent != null) {
            try {
                // 4 前面都认证不成功，调用父类（严格意思不是调用父类，而是其他的 AuthenticationManager 实现类）认证方法
                result = parentResult = parent.authenticate(authentication);
            }
            catch (ProviderNotFoundException e) {
        
            }
            catch (AuthenticationException e) {
                lastException = parentException = e;
            }
        }

        if (result != null) {
            if (eraseCredentialsAfterAuthentication
                    && (result instanceof CredentialsContainer)) {
                //  5  删除认证成功后的 密码信息，保证安全
                ((CredentialsContainer) result).eraseCredentials();
            }
            if (parentResult == null) {
                eventPublisher.publishAuthenticationSuccess(result);
            }
            return result;
        }
        
        if (lastException == null) {
            lastException = new ProviderNotFoundException(messages.getMessage(
                    "ProviderManager.providerNotFound",
                    new Object[] { toTest.getName() },
                    "No AuthenticationProvider found for {0}"));
        }
        if (parentException == null) {
            prepareException(lastException, authentication);
        }

        throw lastException;
    }

梳理下整个方法内部实现逻辑：

通过 getProviders() 方法获取到内部维护的 List<AuthenticationProvider> 对象并通过遍历的方式去认证
通过 provider.supports() 方法来验证是否可用当前的 AuthenticationProvider 进行验证，不可以就直接换下一个 ( 其实方法内部就是验证当前的 Authentication 对象是不是其某个子类，比如我们最常用到的 DaoAuthenticationProvider 的 supports 方法就是判断当前的 Authentication 是不是 UsernamePasswordAuthenticationToken )
通过 provider.authenticate() 调用其真正的认证实现
如果前面的所有 AuthenticationProvider 均不能认证成功，尝试调用 parent.authenticate() 方法：调用父类（严格意思不是调用父类，而是其他的 AuthenticationManager 实现类）认证方法
最后通过 ((CredentialsContainer) result).eraseCredentials() 删除认证成功后的密码信息，保证安全

五、AuthenticationProvider(DaoAuthenticationProvider)

正如我们想象的一样，AuthenticationProvider 是一个接口，本身定义了一个和 AuthenticationManager 一样的 authenticate 认证接口方法，外加一个 supports() 用于判别当前 Authentication 是否可以进行处理。

public interface AuthenticationProvider {
    // 定义认证接口方法
    Authentication authenticate(Authentication authentication)
            throws AuthenticationException;
    // 定义判断是否可以认证处理的接口方法
    boolean supports(Class<?> authentication);
}

这里我们就拿我们用得最多的一个 AuthenticationProvider 实现类 DaoAuthenticationProvider(注意，这里和UsernamePasswordAuthenticationFilter 类似，都是通过父类来实现接口，然后内部处理方法再调用其子类进行处理) 来看其内部这2个抽象方法的实现：

supports 实现：

public boolean supports(Class<?> authentication) {
        return (UsernamePasswordAuthenticationToken.class
                .isAssignableFrom(authentication));
    }

可以看到仅仅只是判断当前的 authentication 是否为 UsernamePasswordAuthenticationToken（或其子类）

authrnticate 实现

// 1 注意这里的实现方法是 DaoAuthenticationProvider 的父类 AbstractUserDetailsAuthenticationProvider 实现的
public Authentication authenticate(Authentication authentication)
            throws AuthenticationException {
    
        // 2 从 authentication 中获取 用户名
        String username = (authentication.getPrincipal() == null) ? "NONE_PROVIDED"
                : authentication.getName();

        boolean cacheWasUsed = true;
        
        // 3 根据username 从缓存中获取 认证成功的 UserDetails 信息
        UserDetails user = this.userCache.getUserFromCache(username);

        if (user == null) {
            cacheWasUsed = false;

            try {
                // 4 如果缓存中没有用户信息 需要 获取用户信息（由 DaoAuthenticationProvider 实现 ） 
                user = retrieveUser(username,
                        (UsernamePasswordAuthenticationToken) authentication);
            }
            catch (UsernameNotFoundException notFound) {
                ......
            }
        }

        try {
            // 5 前置检查账户是否锁定，过期，冻结（由DefaultPreAuthenticationChecks类实现）
            preAuthenticationChecks.check(user);
            // 6 主要是验证 获取到的用户密码与传入的用户密码是否一致
            additionalAuthenticationChecks(user,
                    (UsernamePasswordAuthenticationToken) authentication);
        }
        catch (AuthenticationException exception) {
            // 这里官方发现缓存可能导致了某些问题，又重新去认证一次
            if (cacheWasUsed) {
                // There was a problem, so try again after checking
                // we're using latest data (i.e. not from the cache)
                cacheWasUsed = false;
                user = retrieveUser(username,
                        (UsernamePasswordAuthenticationToken) authentication);
                preAuthenticationChecks.check(user);
                additionalAuthenticationChecks(user,
                        (UsernamePasswordAuthenticationToken) authentication);
            }
            else {
                throw exception;
            }
        }
        // 7 后置检查用户密码是否 过期
        postAuthenticationChecks.check(user);
        
        // 8 验证成功后的用户信息存入缓存
        if (!cacheWasUsed) {
            this.userCache.putUserInCache(user);
        }

        Object principalToReturn = user;

        if (forcePrincipalAsString) {
            principalToReturn = user.getUsername();
        }
        // 9 重新创建一个 authenticated 为true （即认证成功）的 UsernamePasswordAuthenticationToken 对象并返回 
        return createSuccessAuthentication(principalToReturn, authentication, user);
    }

梳理下authenticate（这里的方法的实现是由 AbstractUserDetailsAuthenticationProvider 提供的）方法内部实现逻辑：

从入参 authentication 对象中获取到 username 信息
（这里忽略缓存的处理）调用 retrieveUser() 方法（由 DaoAuthenticationProvider 实现）根据 username 获取到系统（一般来说是从数据库中）中获取到 UserDetails 对象
通过 preAuthenticationChecks.check() 方法检测当前获取到的 UserDetails 是否过期、冻结、锁定（如果任意一个条件为 true 将抛出相应的异常）
通过 additionalAuthenticationChecks() （由 DaoAuthenticationProvider 实现）判断密码是否一致
通过 postAuthenticationChecks.check() 检测 UserDetails 的密码是否过期
最后通过 createSuccessAuthentication() 重新创建一个 authenticated 为true （即认证成功）的 UsernamePasswordAuthenticationToken 对象并返回

虽然我们知道其验证逻辑，但其内部很多方法我们不清楚其内部实现，以及这里新增的一个关键认证类 UserDetails 是怎么设计的，如何验证其是否过期等等。

六、 UserDetailsService 和 UserDetails

继续深入看下 retrieveUser() 方法，首先我们注意到其返回对象是一个 UserDetails,那么我们先从 UserDetails 入手。

UserDetails：

我们先来看下 UserDetails 源码：

public interface UserDetails extends Serializable {
    
    // 1 与 Authentication 的 一样，都是获取 权限信息 
    Collection<? extends GrantedAuthority> getAuthorities();

    // 2 获取用户正确的密码   
    String getPassword();

    // 3 获取账户名
    String getUsername();

    // 4 账户是否过期
    boolean isAccountNonExpired();

    // 5 账户是否锁定
    boolean isAccountNonLocked();

    // 6 密码是否过期 
    boolean isCredentialsNonExpired();

    // 7 账户是否冻结
    boolean isEnabled();
}

从上面的 4，5，6，7 接口我们就能够知道 preAuthenticationChecks.check() 和 postAuthenticationChecks.check() 是如何检测的了，这里2个方法的检测细节就不再深究了，有兴趣的同学可以看看源码，我们只要知道检测失败会抛出异常就行了。

咋呼一看，这个UserDetails 和 Authentication 很相似，其实它们之间还真有关系，在createSuccessAuthentication() 传教Authentication 对象时，它的authorities 就是UserDetails 传入的。

UserDetailsService：

retrieveUser() 方法是系统通过传入的账户名获取对应的账户信息的唯一方法，我们来看下其内部源码逻辑：

protected final UserDetails retrieveUser(String username,
            UsernamePasswordAuthenticationToken authentication)
            throws AuthenticationException {
        prepareTimingAttackProtection();
        try {
        
            // 通过 UserDetailsService 的loadUserByUsername 方法 获取用户信息
            UserDetails loadedUser = this.getUserDetailsService().loadUserByUsername(username);
            if (loadedUser == null) {
                throw new InternalAuthenticationServiceException(
                        "UserDetailsService returned null, which is an interface contract violation");
            }
            return loadedUser;
        }
        catch (UsernameNotFoundException ex) {
            ......
        }
    }

相信看到这里，一切都关联上了，这里的 UserDetailsService.loadUserByUsername() 就是我们在上一篇授权过程中我们自己实现的。这里就不再贴出UserDetailsService 源码了。

还有additionalAuthenticationChecks() 密码验证没有讲到，这里简单提下，其内部就是通过 PasswordEncoder.matches() 方法进行密码匹配的。不过这里要注意一下，这里的 PasswordEncoder 在 Security 5 开始默认替换成了 DelegatingPasswordEncoder 这里也是和我们之前讨论 loadUserByUsername 方法内部创建User （UserDeatails 实现类之一）是一定要用到 PasswordEncoderFactories.createDelegatingPasswordEncoder().encode() 加密是相应的。

七、个人总结

认证的顶级管理员 AuthenticationManager 为我们提供了认证入口( authenticate()接口)，但是呢，我们也知道大老板一般不直接参与实质的工作，所以它把任务安排给它的下属，也就是我们的 ProviderManager 部门领导，部门领导肩负起认证的工作（authenticate() 认证的实现），其实呢，我们也知道部门领导也是直接参数认证工作的，它都是将实际任务安排给小组长的，也就是我们的 AuthrnticationProvider ，部门领导开个会议，聚集了所有小组长，让它们自行判断（通过

support()）大老板交下来的任务该由谁来完成，小组长领到任务后，就把任务分发给各个小组成员，比如成员1( UserDetailsService ) 只需要完成 retrieveUser() 的工作，然后成员2 完成 additionalAuthenticationChecks() 的工作，最后由项目经理 ( createSuccessAuthentication() ) 将结果汇报给小组长，然后小组长汇报给部门领导，部门领导审核一下结果，觉得小组长做得不够好，然后又做了一些操作（ eraseCredentials() 擦除密码信息），最后认为结果可以了就汇报给老板，老板呢，也不多看，直接将结果给了客户(filter)。

按照惯例，上流程图：

Spring Security 解析(二) —— 认证过程