Spring Security 认证流程(源码分析)

一、认证处理流程说明

（1）

前端输入完用户名密码之后，会进入UsernamePasswordAuthenticationFilter类中去获取用户名和密码，然后去构建一个UsernamePasswordAuthenticationToken对象。

这个对象实现了Authentication接口，Authentication接口封装了验证信息，在调用UsernamePasswordAuthenticationToken的构造函数的时候先调用父类AbstractAuthenticationToken的构造方法，传递一个null，因为在认证的时候并不知道这个用户有什么权限。之后去给用户名密码赋值，最后有一个setAuthenticated（false）方法，代表未认证，源码如下：

（2）

实例化UsernamePasswordAuthenticationToken之后调用了setDetails(request,authRequest)将请求的信息设到UsernamePasswordAuthenticationToken中去，包括ip、session等内容

（3）

然后去调用AuthenticationManager,AuthenticationManager本身不包含验证的逻辑，它的作用是用来管理AuthenticationProvider。

注意：前三步都是UsernamePasswordAuthenticationFilter类的 attemptAuthentication 方法。

（4）第三步的authenticate这个方法是在ProviderManager类上的，这个类实现了AuthenticationManager接口，在authenticate方法中有一个for循环，去拿到所有的AuthenticationProvider，真正校验的逻辑是写在AuthenticationProvider中的，为什么是一个集合去进行循环？是因为不同的登陆方式认证逻辑是不一样的，可能是微信等社交平台登陆，也可能是用户名密码登陆。AuthenticationManager其实是将AuthenticationProvider收集起来，然后登陆的时候挨个去AuthenticationProvider中问你这种验证逻辑支不支持此次登陆的方式，根据传进来的Authentication类型会挑出一个适合的provider来进行校验处理。

然后去调用provider的验证方法authenticate方法，authenticate是DaoAuthenticationProvider类中的一个方法，DaoAuthenticationProvider继承了AbstractUserDetailsAuthenticationProvider。实际上authenticate的校验逻辑写在了AbstractUserDetailsAuthenticationProvider抽象类中，首先实例化UserDetails对象，调用了retrieveUser方法获取到了一个user对象，retrieveUser是一个抽象方法。

AbstractUserDetailsAuthenticationProvider的 authenticate 方法的一部分：

注意：如果自己自定义了一个MyAuthenticationProvider继承了AuthenticationProvider，这里就会走自己的认证类。

（5）DaoAuthenticationProvider实现了 retrieveUser 方法，在实现的方法中实例化了UserDetails对象

注意：如果自己自定义了UserDetailsServiceImpl 实现了 UserDetailsService就会走自己的方法。

也就是相当于自定义验证逻辑的那个类，去实现UserDetailService类，这个返回结果就是我们自己在数据库中根据username查询出来的用户信息。在AbstractUserDetailsAuthenticationProvider中如果没拿到信息就会抛出异常，如果查到了就会去调用preAuthenticationChecks的check方法去进行预检查。

AbstractUserDetailsAuthenticationProvider的 authenticate 方法的一部分：

在预检查中进行了三个检查，因为UserDetail类中有四个布尔类型，去检查其中的三个，用户是否锁定、用户是否过期，用户是否可用。

预检查之后紧接着去调用了additionalAuthenticationChecks方法去进行附加检查，这个方法也是一个抽象方法，在DaoAuthenticationProvider中去具体实现，在里面进行了加密解密去校验当前的密码是否匹配。

如果通过了预检查和附加检查，还会进行厚检查，检查4个布尔中的最后一个。

所有的检查都通过，则认为用户认证是成功的。用户认证成功之后，会将这些认证信息和user传递进去，调用createSuccessAuthentication方法。

createSuccessAuthentication方法中同样会实例化一个user，但是这个方法不会调用之前传两个参数的函数，而是会调用三个参数的构造函数。这个时候，在调super的构造函数中不会再传null，会将authorities权限设进去，之后将用户密码设进去，最后setAuthenticated(true),代表验证已经通过。

（6）最后创建一个authentication会沿着验证的这条线返回回去。如果验证成功，则在这条路中调用我们系统的业务逻辑。如果在任何一处发生问题，就会抛出异常，调用我们自己定义的认证失败的处理器。

二、认证结果如何在多个请求之间共享

问题：它是什么时候，把什么东西放到了session中，什么时候在session中读出来。
原理图：

在验证成功之后，其中会调用AbstractAuthenticationProcessingFilter 中的successfulAuthentication方法，在这个方法最后会调用我们自定义的successHandle登陆成功r处理器，在调用这个方法之前会调用SecurityContextHolder.getContext()的setAuthentication方法，会将我们验证成功的那个Authentication放到SecurityContext中，然后再放到SecurityContextHolder中。SecurityContextImpl中只是重写了hashcode方法和equals方法去保证Authentication的唯一。

SecurityContextHolder是ThreadLocal的一个封装，ThreadLocal是线程绑定的一个map，在同一个线程里在这个方法里往ThreadLocal里设置的变量是可以在另一个线程中读取到的。它是一个线程级的全局变量，在一个线程中操作ThreadLocal中的数据会影响另一个线程。也就是说创建成功之后，塞进去，此次登陆所有的请求都会通过SecurityContextPersisenceFilter去SecurityContextHolder拿那个Authentication。SecurityContextHolder在整个过滤器的最前面。

• 当请求时，检查 Session 中是否存在 SecurityContext，如果有将其放入到线程中。
• 当响应时，检查线程中是否存在 SecurityContext，如果有将其放入到 Session 中。

因为整个请求和响应的过程都是在一个线程里去完成的，所以在线程的其他位置随时可以用SecurityContextHolder来拿到认证信息。

三、获取认证用户信息

方法一：
@RestController
@RequestMapping("/user")
public class UserController {

    @GetMapping("/me")
    public Object getCurrentUser(){
        return SecurityContextHolder.getContext().getAuthentication();
    }

方法二：
 @GetMapping("/me")
    public Object getCurrentUser(Authentication authentication){
        return authentication;
    }

方法三：
@GetMapping("/me")
    public Object getCurrentUser(@AuthenticationPrincipal UserDetails userDetails){
        return userDetails;
    }