通过后面对SpringSecurity平安过滤器工作原理的剖析（ Spring Security平安过滤器工作原理）咱们晓得Spring Security的用户认证过程的工作原理大略为：

  1. SecurityContextPersistenceFilter过滤器负责基于session的用户认证信息的治理。
  2. UsernamePasswordAuthenticationFilter负责用户登录认证，认证胜利后将认证信息写入SecurityContextHolder中。
  3. FilterSecurityInterceptor负责验证以后用户是否合乎以后申请的安全策略要求。

所以咱们晓得用户认证是在UsernamePasswordAuthenticationFilter过滤器实现的，如果咱们要实现自定义的用户登录认证的话，只有想方法替换掉UsernamePasswordAuthenticationFilter过滤器中的原装缺省用户认证过程，应该就能够了。

接下来咱们钻研：

  1. 什么是用户认证。
  2. UsernamePasswordAuthenticationFilter过滤器的缺省认证过程。
  3. 如何替换掉UsernamePasswordAuthenticationFilter的缺省用户认证过程。

什么是用户认证

这个问题其实咱们并不钻研、只是申明，明确一下咱们所要钻研的问题的主题。

Spring Security官网overview局部开宗明义阐明SpringSecurity是什么的时候就明确提过用户认证：

Spring Security is a framework that provides authentication, authorization, and protection against common attacks.

阐明用户认证是Spring Security的重要主题之一。

咱们简化、明确一下明天要钻研的用户认证这个主题理论就是：用户身份认证，让零碎搞清楚你是否是非法用户的过程。

目前我的项目上或者咱们见过的零碎中用的最多的身份认证形式还是用户名、明码（或者短信验证码），用户身份认证其实蕴含两局部内容：

  1. 身份确认：通过登录形式实现。
  2. 身份放弃及验证：就是登录验证实现之后，用户身份认证信息在保留以及后续的用户拜访过程中的验证问题。

第一个问题比较简单明确，第二个问题就会引入两种不同的支流框架，次要区别是用户身份认证信息如何保留：

  1. 服务器端保留：最常见的session形式。
  2. 客户端持有：比方JWT的形式

咱们明天要探讨的是身份认证的过程，疏忽或简化身份信息的保留和持有过程，或者说咱们就以传统的、Spring Security默认提供的通过session形式在服务器端持有用户身份认证信息的形式，来把明天钻研的主题聚焦在身份认证这个问题上。

UsernamePasswordAuthenticationFilter过滤去的身份认证过程

先来意识几个概念：

  1. Authentication：或者叫AuthenticationToken，默认实现是UsernamePasswordAuthenticationToken，用来持有申请上来的用户名、明码等信息，以及最终通过认证后的用户认证信息。
  2. AuthenticationManager：认证管理器，由他来发动认证，然而他不实现认证，而是有他持有的AuthenticationProvider实现。
  3. AuthenticationProvider：如上。
  4. UserDetails：零碎非法用户信息，比方你的零碎的非法用户保留在数据库中，那么在发动认证的过程中就须要从数据库获取到后保留在UserDetails中，对应的有一个叫UserDetailsService的家伙，负责干这个事。
  5. PasswordEncoder：顾名思义，明码编码器，零碎用户的明码在零碎中肯定是以密文保留，前台提交上来的个别是明文，须要通过PasswordEncoder验密。说白了你的明码加密算法就是在PasswordEncoder中实现。

差不多够了，咱们就用下面几个概念来阐明一下UsernamePasswordAuthenticationFilter过滤器的用户登录认证过程。

第一步用request生成UsernamePasswordAuthenticationToken，此时生成的UsernamePasswordAuthenticationToken对象中只有前端登录页面传上来的用户名、明码，该token尚未实现认证。咱们假如前台送上来的用户叫：user。前台录入的明码是：123456。

第二步，获取到AuthenticationManager进行认证，下面说过了，他是manager，他不干活，交给AuthenticationProvider去干。

第三步，AuthenticationProvider开始干活，他首先获取到UserDetailsService，让他获取到零碎中叫user的用户信息，返回UserDetails对象（假如获取到了，对象名叫sysUser）。

第四步，仍然是由AuthenticationProvider持续干，拿着前端送上来的用户名、明码（以后由UsernamePasswordAuthenticationToken对象持有）、以及后盾获取到的用户对象（sysUser），交给PasswordEncoder去验密。

第五步，AuthenticationProvider持续拼命干活，如果认证通过的话（明码一样），从新生成一个UsernamePasswordAuthenticationToken，这是曾经实现认证的token。

第六步，AuthenticationProvider干完活了交给经理AuthenticationManager，经理甩手把后果交给过滤器UsernamePasswordAuthenticationFilter。

第七步，过滤器把最终认证过的UsernamePasswordAuthenticationToken保留在SecurityContextHolder中，供后续过滤器、尤其是FilterSecurityInterceptor验证应用。

UsernamePasswordAuthenticationFilter完成使命！

如何替换掉UsernamePasswordAuthenticationFilter的缺省用户认证过程

这个题目长的我有点不太适应，然而就这样吧。

这个问题你如果去百度或者google的话，会有很多不同的答案，我了解因为Spring Security自身是Spring家族的一员，与Spring或SpringBoot联合之后留给用户的客户化形式泛滥，所以咱们能够任选其一进行客户化。

任何既可能实现你的指标、又没有给你的我的项目带来负面影响计划，都是可行的。

上面咱们开始实现这一指标。

通过上面对UsernamePasswordAuthenticationFilter工作过程的剖析，咱们能够先构想一个思路：替换掉上述第三步中的UserDetailsService，让咱们本人的UserDetailsService干活，去获取咱们本人的用户。

我认为这是比较简单的计划，你当然能够替换掉整个UsernamePasswordAuthenticationFilter，然而这样的话你就相当于是替换掉了Spring Security的一个重要模块，你就能够狐疑他还是不是Spring Security了。

篇幅起因，本篇剖析原理，下一篇文章具体操作。

上一篇 Spring Security平安过滤器工作原理
下一篇 Spring Security自定义用户认证过程（2）