前言
本文以用户名/密码验证方式为例，讲解 Spring Security 的认证流程，在此之前，需要你了解 Spring Security 用户名/密码认证的基本配置。
Spring Security 是基于过滤器的，通过一层一层的过滤器，处理认证的流程，拦截非法请求。
认证上下文的持久化
处于最前面的过滤器叫做 SecurityContextPersistenceFilter，Spring Security 是通过 Session 来存储认证信息的，这个过滤器的 doFilter 方法在每次请求中只执行一次，作用就是，在请求时，将 Session 中的 SecurityContext 放到当前请求的线程中（如果有），在响应时，检查县城中是否有 SecurityContext，有的话将其放入 Session。可以理解为将 SecurityContext 进行 Session 范围的持久化。
认证信息的封装
接着进入 UsernamePasswordAuthenticationFilter，这是基于用户名/密码认证过程中的主角之一。
默认情况下，这个过滤器会匹配路径为 /login 的 POST 请求，也就是 Spring Security 默认的用户名和密码登录的请求路径。
这里最关键的代码是 attemptAuthentication 方法（由 doFilter 方法调用），源码如下：
@Override
public Authentication attemptAuthentication ( HttpServletRequest request, HttpServletResponse response )
throws AuthenticationException {
if ( this.postOnly && !request.getMethod () .equals ( "POST" )) {
throw new AuthenticationServiceException ( "Authentication method not supported: " + request.getMethod ()) ;
}
String username = obtainUsername ( request ) ;
username = ( username != null ) ? username : "";
username = username.trim () ;
String password = obtainPassword ( request ) ;
password = ( password != null ) ? password : "";
UsernamePasswordAuthenticationToken authRequest = new UsernamePasswordAuthenticationToken ( username, password ) ;
// Allow subclasses to set the "details" property
setDetails ( request, authRequest ) ;
return this.getAuthenticationManager () .authenticate ( authRequest ) ;
}在 attemptAuthentication 方法代码的第 12 行，使用从 request 中获取到的用户名和密码，构建了一个 UsernamePasswordAuthenticationToken 对象，我们可以看到这个构造方法的代码，非常简单：
public UsernamePasswordAuthenticationToken(Object principal, Object credentials) {
super((Collection)null);
this.principal = principal;
this.credentials = credentials;
this.setAuthenticated(false);
}只是保存了用户名和密码的引用，并且将认证状态设置为 false，因为此时只是封装了认证信息，还没有进行认证。
我们再回到 attemptAuthentication 的代码，在方法的最后一行，将创建好的认证信息，传递给了一个 AuthenticationManager 进行认证。这里实际工作的是 AuthenticationManager 的实现类 ProviderManager。
查找处理认证的 Provider 类
进入 ProviderManager 可以从源码中找到 authenticate 方法，代码比较长，我就不贴在这里了，你可以自行查找，我简述一下代码中的逻辑。
ProviderManager 本身不执行认证操作，它管理着一个 AuthenticationProvider 列表，当需要对一个封装好的认证信息进行认证操作的时候，它会将认证信息和它管理者的 Provider 们，逐一进行匹配，找到合适的 Provider 处理认证的具体工作。
可以这样理解，ProviderManager 是一个管理者，管理着各种各样的 Provider。当有工作要做的时候，它从来都不亲自去做，而是把不同的工作，分配给不同的 Provider 去操作。
最后，它会将 Provider 的工作成果（已认证成功的信息）返回，或者抛出异常。
那么，它是怎么将一个认证信息交给合适的 Provider 的呢？
在上一部分中，我们说到，认证信息被封装成了一个 UsernamePasswordAuthenticationToken，它是Authentication 的子类，ProviderManager 会将这个认证信息的类型，传递个每个 Provider 的 supports 方法，由 Provider 来告诉 ProviderManager 它是不是支持这个类型的认证信息。
认证逻辑
在 Spring Security 内置的 Provider 中，与 UsernamePasswordAuthenticationToken 对应的 Provider 是 DaoAuthenticationProvider，authenticate 方法在它的父类 AbstractUserDetailsAuthenticationProvider 中。我们来看它的 authenticate 方法：
@Override
public Authentication authenticate ( Authentication authentication ) throws AuthenticationException {
Assert.isInstanceOf( UsernamePasswordAuthenticationToken.class, authentication,
() -> this.messages.getMessage ( "AbstractUserDetailsAuthenticationProvider.onlySupports",
"Only UsernamePasswordAuthenticationToken is supported" )) ;
String username = determineUsername ( authentication ) ;
boolean cacheWasUsed = true;
UserDetails user = this.userCache.getUserFromCache ( username ) ;
if ( user == null ) {
cacheWasUsed = false;
try {
user = retrieveUser ( username, ( UsernamePasswordAuthenticationToken ) authentication ) ;
}
catch ( UsernameNotFoundException ex ) {
this.logger.debug ( "Failed to find user '" + username + "'" ) ;
if ( !this.hideUserNotFoundExceptions ) {
throw ex;
}
throw new BadCredentialsException ( this.messages
.getMessage ( "AbstractUserDetailsAuthenticationProvider.badCredentials", "Bad credentials" )) ;
}
Assert.notNull( user, "retrieveUser returned null - a violation of the interface contract" ) ;
}
try {
this.preAuthenticationChecks.check ( user ) ;
additionalAuthenticationChecks ( user, ( UsernamePasswordAuthenticationToken ) authentication ) ;
}
catch ( AuthenticationException ex ) {
if ( !cacheWasUsed ) {
throw ex;
}
// 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 ) ;
this.preAuthenticationChecks.check ( user ) ;
additionalAuthenticationChecks ( user, ( UsernamePasswordAuthenticationToken ) authentication ) ;
}
this.postAuthenticationChecks.check ( user ) ;
if ( !cacheWasUsed ) {
this.userCache.putUserInCache ( user ) ;
}
Object principalToReturn = user;
if ( this.forcePrincipalAsString ) {
principalToReturn = user.getUsername () ;
}
return createSuccessAuthentication ( principalToReturn, authentication, user ) ;
}代码比较长，我们说要点：
- 代码第 12 行，通过
retrieveUser方法，获得UserDetails信息，这个方法的具体实现，可以在DaoAuthenticationProvider中找到，主要是通过UserDetailsService的loadUserByUsername方法，查找系统中的用户信息。 - 代码第 25 行，通过
preAuthenticationChecks.check方法，进行了认证前的一些校验。校验的具体实现可以在DefaultPreAuthenticationChecks内部类中找到，主要是判断用户是否锁定、是否可用、是否过期。 - 代码第 26 行，通过
additionalAuthenticationChecks方法，对用户名和密码进行了校验。具体实现可以在DaoAuthenticationProvider中找到。 - 代码第 39 行，通过
postAuthenticationChecks.check方法，校验了密码是否过期。具体实现可以在DefaultPostAuthenticationChecks内部类中找到。 - 最后，如果以上校验和认证都没有问题，则通过
createSuccessAuthentication方法，创建成功的认证信息，并返回。此时，就成功通过了认证。
在最后的 createSuccessAuthentication 方法中，会创建一个新的 UsernamePasswordAuthenticationToken 认证信息，这个新的认证信息的认证状态为 true。表示这是一个已经通过的认证。
这个认证信息会返回到 UsernamePasswordAuthenticationFilter 中，并作为 attemptAuthentication 方法的结果。
在 doFilter 方法中，会根据认证成功或失败的结果，调用相应的 Handler 类进行后续的处理，最后，认证的信息也会被保存在 SecurityContext 中，供后续使用。
总结
到此这篇关于Spring Security认证流程的文章就介绍到这了,更多相关Spring Security认证流程内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网！
