简介
Spring Security 对认证、授权和常见漏洞保护提供了全方位支持。
注：本篇博文使用的版本为：Spring Security 5.5.2
两个概念释义
-
认证（Authentication）：认证就是对试图访问资源的用户进行验证。
认证的一个典型的场景就是 登录 流程，常见的方式就是要求提供用户名和密码，当验证通过的时候，就可以执行授权操作。
授权（Authority）：授权就是对资源进行权限设置，只有用户具备相应权限才能访问。
简单来讲：
- 认证：你是谁？
- 授权：你能做什么？
架构总览
原理
Spring Security 在基于 Servlet应用 中，其底层是采用了Filter机制实现了对请求的认证、授权和漏洞防御等功能。
简单来说，我们可以为 Servlet 设置一些Filters，这些Filters 就构成了一个FilterChain。每次当请求进来时，首先会被FilterChain中的Filters 依次捕获得到，每个Filter可以对请求进行一些预处理或对响应进行一些后置处理，最后才会到达Servlet。具体流程如下图所示：
注：FilterChain中的Filter主要有两方面作用：
- 修改
HttpServletRequest或HttpServletResponse，这样FilterChain后续的Filters 或Servlet得到的就是被修改后的请求和响应内容。 -
Filter可以拦截请求，自己作出响应，相当于断开了FilterChain，导致后续的Filters和Servlet无法接收到该请求。
DelegatingFilterProxy
基于 Servlet 规范，我们可以为 Servlet容器 注入一些自定义Filters，但是在 Spring 应用中，实现了Filter接口的 Bean 无法被 Servlet容器 感知到，因为没有调用ServletContext#addFilter方法注册到FitlerChain中。为了解决这个问题，Spring 提供了一个DelegatingFilterProxy代理类，DelegatingFilterProxy实现了Filter，因此它可以被注入到FilterChain中，同时，当请求到来时，它会把请求转发到 Spring容器 中实现了Filter接口的 Bean 实体，所以DelegatingFilterProxy桥接了 Servlet容器 和 Spring容器。DelegatingFilterProxy作用示意图大致如下所示：
当请求到来时，DelegatingFilterProxy会从ApplicationContext中获取FilterBean 实体，然后将请求转发给到它，伪代码如下所示：
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
// Lazily get Filter that was registered as a Spring Bean
// For the example in DelegatingFilterProxy delegate is an instance of Bean Filter0
Filter delegate = getFilterBean(someBeanName);
// delegate work to the Spring Bean
delegate.doFilter(request, response);
}
FilterChainProxy
前面的步骤其实完成了 Spring容器 中的Filters Bean 实体可以注入到 Servlet容器 中的FilterChain功能，基于此，Spring Security 向 Spring容器 提供了一个FilterChainProxy Bean 实体，该FilterChainProxy实现了Filter接口，因此，请求就会被FilterChainProxy捕获到，这样 Spring Security 就可以开始工作了。具体来说，默认情况下，DelegatingFilterProxy从 Spring容器中 获取得到的就是FilterChainProxy实体，而FilterChainProxy也是一个代理类，它最终会将请求转发到 Spring Security 提供的SecurityFilterChain中。流程示意图如下所示：
注：FilterChainProxy就是 Spring Security 真正的入口起始点，调式代码时，将断点设置在FilterChainProxy#doFilter就可以追踪 Spring Security 完整调用流程。
SecurityFilterChain
SecurityFilterChain作用其实跟 Servlet 的FilterChain一样，同样维护了很多Filters，这些Filters 是由 Spring Security 提供的，每个 Security Filter 都有不同的职能，比如登录认证、CSRF防御...如下图所示：
同时，Spring Security 支持添加多个SecurityFilterChain，每个SecurityFilterChain负责不同的请求（比如依据请求地址进行区分），这样可以为不同的请求设置不同的认证规则。其源码如下所示：
public interface SecurityFilterChain {
// 匹配请求
boolean matches(HttpServletRequest request);
// 获取该 SecurityFilterChain 中的所有 Filter
List<Filter> getFilters();
}
具体来说，当请求到达FilterChainProxy时，其内部会根据当前请求匹配得到对应的SecurityFilterChain，然后将请求依次转发给到该SecurityFilterChain中的所有 Security Filters。如下图所示：
Security Filters
经过前面步骤介绍，我们知道，Spring Security 最终对请求进行处理的就是某个SecurityFilterChain中的 Security Filters，这些Fitlers 都设置为 Bean 注入到 Spring容器中，且这些Filters 的先后顺序很重要。以下是 Spring Security 内置的完整 Security Filter 顺序列表：
ChannelProcessingFilter：确保请求投递到要求渠道。最常见的使用场景就是指定哪些请求必须使用 HTTPS 协议，哪些请求必须使用 HTTP 协议，哪些请求随便使用哪种协议均可。-
WebAsyncManagerIntegrationFilter：集成SecurityContext到 Spring Web 异步请求机制中的WebAsyncManager。注：
SecurityContext就是 安全上下文，主要职能就是用于存储用户认证的一些信息。 -
SecurityContextPersistenceFilter：在每次请求处理之前，从 Session（默认使用HttpSessionSecurityContextRepository）中获取SecurityContext，然后将其设置给到SecurityContextHolder；在请求结束后，就会将SecurityContextHolder中存储的SecurityContext重新保存到 Session 中，并且清除SecurityContextHolder中的SecurityContext。SecurityContextPersistenceFilter可以通过HttpSecurity#securityContext()及相关方法引入其配置对象SecurityContextConfigurer来进行配置。 -
HeaderWriterFilter：该过滤器可为响应添加一些响应头，比如添加X-Frame-Options，X-XSS-Protection和X-Content-Type-Options等响应头，让浏览器开启保护功能。HeaderWriterFilter可以通过HttpSecurity#headers()来定制。 -
CorsFilter：处理跨域资源共享（CORS）。CorsFilter可以通过HttpSecurity#cors()来定制。 -
CsrfFilter：处理跨站请求伪造(CSRF)。CsrfFilter可以通过HttpSecurity#csrf()来开启或关闭。在前后端分离项目中，不需要使用 CSRF。 -
LogoutFilter：处理退出登录请求。LogoutFilter可以通过HttpSecurity#logout()来定制退出逻辑。 -
OAuth2AuthorizationRequestRedirectFilter：用于构建 OAuth 2.0 认证请求，将用户请求重定向到该认证请求接口。注：该过滤器需要添加
spring-security-oauth2等相关模块。 -
Saml2WebSsoAuthenticationRequestFilter：基于 SAML 的 SSO 单点登录认证请求过滤器。注：
Saml2WebSsoAuthenticationRequestFilter需要添加 Spring Security SAML 模块。 -
X509AuthenticationFilter：X509 认证过滤器。X509AuthenticationFilter可以通过SecurityContext#X509()来启用和配置相关功能。 -
AbstractPreAuthenticatedProcessingFilter：认证预处理请求过滤器基类，其中认证主体已经由外部系统进行了身份验证。目的只是从传入请求中提取主体上的必要信息，而不是对它们进行身份验证。可以继承该类进行具体实现并通过
HttpSecurity#addFilter方法来添加个性化的AbstractPreAuthenticatedProcessingFilter。 -
CasAuthenticationFilter：用于处理 CAS 单点登录认证。注：
CasAuthenticationFilter需要添加 Spring Security CAS 模块。 -
OAuth2LoginAuthenticationFilter：OAuth2.0 登录认证过滤器。注：
OAuth2LoginAuthenticationFilter需要添加spring-security-oauth2等相关模块。 -
Saml2WebSsoAuthenticationFilter：基于 SAML 的 SSO 单点登录认证过滤器。注：
Saml2WebSsoAuthenticationFilter需要添加 Spring Security SAML 模块。 -
UsernamePasswordAuthenticationFilter：用于处理表单登录认证。默认处理接口为/login，表单必须提供两个参数：用户名 和 密码，默认的参数名(key)为username和password，可以通过usernameParameter和passwordParameter方法进行修改。UsernamePasswordAuthenticationFilter可以通过HttpSecurity#formLogin()及相关方法引入其配置对象FormLoginConfigurer来进行配置。 OpenIDAuthenticationFilter：基于 OpenID 认证协议的认证过滤器。-
DefaultLoginPageGeneratingFilter：如果没有配置登录页面，那么就会默认采用该过滤器生成一个登录表单页面。注：默认的登录页面接口为
/login -
DefaultLogoutPageGeneratingFilter：生成默认退出登录页面。注：默认的退出登录页面接口为
/logout ConcurrentSessionFilter：主要用来判断 Session 是否过期以及更新最新访问时间。该过滤器可能会被多次执行。-
DigestAuthenticationFilter：用于处理 HTTP 头部显示的摘要式身份验证凭据。DigestAuthenticationFilter可以通过HttpSecurity#addFilter()来启用和配置相关功能。 BearerTokenAuthenticationFilter：处理 Token 认证。-
BasicAuthenticationFilter：用于检测和处理 Http Baisc 认证。BasicAuthenticationFilter可以通过HttpSecurity#httpBasic()及相关方法引入其配置对象HttpBaiscConfigurer来进行配置。 -
RequestCacheAwareFilter：用于用户认证成功后，重新恢复因为登录被打断的请求。当匿名访问一个需要授权的资源时。会跳转到认证处理逻辑，此时请求被缓存。在认证逻辑处理完毕后，从缓存中获取最开始的资源请求进行再次请求。RequestCacheAwareFilter可以通过HttpSecurity#requestCache()及相关方法引入其配置对象RequestCacheConfigurer来进行配置。 -
SecurityContextHolderAwareRequestFilter：对请求对象进行包装，增加了一些安全相关方法。SecurityContextHolderAwareRequestFilter可以通过HttpSecurity#servletApi()及相关方法引入其配置对象ServletApiConfigurer来进行配置。 JaasApiIntegrationFilter：适用于 JAAS （Java 认证授权服务）。如果SecurityContextHolder中拥有的Authentication是一个JaasAuthenticationToken，那么该JaasApiIntegrationFilter将使用包含在JaasAuthenticationToken中的Subject继续执行FilterChain。-
RememberMeAuthenticationFilter：当用户没有登录而直接访问资源时，从 cookie 里找出用户的信息，如果 Spring Security 能够识别出用户提供的 remember me cookie，用户将不必填写用户名和密码，而是直接登录进入系统。它先分析 SecurityContext 里有没有Authentication对象，如果有，则不做任何操作，直接跳到下一个过滤器；如果没有，则检查请求里有没有包含 remember-me 的 cookie 信息。如果有，则解析出 cookie 里的验证信息，判断是否有权限。RememberMeAuthenticationFilter可以通过HttpSecurity#rememberMe()及相关方法引入其配置对象RememberMeConfigurer来进行配置。 -
AnonymousAuthenticationFilter：匿名认证过滤器，检测SecurityContextHolder中是否存在Authentication对象，如果不存在，就生成一个匿名Authentication对象。AnonymousAuthenticationFilter可以通过HttpSecurity#anonymous()及相关方法引入其配置对象AnonymousConfigurer来进行配置。 OAuth2AuthorizationCodeGrantFilter：OAuth 2.0 授权码模式，用于处理 OAuth 2.0 授权码响应。-
SessionManagementFilter：检测用户是否通过认证，如果已认证，就通过SessionAuthenticationStrategy进行 Session 相关管理操作。SessionManagementFilter可以通过HttpSecurity#sessionManagement()及相关方法引入其配置对象SessionManagementConfigurer来进行配置。 ExceptionTranslationFilter：可以用于捕获FilterChain上所有的异常，但只处理AccessDeniedException和AuthenticationException异常。FilterSecurityInterceptor：对 web资源 进行一些安全保护操作。SwitchUserFilter：主要用来作用户切换。
自动配置
依据 Spring Boot 自动配置原理，其会自动加载spring-boot-autoconfigure.jar中/META-INF/spring.factories内键值org.springframework.boot.autoconfigure.EnableAutoConfiguration指定的自动配置类。查看该文件，可以看到，与 Spring Security 相关的自动配置类有如下几个：
org.springframework.boot.autoconfigure.security.servlet.SecurityAutoConfiguration, \
org.springframework.boot.autoconfigure.security.servlet.UserDetailsServiceAutoConfiguration, \
org.springframework.boot.autoconfigure.security.servlet.SecurityFilterAutoConfiguration, \
org.springframework.boot.autoconfigure.security.reactive.ReactiveSecurityAutoConfiguration, \
org.springframework.boot.autoconfigure.security.reactive.ReactiveUserDetailsServiceAutoConfiguration, \
org.springframework.boot.autoconfigure.security.rsocket.RSocketSecurityAutoConfiguration, \
org.springframework.boot.autoconfigure.security.saml2.Saml2RelyingPartyAutoConfiguration, \
org.springframework.boot.autoconfigure.security.oauth2.client.servlet.OAuth2ClientAutoConfiguration, \
org.springframework.boot.autoconfigure.security.oauth2.client.reactive.ReactiveOAuth2ClientAutoConfiguration, \
org.springframework.boot.autoconfigure.security.oauth2.resource.servlet.OAuth2ResourceServerAutoConfiguration, \
org.springframework.boot.autoconfigure.security.oauth2.resource.reactive.ReactiveOAuth2ResourceServerAutoConfiguration, \
每个配置类都为 Spring Security 注入不同的 Bean 到 Spring容器中。这里我们着重介绍一下SecurityFilterAutoConfiguration和SecurityAutoConfiguration配置类，因为这两个配置类会自动装配DelegatingFilterProxy和FilterChain到 Spring容器 中。具体如下：
自动装配FilterChainProxy
下面介绍下配置类SecurityAutoConfiguration，具体如下：
-
首先看下源码：
@Configuration(proxyBeanMethods = false) @ConditionalOnClass(DefaultAuthenticationEventPublisher.class) @EnableConfigurationProperties(SecurityProperties.class) @Import({ SpringBootWebSecurityConfiguration.class, WebSecurityEnablerConfiguration.class, SecurityDataConfiguration.class }) public class SecurityAutoConfiguration { @Bean @ConditionalOnMissingBean(AuthenticationEventPublisher.class) public DefaultAuthenticationEventPublisher authenticationEventPublisher(ApplicationEventPublisher publisher) { return new DefaultAuthenticationEventPublisher(publisher); } }SecurityAutoConfiguration导入了3个配置类，我们注重看WebSecurityEnablerConfiguration。 -
查看
WebSecurityEnablerConfiguration配置类，其源码如下：@Configuration(proxyBeanMethods = false) @ConditionalOnMissingBean(name = "springSecurityFilterChain") @ConditionalOnClass(EnableWebSecurity.class) @ConditionalOnWebApplication(type = ConditionalOnWebApplication.Type.SERVLET) @EnableWebSecurity class WebSecurityEnablerConfiguration { }当 Spring容器 中没有名称为
springSecurityFilterChain的 Bean 等条件时，就会加载该配置类，此时@EnableWebSecurity注解生效：@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) @Documented @Import({ WebSecurityConfiguration.class, SpringWebMvcImportSelector.class, OAuth2ImportSelector.class, HttpSecurityConfiguration.class }) @EnableGlobalAuthentication @Configuration public @interface EnableWebSecurity { boolean debug() default false; }注解
@EnableWebSecurity又导入了4个配置类，这里着重看下WebSecurityConfiguration：@Configuration(proxyBeanMethods = false) public class WebSecurityConfiguration implements ImportAware, BeanClassLoaderAware { ... /** * Creates the Spring Security Filter Chain * @return the {@link Filter} that represents the security filter chain * @throws Exception */ @Bean(name = "springSecurityFilterChain") public Filter springSecurityFilterChain() throws Exception { ... return this.webSecurity.build(); } ... }可以看到，
WebSecurityConfiguration#springSecurityFilterChain()最终生成了一个名称为springSecurityFilterChain的 Bean 实体，该 Bean 的实际类型其实为FilterChainProxy，是由WebSecurity#build()方法创建的。
综上，SecurityAutoConfiguration配置类生成了很多 Bean 实体，其中最重要的一个是名称为springSecurityFilterChain的FilterChainProxy对象。
自动装配DelegatingFilterProxy
下面介绍下配置类SecurityFilterAutoConfiguration，其源码如下所示：
@Configuration(proxyBeanMethods = false)
@ConditionalOnWebApplication(type = Type.SERVLET)
@EnableConfigurationProperties(SecurityProperties.class)
@ConditionalOnClass({ AbstractSecurityWebApplicationInitializer.class, SessionCreationPolicy.class })
@AutoConfigureAfter(SecurityAutoConfiguration.class) // 须先加载 SecurityAutoConfiguration
public class SecurityFilterAutoConfiguration {
...
@Bean
@ConditionalOnBean(name = “springSecurityFilterChain”)
public DelegatingFilterProxyRegistrationBean securityFilterChainRegistration(
SecurityProperties securityProperties) {
...
}
...
}
可以看到，要加载SecurityFilterAutoConfiguration前，必须先加载配置类SecurityAutoConfiguration，该配置类前面已经详细介绍了，主要功能就是注入了一个名称为springSecurityFilterChain的 Bean，因此，此时SecurityFilterAutoConfiguration#securityFilterChainRegistration就会生效，最终生成一个DelegatingFilterProxyRegistrationBean实体。DelegatingFilterProxyRegistrationBean实现了ServletContextInitializer接口，当系统执行ServletWebServerApplicationContext.selfInitialize()进行初始化时，会依次调用到：RegistrationBean.onStartup() --> DynamicRegistrationBean.register() --> AbstractFilterRegistrationBean.addRegistration()，其中，AbstractFilterRegistrationBean#addRegistration()源码如下：
protected Dynamic addRegistration(String description, ServletContext servletContext) {
Filter filter = this.getFilter();
return servletContext.addFilter(this.getOrDeduceName(filter), filter);
}
this.getFilter()实际调用的是DelegatingFilterProxyRegistrationBean#getFilter()方法，其内部会创建一个DelegatingFilterProxy实例并返回，源码如下：
public DelegatingFilterProxy getFilter() {
return new DelegatingFilterProxy(this.targetBeanName, this.getWebApplicationContext()) {
protected void initFilterBean() throws ServletException {
}
};
}
因此，AbstractFilterRegistrationBean#addRegistration()最终就是通过ServletContext#addFilter将一个DelegatingFilterProxy实例注入到 Servlet 的FilterChain中。
以上，就是 Spring Boot 中自动装配 Spring Security 相关配置源码分析，更加详细内容，可参考：
总结
总结一下，在 Servlet应用中，Spring Security 作用机制大致如下：
-
注册标准
Filter：首先，Spring 会自动注入一个DelegatingFilterProxy到 Servlet 的FilterChain中。 -
请求转发到 Spring Security：当请求到来时，
DelegatingFilterProxy就会自动在 Spring容器 中搜索名称为springSecurityFilterChain的Filter实体，其实际类型为FilterChainProxy。DelegatingFilterProxy最终会将请求转发给到FilterChainProxy。 -
找到匹配请求处理的
SecurityFilterChain：FilterChainProxy内部维护了一系列SecurityFilterChains，他会依据请求内容找到对应处理该请求的SecurityFilterChain。 -
请求处理：找到能处理请求的第一个
SecurityFilterChain后，就会遍历该SecurityFilterChain内部维护的一系列Filters，依次让这些 Security Filter 处理该请求，完成认证、授权等功能。
Spring Security 架构简单示意图如下所示：
基本使用
在 Spring Boot 中集成 Spring Security，只需导入如下依赖：
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
</dependencies>
无需其他操作，此时项目便已成功使能 Spring Security 提供的认证、授权、安全防护等功能。
默认情况下，Spring Security 采用 Http Basic 认证和表单认证，默认的用户名为user，密码打印在控制台，比如：
# 每次启动后台应用，都会生成一个随机密码
Using generated security password: 81a892eb-8191-45af-9bdb-4acd4f9c32e0
默认 SecurityFilterChain
前面内容有讲述，自动配置类SecurityAutoConfiguration会注入一个名称为springSecurityFilterChain的FilterChainProxyBean 实体到 Spring容器 中，实际上，该自动配置类还注入了一个SecurityFilterChainBean，源码追踪如下：
// org\springframework\boot\autoconfigure\security\servlet\SecurityAutoConfiguration.java
@Import({ SpringBootWebSecurityConfiguration.class, WebSecurityEnablerConfiguration.class,
SecurityDataConfiguration.class })
public class SecurityAutoConfiguration {
...
}
// org\springframework\boot\autoconfigure\security\servlet\SpringBootWebSecurityConfiguration.java
@Configuration(proxyBeanMethods = false)
@ConditionalOnDefaultWebSecurity
@ConditionalOnWebApplication(type = Type.SERVLET)
class SpringBootWebSecurityConfiguration {
@Bean
@Order(SecurityProperties.BASIC_AUTH_ORDER)
SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception {
// HTTP 请求配置
http.authorizeRequests().anyRequest().authenticated().and().formLogin().and().httpBasic();
return http.build();
}
}
具体负责自动注入的配置类是SpringBootWebSecurityConfiguration，其会向 Spring容器 注入一个名称为defaultSecurityFilterChain的SecurityFilterChainBean，这个 Bean 设置了默认的请求权限配置，即使用 Http Basic 认证方式，对所有的授权请求都要进行认证，前端认证会自动生成一个表单页面，供用户进行输入。
默认用户配置
Spring Secuirty 提供的默认用户是由配置类UserDetailsServiceAutoConfiguration自动装配的：
@Configuration(proxyBeanMethods = false)
...
public class UserDetailsServiceAutoConfiguration {
...
@Bean
@ConditionalOnMissingBean(
type = "org.springframework.security.oauth2.client.registration.ClientRegistrationRepository")
@Lazy
public InMemoryUserDetailsManager inMemoryUserDetailsManager(SecurityProperties properties,
ObjectProvider<PasswordEncoder> passwordEncoder) {
// 用户信息来自 SecurityProperties
SecurityProperties.User user = properties.getUser();
List<String> roles = user.getRoles();
return new InMemoryUserDetailsManager(
// 最后将 user 包装为一个 UserDetails
User.withUsername(user.getName()).password(getOrDeducePassword(user, passwordEncoder.getIfAvailable()))
.roles(StringUtils.toStringArray(roles)).build());
}
...
}
从源码可以看到，默认的用户信息来自SecurityProperties#getUser()方法，追踪源码如下：
@ConfigurationProperties(prefix = "spring.security")
public class SecurityProperties {
...
private final User user = new User();
public User getUser() {
return this.user;
}
...
public static class User {
// Default user name.
private String name = "user";
// Password for the default user name.
private String password = UUID.randomUUID().toString();
// Granted roles for the default user name.
private List<String> roles = new ArrayList<>();
...
}
}
可以看到，SecurityProperties会默认生成一个User，该User默认名为user，默认密码是一个随机UUID。
由于SecurityProperties被注解@ConfigurationProperties修饰，因此这里我们也可以通过外部配置文件修改默认用户信息，如下所示：
# application.properties
spring.security.user.name=whyn
spring.security.user.password=password
自定义配置入口
Spring Security 的自定义配置类入口是WebSecurityConfigurerAdapter，通常我们会自定义一个配置类，继承自WebSecurityConfigurerAdapter，然后覆写相应方法进行自定义配置，如下所示：
// Spring Security 自定义配置类
@Configuration
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {
// 认证管理器配置方法
@Override
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
super.configure(auth);
}
// 核心过滤器配置方法
@Override
public void configure(WebSecurity web) throws Exception {
super.configure(web);
}
// 安全过滤器链配置方法
@Override
protected void configure(HttpSecurity http) throws Exception {
super.configure(http);
}
}
WebSecurityConfigurerAdapter主要提供了三个配置方法：
configure(AuthenticationManagerBuilder auth)：认证管理器配置方法。主要用于配置认证管理器AuthenticationManager，使用参数AuthenticationManagerBuilder就可以构建出一个AuthenticationManager。简单来说，对于用户认证的地方就在这里配置，比如配置UserDetails、PasswordEncoder...-
configure(WebSecurity web)：核心过滤器配置方法。该方法主要用于配置WebSecurity。该接口平常使用不多，因为它不走 Spring Security 过滤器链，因此不具备状态维持，请求都是无状态的。通常我们都在这里配置放行静态资源，具体配置见下文内容。注：前文有提及，Spring Boot 中自动配置类
WebSecurityEnablerConfiguration最终就是通过WebSecurity#build()生成一个默认的名称为springSecurityFilterChain的FilterChainProxyBean，所以该方法主要就是用于配置springSecuritFilterChain这个FilterChainProxy。 -
configure(HttpSecurity http)：安全过滤器链配置方法。主要用来配置HttpSecurity。HttpSecurity提供了很多配置方法，绝大多数数情况下，我们都会在这里对请求进行自定义配置安全访问策略。注：前文有提及，Spring Boot 中自动配置类
SpringBootWebSecurityConfiguration最终就是通过HttpSecurity#build()生成一个默认的名称为defaultSecurityFilterChain的SecurityFilterChainBean，但是在我们自定义了WebSecurityConfigurerAdapter或SecurityFilterChain时，就不会使用默认生成的SecurityFilterChain，而是使用我们自定义的。无论哪种，最终都会将该SecurityFilterChainBean 注入到核心过滤器springSecuritFilterChain中。所以该方法主要就是用于配置SecurityFilterChain。
接口放行
Spring Security 提供了两种放行策略：
-
通过配置
WebSecurity，使用WebSecurity#ignoring()方法：@Override public void configure(WebSecurity web) throws Exception { web.ignoring().antMatchers("/css/**", "/js/**", "/index.html", "/img/**", "/fonts/**", "/favicon.ico", "/verifyCode"); }WebSecurity通常只用于配置放行静态资源，原因上文有提及。 -
通过配置
HttpSecurity，使用HttpSecurity#antMatcher/HttpSecurity#antMatchers方法：@Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() // 放行接口 login/**，/test/index .antMatchers("/login/**","/test/index").permitAll() // 其余所有请求都必须经过认证 .anyRequest().authenticated() .and() // 使用 HTTP Basic 认证 .httpBasic() .and() // 同时支持表单认证（Web端优先使用表单认证） .formLogin(); }注：
antMatchers中前缀 ant 是 Spring 参考的 apache ant 项目里的匹配风格！，简单来说，在 ant-style 中，存在如下几种匹配规则：-
?：匹配一个字符 -
*：匹配任意字符，所以，a/*/c可以匹配a/c、a/b/c、a/bd/c... -
**：匹配任意层级路径。a/**/c，可以匹配a/b/c、a/b/d/c... -
{spring:[a-z]+}：匹配路径变量spring满足正则表达式[a-z]+。比如，com/{filename:\\w+}.jsp可以匹配com/test.jsp，并且会将变量filename的值设为test。
注：Spring Security 的匹配规则是从上往下顺序匹配，一旦匹配到了就立即返回，因此
antMatchers(..)放行必须放置在认证authenticated()之前。现在我们就可以直接访问
/login及其子接口和/test/index接口，其余接口都需要先进行认证。如果想放行所有接口，可以配置如下：@Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests((request) -> request.anyRequest().permitAll()); } -
关于上述两种放行策略差别更详细分析，可参考：Spring Security 两种资源放行策略，千万别用错了！
用户与密码配置
前面我们提及，自动配置类UserDetailsServiceAutoConfiguration会为我们生成一个默认用户User，该用户默认名为user，默认密码是一个随机UUID，运行时会打印在控制台上。
我们也可以自己手动创建一个User，然后注入给 Spring Security。注入用户步骤如下：
-
创建一个用户，首先需要创建一个可以对密码进行加密和验证的
PasswordEncoder，其接口源码如下：public interface PasswordEncoder { // 加密 String encode(CharSequence rawPassword); // 验证 boolean matches(CharSequence rawPassword, String encodedPassword); // 对加密字符串再次进行加密，提高安全性。 // 一般设置为 false 即可，即无需二次加密 default boolean upgradeEncoding(String encodedPassword) { return false; } }Spring Security 内置了几种
PasswordEncoder，这里简单列举常见的几种：-
NoOpPasswordEncoder：明文存储密码。 -
BCryptPasswordEncoder：其使用 bcrypt 强哈希函数，且自带加盐处理，安全且方便。当前 Spring Security 官方推荐使用该种加密算法。 -
DelegatingPasswordEncoder：加密算法一直处于更新状态，我们永远不知道什么时候当前推荐的加密算法就不安全了。因此 Spring Security 官方提供了DelegatingPasswordEncoder，它可以确保一直使用最新的加密算法，并且兼容旧格式密码验证。
其余 Spring Security 提供的
PasswordEncoder，可参考官网：Password Storage综上，我们这里自定义一个配置类，注入一个
BCryptPasswordEncoder或者DelegatingPasswordEncoder：@Configuration public class SecurityPasswordEncoder { @Bean public PasswordEncoder passwordEncoder() { // return new BCryptPasswordEncoder(); return PasswordEncoderFactories.createDelegatingPasswordEncoder(); } } -
-
配置用户信息，并使用前面配置的
PasswordEncoder对密码进行加密：@Component public class SpringSecurityConfig extends WebSecurityConfigurerAdapter { @Autowired private PasswordEncoder passwordEncoder; @Override protected void configure(AuthenticationManagerBuilder auth) throws Exception { // 加密 String password = this.passwordEncoder.encode("123456"); // 内存用户 auth.inMemoryAuthentication() // 用户名 .withUser("whyn") // 密码 .password(password) // 权限 CRUD .authorities("Role_ADMIN",create","read","udpate","delete"); } }这里我们在内存中创建了一个用户，其名称为
whyn，密码为123456，角色是ADMIN，拥有create、read、update和delete权限。此时运行程序，页面表单输入用户名和密码就可以成功访问。
除了在内存中创建用户外，Spring Security 还支持从其他一些存储数据源中获取用户：
-
In-Memory Authentication：即用户信息存在在内存中。Spring Security 内置的
InMemoryUserDetailsManager实现了接口UserDetailsService，UserDetailsService可以通过用户名加载到相应的用户对象UserDetails，所以InMemoryUserDetailsManager可以在内存中加载用户对象。对于基于用户名/密码认证的简单场景，可以通过这种方式创建一个自定义用户
UserDetails，比如，前面的代码还可以更改为如下：@Configuration public class InMemoryUserDetailsServiceConfig { @Autowired private PasswordEncoder passwordEncoder; @Bean public UserDetailsService createUserDetailsService() { InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager(); // 创建 admin 用户 manager.createUser( User.withUsername("whyn") .password(this.passwordEncoder.encode("123456")) .roles("admin") .authorities("create", "read", "update", "delete") .build() ); // 创建 tourist 用户 manager.createUser( User.withUsername("tourist") .password(this.passwordEncoder.encode("guest")) .roles("tourist") .build()); return manager; } } JDBC Authentication：用户存储在关系型数据库。Spring Security 提供了
JdbcDaoImpl，它实现了UserDetailsService，可以从数据库中获取相应用户。LDAP Authentication：LDAP 是跨平台身份验证，通常用于作为用户信息存储的中央仓库，并提供认证服务。
-
UserDetailsService：
DaoAuthenticationProvider会从UserDetailsService中获取用户的名称、密码和其他一些属性用户认证。我们可以自定义一个UserDetailsService，自定义用户UserDetails加载逻辑：@Service public class CustomUserDetailsServiceImpl implements UserDetailsService { @Autowired private PasswordEncoder passwordEncoder; @Override public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException { return User.withUsername("custom") .password(this.passwordEncoder.encode("123456")) .roles("tourist") .build(); } } @Configuration public class SpringSecurityConfig extends WebSecurityConfigurerAdapter { @Autowired private PasswordEncoder passwordEncoder; @Autowired private UserDetailsService userDetailsService; @Override protected void configure(AuthenticationManagerBuilder auth) throws Exception { auth.authenticationProvider(daoAuthenticationProvider()); } // 自定义一个 DaoAuthenticationProvider，与我们自定义的 UserDetailsService 进行绑定 @Bean public DaoAuthenticationProvider daoAuthenticationProvider() { DaoAuthenticationProvider provider = new DaoAuthenticationProvider(); // 绑定到我们自定义的 UserDetailsService provider.setUserDetailsService(this.userDetailsService); provider.setPasswordEncoder(this.passwordEncoder); return provider; } }UserDetailsService的接口只有一个抽象方法loadUserByUsername，其根据用户名从存储系统中获取用户信息UserDetails，因此，自定义UserDetailsService形式非常灵活，我们可以自行选择加载用户的数据源，比如，可以从内存中获取，也可以从数据库中获取...
-
安全防护
Spring Security 提供了很多安全防护措施，其中一个主要的就是预防 CSRF 攻击。
- CSRF：跨站请求伪造（Cross Site Request Forgery），即在其他域网站在访问当前网站时，浏览器会自动将当前网站的 Cookie 携带上，这样服务器就会认为是已登录用户的正常请求，导致用户数据被窃取。
默认情况下，Spring Boot 与 Spring Security 整合后，会自动开启 CSRF 预防，此时只有 GET、OPTIONS、HEAD、TRACE、CONNECTION 可以访问，POST 等请求会被拒接，错误码为403。
如果集成 Spring Security 后，发现只有 GET 能请求，POST、PUT 等方法无法请求，那基本上就是因为开启了 CSRF 原因。
注：在前后端分离项目中，无需开启 CSRF，建议直接关闭即可：csrf().diable()
更多安全预防详情，可参考官网：Protection Against Exploits
常见认证机制
常见的认证机制主要有：HTTP Basic Auth、Session-Cookie Auth、Token Auth、OAuth2 和 SSO...
下面简单介绍下这几种认证机制，以及在 Spring Security 中使能这些机制。
HTTP Baisc Auth
HTTP Basic 是 HTTP 协议中内置的最古老，最基础的身份认证机制，简单来说，使用 HTTP Basic 认证，每次在请求 API 的时候，都需要携带用户的username和password。
在 Spring Security 中，开启 HTTP Basic 认证配置方式如下所示：
@Configuration
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
// 所有授权请求都必须先进行认证
http.authorizeRequests((request) -> request.anyRequest().authenticated());
// 开启 HTTP Basic 认证
http.httpBasic();
}
}
只需自定义一个配置类，然后通过HttpSecurity#httpBasic()方法开始 HTTP Baisc 认证机制即可。
假设现在我们有如下接口：
@RestController
@RequestMapping("/test")
public class TestApi {
@GetMapping("/index")
public String index() {
return "welcome to Spring Security!";
}
}
当我们在Web页（即网页端）端访问该接口时，浏览器就会弹出一个输入框，供用户输入用户名和密码，如下如所示：
这里我们直接在终端进行访问，查看下访问详情：
$ curl -X GET 'localhost:8080/test/index' --user 'user:3ee0747f-3c0a-49d4-a50d-f60cdab0c5a1' -v
* Server auth using Basic with user 'user'
> GET /test/basic-auth HTTP/1.1
> Authorization: Basic dXNlcjozZWUwNzQ3Zi0zYzBhLTQ5ZDQtYTUwZC1mNjBjZGFiMGM1YTE=
>
< HTTP/1.1 200
< Set-Cookie: JSESSIONID=60364574CA3BE7AF0530999009F3BDE3; Path=/; HttpOnly
welcome to Sprign Security!%
上述数据去除了一些不重要内容，可以看到，请求成功了，一个注意的点就是，每次使用 HTTP Basic 请求，都会在请求头携带上Authorization: Basic xxx，其中，xxx是对username:password进行 base64 编码后的值，我们对上述请求头Authorization进行解码，如下所示：
# 解码
$ echo -n 'dXNlcjozZWUwNzQ3Zi0zYzBhLTQ5ZDQtYTUwZC1mNjBjZGFiMGM1YTE=' | base64 --decode
user:3ee0747f-3c0a-49d4-a50d-f60cdab0c5a1%
# 编码，-n 必须加上，否则会添加一个换行符
$ echo -n 'user:3ee0747f-3c0a-49d4-a50d-f60cdab0c5a1' | base64
dXNlcjozZWUwNzQ3Zi0zYzBhLTQ5ZDQtYTUwZC1mNjBjZGFiMGM1YTE=
注：在 zsh 中，无换行会以 % 百分号结尾，在bash中，命令提示符会直接跟在输出结果的后面，而 zsh 会强制转换。
HTTP Basic 的优点就是简单，而缺点就是明文传输私密信息，非常不安全。如果一定要使用 HTTP Basic 机制，那么建议在 HTTPS 环境，起码增添了一层加密，提高安全性。
Session-Cookie Auth
Session-Cookie 是 Web端 用的比较多的认证机制，其实就是我们常说的表单认证，其认证流程为：第一次访问时，需要携带用户名和密码，服务端认证通过后，会将用户信息存储在一个 Session 中，然后将用户标识（通常为sessionId）下发给浏览器（通过Set-Cookie下发），后续该浏览器的其他请求，会自动携带身份标识 Cookie，服务器就可以认证通过，因此，Session-Cookie 是具备状态维护的。
注：对于 Session-Cookie 更详细介绍，可参考：简析 Cookie，Session 和 Token（JWT）
Spring Security 中配置 Session-Cookie 认证如下所示：
@Component
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
// 所有授权请求都必须先进行认证
http.authorizeRequests((request) -> request.anyRequest().authenticated());
// 开启表单认证
http.formLogin();
}
}
此时，当我们在浏览器输入localhost:8080/test/index时，就会重定向到localhost:8080/login页面，如下图所示：
输入用户名和密码就可以正常访问了。
注：Web端表单提交存在 CSRF 攻击漏洞，Spring Security 默认对 CSRF 攻击进行防御，其原理是在/login页面上的form表单上添加了一个隐式_csrf键值对，每次请求登录页面，Spring Security 都会生成一个随机的_csrftoken，这样只有在服务器端检测到该_csrf是合法时，才表示该次请求是合法请求。
而对于 Ajax 异步请求，前端就需要使用 JavaScritp 自己手动获取_csrftoken 并设置到请求头中。只要保证浏览器无法从 Cookie 中直接获取得到_csrf，那么就可以规避 CSRF 攻击。
Spring Seurity 中表单认证提供了很多配置细节，这里简单列举常用的一些配置：
-
自定义登录页面：默认情况下，Spring Security 生成的表单登录页面和登录接口都是
/login，即存在如下两个接口：- GET
http://localhost:8080/login：获取表单页面接口 - POST
http://localhost:8080/login：提交表单数据接口
要自定义登录页面，使用的是
FormLoginConfigurer#loginPage方法，要自定义表单提交接口，使用的是AbstractAuthenticationFilterConfigurer#loginProcessingUrl，具体配置步骤如下：- 首先配置 Spring Security，指定自定义登录页面和登录接口：
@Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() // 所有请求都要先认证 .anyRequest().authenticated() .and() // 启动表单验证 .formLogin(form -> // 登录页面，不拦截 form.loginPage("/login.html").permitAll() // 表单登录提交接口（无需定义 doLogin 接口） .loginProcessingUrl("/doLogin")) // 失能 CSRF .csrf().disable(); }
注：如果只配置了
loginPage，那么此时loginProcessingUrl等同于loginPage，即登录页面和登录接口一样。-
后端创建配置对应的登录接口：
@Controller public class LoginApi { // 登录页面接口 @GetMapping("/login.html") public String loginPage() { return "login"; }注：
loginProcessingUrl的作用是为了告诉UsernamePasswordAuthenticationFilter用户名和密码获取地址，自己项目中无需声明一个对应的Controller接口，声明了也没用，因为不会走自己定义的接口。
建议不要配置loginProcessingUrl，让他默认跟loginPage一致即可，免得搞乱自己。 -
导入模板引擎 Thymeleaf：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> -
创建登录页面：
resources/templates/login.html，内容如下：<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Custom Login Page</title> </head> <body> <form action="/doLogin" method="post"> <div> <!-- 用户名键值默认为 username --> <input type="text" name="username" placeholder="input username" required/> </div> <div> <!-- 密码键值默认为 password --> <input type="password" name="password" placeholder="input password" required/> </div> <input type="submit"> </form> </body> </html>注：表单中
action接口地址必须与loginProcessingUrl一致。
以上，便已完成配置。初次访问时，就会重定向到我们自定义登录界面
/login.html，认证成功后即可访问其余页面。 - GET
-
登录成功跳转：登录成功后，设置跳转页面，Spring Security 主要提供了三种配置方法：
-
successForwardUrl：登录成功后，一律跳转到指定位置，无论之前是访问哪个页面：protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .anyRequest().authenticated() .and() .csrf().disable() .formLogin() .successForwardUrl("/success"); } @Controller public class LoginApi { ... @PostMapping("/success") @ResponseBody public String loginSuccessForward() { return "login success"; } }注：
successForwardUrl采用服务端内部请求转发，因此跳转的接口方法要一致。比如表单登录使用的是Post方法，那么跳转接口也要支持Post请求。 -
defaultSuccessUrl：默认情况下，defaultSuccessUrl在登录成功后，会跳转会原先访问的页面。defaultSuccessUrl还有一个重载方法defaultSuccessUrl(String,boolean)，第二个参数默认值为fasle，如果设置为true，则其效果跟successForwardUrl一样：protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .anyRequest().authenticated() .and() .csrf().disable() .formLogin() .defaultSuccessUrl("/test/index"); }注：
defaultSuccessUrl在登录成功后，无论第二个参数是true还是fasle，采用的都是重定向跳转到指定页面。 -
successHandler：该方法可用于自定义登录成功处理器。当需要一些自定义操作跳转时，可以采用该方式。比如，我们自定义一个处理器，实现类似defaultSuccessUrl跳转功能：public class AuthenticationSuccessHandlerImpl implements AuthenticationSuccessHandler { private String url; // 请求缓存 private RequestCache requestCache = new HttpSessionRequestCache(); public AuthenticationSuccessHandlerImpl(String destUrl) { if (!UrlUtils.isValidRedirectUrl(destUrl)) { throw new RuntimeException(String.format("'%s' is not a valid URL", destUrl)); } this.url = destUrl; } @Override public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, Authentication authentication) throws IOException, ServletException { SavedRequest savedRequest = this.requestCache.getRequest(request, response); if (savedRequest == null) { response.sendRedirect(this.url); return; } // 目标URL，即登录页面前访问的 URL String targetUrl = savedRequest.getRedirectUrl(); response.sendRedirect(targetUrl); } }然后配置到表单选项上：
protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .anyRequest().authenticated() .and() .csrf().disable() .formLogin() .successHandler(new AuthenticationSuccessHandlerImpl("https://www.baidu.com")); }
实际使用中，
defaultSuccessUrl、successForwardUrl和successHandler只需配置一个即可，建议优先使用defaultSuccessUrl，需要自定义配置时使用successHandler。 -
-
失败登录跳转：对于失败登录跳转，Spring Security 同样提供了三种配置：
failureForwardUrl、failureUrl和failureHandler。注：
failureForwardUrl是基于服务器内转发，failureUrl是基于重定向（failureUrl配置后一直还会重定向到登录页面，原因目前未知-_-），failureHander可以实现自定义登录失败处理器。这里简单列举下
failureHander的配置方法：-
创建一个登录失败接口：
@Controller public class LoginApi { @RequestMapping("/failure.html") public String hahawaPage() { return "failure"; } } -
创建登录失败显示页面：
resources/templates/failure.html<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Failure</title> </head> <body> <span>登录是失败，请重新<a href="/login">登录</a></span> </body> </html> -
配置登录失败处理：
@Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers("/failure.html").permitAll() .anyRequest().authenticated() .and() .csrf().disable() .formLogin() .failureHandler(new AuthenticationFailureHandlerImpl("/failure.html")); // failure.html 需要支持 POST 请求 //.failureForwardUrl("/failure.html"); // .failureUrl("/failure.html"); }
-
-
表单参数：默认情况下，表单数据用户名默认名称为
username、密码默认名称为password，可以通过如下方法配置表单参数：protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests(request -> request.anyRequest().authenticated()) .formLogin((form) -> { // 设置登录页面，且不进行拦截 form.loginPage("/login.html").permitAll() // 配置用户名键值 .usernameParameter("name") // 配置密码键值 .passwordParameter("pwd"); }).csrf().disable(); }然后对于登陆页面
resources/templates/login.html，修改其 Form表单 中的登录参数：<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Custom Login Page</title> </head> <body> <form action="/login.html" method="post"> <div> <!-- 用户名键值默认为 username --> <input type="text" name="name" placeholder="input username" required/> </div> <div> <!-- 密码键值默认为 password --> <input type="password" name="pwd" placeholder="input password" required/> </div> <input type="submit"> </form> </body> </html> -
退出登录：Spring Security 提供的用户退出登录配置大致有如下：
protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .anyRequest().authenticated() .and() .csrf().disable() .formLogin() .and() .logout(logout -> { // doLogout 无需自己定义，可直接访问退出 logout.logoutUrl("/doLogout") // 修改注销 URL，可自定义请求方法... // logout.logoutRequestMatcher(new AntPathRequestMatcher("/doLogout","POST")); // 退出成功后跳转页面 .logoutSuccessUrl("/test/index").permitAll() // 清除 cookie .deleteCookies() // 清除认证消息 (默认使能） .clearAuthentication(true) // 清除 Session（默认使能） .invalidateHttpSession(true); }); }注：
logoutUrl可指定退出登录接口，我们无需自己在Controller内定义该接口，直接指定就可以使用。
logoutUrl和logoutRequestMatcher实际使用中任意设置一个即可。 -
Remember Me：Spring Security 支持 Remember Me 功能，其实就是给 Cookie 设置一个过期时间，这样浏览器就会持久化该 Cookie，在有效期间内就能一直起到登录作用。其配置方式大致如下：
protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .anyRequest().authenticated() .and() .formLogin() .and() .rememberMe(rememberMe -> { // 用于生成 token 的密钥 rememberMe.key("uniqueAndSecure") // 表单参数名称 .rememberMeParameter("remember-me") // Cookie 名称 .rememberMeCookieName("remember-me") // 过期时间，默认是 2周 .tokenValiditySeconds((int) TimeUnit.DAYS.toSeconds(2)); }); }以上配置后，登录页面就是多出一个
Remember Me的勾选框，其实就是添加了一个表单字段remember-me。
Session-Cookie 机制的优点是具备状态维持，缺点是由于移动端等缺省不直接支持 Cookie 机制，因此无法直接在移动端中使用，同时，由于 Session 集中存在在服务器端，限制了服务器的水平扩展能力。
由于 Session-Cookie 并不归属于 HTTP认证规范，因此它可以采用不同的实现机制。一个改进的方案就是将 Cookie 存放到本地存储仓库中，比如，浏览器将收到的 Cookie 存放到localStorage中，而移动端可以将 Cookie 存储到SharedPreferences或本地数据库中。每次请求时，就从本地仓库中获取到 Cookie（即sessionId），将其设置到请求头中或请求体中，由于数据不直接存放在 Cookie 中，因此浏览器端不存在 CSRF 风险。同时，服务器端可以将 Session 迁移到 Redis 等内存数据库中，将其作为 Session 共享服务器，速度快且一定程度上缓解了服务器水平扩展问题。
Token Auth
Token 是一种格式紧凑且具备自描述信息的安全认证机制，其存储了用户信息（明文）和对用户信息加密后生成的签名。其认证流程如下：
- 首次请求时，客户端会发送用户名和密码给到服务器，服务器认证通过后，会生成一个包含用户数据等信息的 Token，然后将该 Token 下发给客户端。
- 客户端收到 Token 后，将 Token 存储到本地存储仓库中，后续请求时，都要将该 Token 放置到请求头或请求体中。
- 服务器收到请求后，首先获取 Token，提取出用户信息和加密算法，结合自己的密钥对 Token 中的用户信息进行加密，得出签名，如果该签名与 Token 中的签名一样的话，说明用户信息没有被串改，认证成功。
注：对于 Token 更详细介绍，可参考：简析 Cookie，Session 和 Token（JWT）
在 Spring Security，配置 Token 认证方式的主要为如下两步：
-
下发 JWT Token：首次登录时，需要对用户身份进行验证，成功后生成一个 JWT token，下发给到客户端。
具体配置步骤如下所示：
-
导入依赖：当前主流的 token 实现格式为：JSON Web Token，这里我们采用 jjwt 库实现 jwt：
<dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.2</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-impl</artifactId> <version>0.11.2</version> <scope>runtime</scope> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-jackson</artifactId> <!-- or jjwt-gson if Gson is preferred --> <version>0.11.2</version> <scope>runtime</scope> </dependency> -
编写 Token 操作工具类：方便生成和解析 Token：
public class JwtTokenUtils { // 私钥 private static final String PRIVATE_SECRET_KEY = "this_is_private_secret_key"; // token 默认过期时间：14 天 private static final long TOKEN_EXPIRATION = TimeUnit.DAYS.toMillis(14); // 下发 token 增加前缀 public static final String TOKEN_PREFIX = "Bearer "; public static final String KEY_USER_NAME = "username"; public static final String KEY_USER_AUTHORITIES = "authorities"; // 解析 token public static Map<String, Object> parseToken(String token) { Map<String, Object> userDetails = new HashMap<>(); try { token = validateToken(token); Jws<Claims> claimsJws = Jwts.parserBuilder() .setSigningKey(getSecretKey()).build().parseClaimsJws(token); // 用户名 String username = claimsJws.getBody().getSubject(); // 用户权限 List<Map<String, String>> authorities = (List<Map<String, String>>) claimsJws.getBody().get(KEY_USER_AUTHORITIES); Collection<? extends GrantedAuthority> userAuthorities = authorities.stream() .map(item -> new SimpleGrantedAuthority(item.get("authority"))) .collect(Collectors.toSet()); userDetails.put(KEY_USER_NAME, username); userDetails.put(KEY_USER_AUTHORITIES, userAuthorities); return userDetails; } catch (JwtException e) { throw new IllegalStateException(String.format("invalid token: %s", token)); } } // 生成token public static String generateToken(String username) { String token = Jwts.builder() .setSubject(username) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + TOKEN_EXPIRATION)) .signWith(getSecretKey()) .compact(); return generateTokenWithPrefix(token); } // 生成 token，包含用户主体和其权限 public static String generateToken(String username, Object authorities) { String token = Jwts.builder() // 用户名 .setSubject(username) // payload .claim(KEY_USER_AUTHORITIES, authorities) // 发行时间 .setIssuedAt(new Date()) // 过期时间 .setExpiration(new Date(System.currentTimeMillis() + TOKEN_EXPIRATION)) // 私钥 .signWith(getSecretKey()) .compact(); return generateTokenWithPrefix(token); } // token 添加前缀 Bearer private static String generateTokenWithPrefix(final String token) { return TOKEN_PREFIX + token; } // 生成签名私钥 private static Key getSecretKey() { return Keys.hmacShaKeyFor(generateSecretKey()); } // 加密要求至少 256 位，因此将私钥进行 sha256，只是单纯为了生存 256 个字节 private static byte[] generateSecretKey() { byte[] hashKey = null; try { MessageDigest digest = MessageDigest.getInstance("SHA-256"); hashKey = digest.digest(PRIVATE_SECRET_KEY.getBytes(StandardCharsets.UTF_8)); } catch (NoSuchAlgorithmException e) { hashKey = fillBytes(PRIVATE_SECRET_KEY); } return hashKey; } // 循环字符串添加到 256 个字节 private static byte[] fillBytes(String str) { if (str == null) { str = PRIVATE_SECRET_KEY; } byte[] bytes256 = new byte[256]; int length = str.length(); for (int i = 0; i < 256; ++i) { // 忽视精度缺失，只是为了添加到 256 个字节 bytes256[i] = (byte) str.charAt(i % length); } return bytes256; } // 去除 token 前缀：Bearer private static String validateToken(String token) { String rawToken = token; if (rawToken.startsWith(TOKEN_PREFIX)) { rawToken = rawToken.substring(TOKEN_PREFIX.length()); } return rawToken; } }注：上面的 Token 工具类内部硬编码了一些常量，这些自定义常量其实也可以通过配置文件进行配置，比如，以下定义了一个配置类：
@ConfigurationProperties(prefix = "jwt.token") public class JwtTokenProperty { private String secretKey; private long expiration; private String tokenPrefix; // getters // setters }配置类
JwtTokenProperty可以从配置文件application.yml中读取前缀为jwt.token的配置选项：jwt: token: # 密钥 secretKey: "this_is_private_secret_key" # 过期时间 14 天 # jshell> TimeUnit.DAYS.toMillis(14); # $1 ==> 1209600000 expiration: 1209600000 # token 前缀 tokenPrefix: Bearer按上述配置，当程序运行时，
JwtTokenProperty内部属性就会自动被赋予配置文件中定义的值，灵活度更高。最后，要让配置类生效，还需显示使用注解
@EnableConfigurationProperties进行使能：@SpringBootApplication // 使能配置类 @EnableConfigurationProperties({JwtTokenProperty.class}) public class SpringSecurityDemoApplication { ... } -
自定义验证过滤器：我们知道，在 Spring Security 中，负责验证用户登录的是
UsernamePasswordAuthenticationFilter，但是它无法对 JSON 数据进行校验，因此，这里我们可以基于它实现一个可以识别并验证 JSON 数据登录请求：public class JwtTokenUsernamePasswordAuthenticationFilter extends UsernamePasswordAuthenticationFilter { private final AuthenticationManager authenticationManager; public JwtTokenUsernamePasswordAuthenticationFilter(AuthenticationManager authenticationManager) { this.authenticationManager = authenticationManager; } @Override public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response) throws AuthenticationException { try { // 获取请求参数 Map<String, String> userMap = new ObjectMapper().readValue( request.getInputStream(), Map.class); // 获取用户名 String username = userMap.get(this.getUsernameParameter()); // 获取用户密码 String password = userMap.get(this.getPasswordParameter()); // 包装为一个 Authentication 对象，方便后面给 AuthenticationManager 进行验证 UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(username, password); // Allow subclasses to set the "details" property this.setDetails(request, authentication); // 进行验证 return this.authenticationManager.authenticate(authentication); } catch (Exception e) { throw new AuthenticationServiceException("用户名或密码错误，认证失败!"); } } @Override // 认证成功 protected void successfulAuthentication(HttpServletRequest request, HttpServletResponse response, FilterChain chain, Authentication authResult) throws IOException, ServletException { // 生成 token String token = JwtTokenUtils.generateToken(authResult.getName(), authResult.getAuthorities()); // 下发 token response.addHeader("Authorization", token); response.setCharacterEncoding("utf-8"); response.getWriter().print("登录成功"); } @Override // 认证失败 protected void unsuccessfulAuthentication(HttpServletRequest request, HttpServletResponse response, AuthenticationException failed) throws IOException, ServletException { SecurityContextHolder.clearContext(); response.setCharacterEncoding("utf-8"); response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.getWriter().print(failed.getMessage()); } }注：因为 Token Auth 常用于前后端分离项目，前后端基本上都是通过 JSON 数据进行通信，包含登录等操作，因此这里我们自定义
JwtTokenUsernamePasswordAuthenticationFilter支持 JSON 格式登录验证，并且验证成功后会生成一个 JWT token，放置在响应头Authorization中，客户端只需提取出该 JWT token，后续请求时携带上即可访问服务器上的资源。 -
注册到
SecurityFilterChain：最后还需要将自定义的JwtTokenUsernamePasswordAuthenticationFilter注册到 Spring Security 的SecurityFilterChain中，让其生效：@Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests(request -> request.anyRequest().authenticated()) // 关闭 CSRF 预防 .csrf(csrf -> csrf.disable()) .sessionManagement(sessionManager -> // 无需创建 Session sessionManager.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) // 添加自定义 token 认证过滤器（下发 token） .addFilter(new JwtTokenUsernamePasswordAuthenticationFilter( this.authenticationManager())); }
此时，项目就具备下发 token 能力了，我们进行登录，查看下效果：
$ curl -X POST 'localhost:8080/login' --header 'Content-Type: application/json; charset=utf-8' --data '{"username":"admin","password":"admin_password"}' -v > POST /login HTTP/1.1 > Content-Type: application/json; charset=utf-8 > Content-Length: 48 > < HTTP/1.1 200 < Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImF1dGhvcml0aWVzIjpbeyJhdXRob3JpdHkiOiJjcmVhdGUifSx7ImF1dGhvcml0eSI6ImRlbGV0ZSJ9LHsiYXV0aG9yaXR5IjoicmVhZCJ9LHsiYXV0aG9yaXR5IjoidXBkYXRlIn1dLCJpYXQiOjE2MzM5NzMwOTgsImV4cCI6MTYzNTE4MjY5OH0.lzdNOz2nIGZi4sJYgaJ7AFVKmA_PlyCd-HcTY7JDotA可以看到，我们通过 JSON 进行登录，服务区验证通过后，成功下发了一个 token，将该 token 复制到 JWT 官网上，可以查看该 token 携带的信息，如下图所示：
JSON Web Token -
-
验证 JWT Token：前面步骤完成了登录下发 JWT token，后续客户端每次请求时，都会携带该 token，因此我们需要对该 token 进行验证，成功则允许其访问资源。
具体配置步骤如下：
-
自定义 token 验证过滤器：需要自定义一个过滤器，对每次请求，将其 token 截取出来，并进行认证：
// OncePerReequestFilter 可以确保单次请求只会执行一次 Filter public class JwtTokenVerifyFilter extends OncePerRequestFilter { @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token = request.getHeader("Authorization"); if (null != token && token.startsWith(JwtTokenUtils.TOKEN_PREFIX)) { Map<String, Object> userDetails = JwtTokenUtils.parseToken(token); String username = (String) userDetails.get(JwtTokenUtils.KEY_USER_NAME); Collection<? extends GrantedAuthority> authorities = (Collection<? extends GrantedAuthority>) userDetails.get(JwtTokenUtils.KEY_USER_AUTHORITIES); // 将 token 提取出来的用户信息封装到 Authentication 中 Authentication authentication = new UsernamePasswordAuthenticationToken( username, // principal 用户名 null, // credentials 密码无法获取，直接置为空即可 authorities); // 认证成功，直接设置到 SecurityContextHolder 中，供后续 Filters 使用 SecurityContextHolder.getContext().setAuthentication(authentication); } filterChain.doFilter(request, response); } } -
注册到
SecurityFilterChain：将自定义的JwtTokenVerifyFilter注册到SecurityFilterChain中，且该Filter要在JwtTokenUsernamePasswordAuthenticationFilter后面，因为登录在先（生成 token），后续才是请求处理（验证 token）：protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests(request -> request.anyRequest().authenticated()) .csrf(csrf -> csrf.disable()) .sessionManagement(sessionManager -> sessionManager.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .addFilter(new JwtTokenUsernamePasswordAuthenticationFilter( this.authenticationManager())) // 添加自定义 token 提取过滤器（提取并认证） .addFilterAfter(new JwtTokenVerifyFilter(), JwtTokenUsernamePasswordAuthenticationFilter.class); }
此时，我们就能对 JWT token 进行校验，校验通过则允许用户访问对应资源。比如，我们拿上面生成的 token，访问服务器资源，效果如下：
$ curl -X GET 'localhost:8080/user' --header 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImF1dGhvcml0aWVzIjpbeyJhdXRob3JpdHkiOiJjcmVhdGUifSx7ImF1dGhvcml0eSI6ImRlbGV0ZSJ9LHsiYXV0aG9yaXR5IjoicmVhZCJ9LHsiYXV0aG9yaXR5IjoidXBkYXRlIn1dLCJpYXQiOjE2MzM5NzMwOTgsImV4cCI6MTYzNTE4MjY5OH0.lzdNOz2nIGZi4sJYgaJ7AFVKmA_PlyCd-HcTY7JDotA' ["David","Roy","Linda"]%可以看到，访问成功。
以上，便完成了 Spring Security Token 认证配置。
注：如果想了解 Spring Security 认证和授权具体流程，可参考：
-
最后，Token 认证机制是对 Session 机制的一种改进做法，其优点如下：
-
规避 CSRF 攻击：Token 存储在客户端本地存储系统中，比如 Web端将 Token 存储到
localStorage中（不要直接存储在 Cookie 中），从根本上规避了 CSRF 攻击。 - 可扩展性：相对于 Session 将用户信息保存到服务器中，Token 是将用户信息存储到客户端中，其由于其具备自验证功能，因此服务端无需存储用户状态，服务端可以轻松进行水平扩展。
- 丰富客户端类型：Session-Cookie 机制主要用于 Web端，限制了移动等原生客户端类型，而 Token 独立存在，只需请求时携带即可，对客户端类型没有限制。
Token 的缺点主要有两点：
- 体积大：由于用户信息都存储在 Token 中，因此 Token 字符串本身比较大。
- 无法回收 Token 权限：由于 Token 具备自验证功能，因此在生效时间内，就一直有效。典型的场景就是我们无法直接强制用户下线。
OAuth
OAuth，即 Open Authrization(（开放授权），它为用户资源的授权提供了一个安全的、开放而又简易的标准，允许用户让第三方应用访问用户存储在其他服务器上的私密资源，而无需将用户名和密码提供给第三方应用。
OAuth协议 有 1.0 和 2.0 两个版本，但 OAuth1.0 存在许多安全漏洞，因此在 OAuth2.0 里面完全废弃了 OAuth1.0，且 OAuth2.0 整个授权验证流程更简单更安全。
OAuth 是一个开放的协议，任何服务提供商（私密资源服务器）都可以提供 OAuth 服务（开放 API），任何第三方都可以接入并使用 OAuth 认证服务。国内常见的提供 OAuth 认证服务的厂商有：微信、微博、支付宝...
常用于第三方登录场景，比如微信，微博登录。
OAuth 交互具体流程，可参考：几种常用的Web安全认证方式
::to be continued
SSO
SSO，即 单点登录（Single Sign On），指的是在公司内容搭建一个公共的认证中心，公司下的所有产品的登录都可以在认证中心里完成，一个产品在认证中心登录后，再去访问另一个产品，可以不用再次登录，即可获取登录状态。
SSO 单点登录比较适合中大型企业，内部拥有多个产品，可以实现统一登录逻辑。
OAuth第三方登录 是 SSO单点登录 的一种形式，其公共的认证中心是由第三方平台提供。中小公司可以借助这些大厂提供的第三方登录服务，完成登录流程。
SSO 交互具体流程，可参考：4种常规的登录认证方式
::to be continued
授权
当用户认证通过后，需要访问某些资源时，就可以进行授权操作。Spring Security 对用户授权组织模型为：角色（role） + 权限（authority）。
-
角色：可设置拥有某种角色的用户可访问某一类资源。
举个例子：比如角色为
USER的用户可以访问/user/**接口，角色为ADMIN的用户可以访问接口/admin/**和/user/**接口。具体配置步骤如下：-
首先创建对应角色的用户：
@Configuration public class SpringSecurityConfig extends WebSecurityConfigurerAdapter { @Autowired private PasswordEncoder passwordEncoder; @Override @Bean protected UserDetailsService userDetailsService() { // 管理员 UserDetails adminUser = User.withUsername("admin") .password(this.passwordEncoder.encode("admin_password")) .roles("ADMIN") // ROLE_ADMIN .build(); // 普通用户 UserDetails normalUser = User.builder() .username("user") .password(this.passwordEncoder.encode("user_password")) .roles("USER") // ROLE_USER .build(); return new InMemoryUserDetailsManager(adminUser, normalUser); } }上述代码在内存中创建了两个用户：
admin和user，其中，admin角色为ADMIN，user角色为USER。 -
创建相应接口，区分用户使用：
// 管理员接口：/admin/** @RestController @RequestMapping("/admin") public class AdminApi { @GetMapping public String showUserDetails() { // 返回用户详细信息 return SecurityContextHolder.getContext().getAuthentication().getPrincipal().toString(); } } // 普通用户接口：/user/** @RestController @RequestMapping("user") public class UserApi { private List<String> users = Arrays.asList("David", "Roy", "Linda"); @GetMapping public List<String> getUsers() { return this.users; } } -
配置 Spring Security，对不同角色的用户指定不同的资源访问权限：
@Configuration public class SpringSecurityConfig extends WebSecurityConfigurerAdapter { @Override @Bean protected UserDetailsService userDetailsService() { ... } @Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() // 角色为 ADMIN 的用户才能访问接口 /admin/** .antMatchers("/admin/**").hasRole("ADMIN") // 角色为 ADMIN 和 USER 的用户都可以访问接口 /user/** .antMatchers("/user/**").hasAnyRole("ADMIN", "USER") .anyRequest().authenticated() .and() // HTTP Basic 认证 .httpBasic(); } }
以上，我们就配置了相应角色的用户访问不同资源的权限，这里我们在终端进行访问，如下所示：
# user 可以访问 /user/** $ curl -X GET 'localhost:8080/user' --user 'user:user_password' ["David","Roy","Linda"]% # user 不能访问 /admin/**，因为 user 没有 ADMIN 角色 $ curl -X GET 'localhost:8080/admin' --user 'user:user_password' {"timestamp":"2021-10-10T08:21:59.815+00:00","status":403,"error":"Forbidden","path":"/admin"}% # admin 可以访问 /user/** $ curl -X GET 'localhost:8080/user' --user 'admin:admin_password' ["David","Roy","Linda"]% # admin 可以访问 /admin/**，因为有 ADMIN 角色 $ curl -X GET 'localhost:8080/admin' --user 'admin:admin_password' org.springframework.security.core.userdetails.User [Username=admin, Password=[PROTECTED], Enabled=true, AccountNonExpired=true, credentialsNonExpired=true, AccountNonLocked=true, Granted Authorities=[ROLE_ADMIN]]%上面例子中，
ADMIN权限显然包含USER权限，因此我们上面在配置访问/user/**接口时，使用的是hasAnyRole("ADMIN","USER")，即只有用户角色是ADMIN或者USER其中一个即可访问，但是这里不能体现包含关系，此时可以使用 角色继承，让上级角色自动具备下级角色所有权限，因此这里我们可以配置ADMIN包含USER权限，如下所示：@Configuration public class SpringSecurityConfig extends WebSecurityConfigurerAdapter { // 角色继承 @Bean RoleHierarchy roleHierarchy() { RoleHierarchyImpl hierarchy = new RoleHierarchyImpl(); hierarchy.setHierarchy("ROLE_ADMIN > ROLE_USER"); return hierarchy; } @Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers("/admin/**").hasRole("ADMIN") // USER 能访问的，ADMIN 就可以访问 .antMatchers("/user/**").hasRole("USER") .anyRequest().authenticated() .and() .httpBasic(); } } -
-
权限：某些资源可以设置为具备特定权限的用户才能访问。
举个例子：比如员工系统中，拥有
read权限的用户可以读取员工资料，拥有write或create或delete权限的用户可以读取和修改员工资料，配置步骤如下：-
创建对应用户权限：
@Configuration public class SpringSecurityConfig extends WebSecurityConfigurerAdapter { @Autowired private PasswordEncoder passwordEncoder; @Override @Bean protected UserDetailsService userDetailsService() { // 管理员 UserDetails adminUser = User.withUsername("admin") .password(this.passwordEncoder.encode("admin_password")) // 权限 .authorities("create", "read", "update", "delete") .build(); // 普通用户 UserDetails normalUser = User.builder() .username("user") .password(this.passwordEncoder.encode("user_password")) // 权限 .authorities("read") .build(); return new InMemoryUserDetailsManager(adminUser, normalUser); } }上述代码为用户
admin添加了create、read、update和delete权限，为用户user添加了只读权限read。 -
创建员工资料访问接口：
@RestController @RequestMapping("user") public class UserApi { // 模拟数据库 private List<String> users = Stream.of("David","Roy","Linda").collect(Collectors.toList()); @GetMapping public List<String> getUsers() { return this.users; } @GetMapping("/{userId}") public String getUser(@PathVariable("userId") Integer userId) { return this.users.get(userId); } @PostMapping public List<String> createUser(@RequestParam("name") String username) { System.out.println("username = " + username); this.users.add(username); return this.users; } @PutMapping("/{userId}") public String updateUser(@PathVariable("userId") Integer userId) { return this.users.get(userId) + " update successfully!"; } @DeleteMapping("/{userId}") public String removeUser(@PathVariable("userId") Integer userId) { String oldUser = this.users.remove(userId.intValue()); return String.format("delete %s successfully！", oldUser); } }上述的
UserApi是遵循 Restful 风格的 API，模拟了对员工数据的增、删、改、查操作。 -
配置 Spring Security：
@Configuration public class SpringSecurityConfig extends WebSecurityConfigurerAdapter { @Override @Bean protected UserDetailsService userDetailsService() { ... } @Override protected void configure(HttpSecurity http) throws Exception { // 关闭 CSRF http.csrf().disable() .authorizeRequests() // 拥有 create，或者 update，或者 delete 权限就可以访问 /admin/** .antMatchers("/admin/**").hasAnyAuthority("create", "update", "delete") // 只有拥有 read 权限才能访问：GET /user/** .antMatchers(HttpMethod.GET, "/user/**").hasAuthority("read") // 只有拥有 create 权限才能上传用户： POST /user/** .antMatchers(HttpMethod.POST,"/user/**").hasAuthority("create") // 只有拥有 update 权限才能更新用户： PUT /user/** .antMatchers(HttpMethod.PUT,"/user/**").hasAuthority("update") // 只有拥有 delete 权限才能删除用户： DELETE /user/** .antMatchers(HttpMethod.DELETE,"/user/**").hasAuthority("delete") .anyRequest().authenticated() .and() .httpBasic(); } }上述代码配置了
admin用户具备/user/**和/admin/**的完全访问权限，而用户user的权限只能读取/user/**：# user用户可读，因为具备 read 权限 $ curl -X GET 'localhost:8080/user' --user 'user:user_password' ["David","Roy","Linda"]% # user用户不可写 $ curl -X POST 'localhost:8080/user' --data 'name=whyn' --user 'user:user_password' {"timestamp":"2021-10-10T11:02:57.644+00:00","status":403,"error":"Forbidden","path":"/user"}% # admin用户可读，因为具备 read 权限 $ curl -X GET 'localhost:8080/user' --user 'admin:admin_password' ["David","Roy","Linda"]% # admin用户可写，因为具备 write 权限 $ curl -X POST 'localhost:8080/user' --user 'admin:admin_password' --data 'name=whyn' ["David","Roy","Linda","whyn"]% # admin用户可修改，因为具备 update 权限 $ curl -X PUT 'localhost:8080/user/1' --user 'admin:admin_password' Roy update successfully!% # admin用户可删除，因为具备 delete 权限 $ curl -X DELETE 'localhost:8080/user/0' --user 'admin:admin_password' delete David successfully！%
-
最后，Spring Security 中的角色role和权限authority底层实现上其实是一样的，源码如下所示：
// org\springframework\security\core\userdetails\User.java
public UserBuilder roles(String... roles) {
List<GrantedAuthority> authorities = new ArrayList<>(roles.length);
for (String role : roles) {
Assert.isTrue(!role.startsWith("ROLE_"),
() -> role + " cannot start with ROLE_ (it is automatically added)");
// role 会添加前缀 ROLE_
authorities.add(new SimpleGrantedAuthority("ROLE_" + role));
}
return authorities(authorities);
}
public UserBuilder authorities(String... authorities) {
return authorities(AuthorityUtils.createAuthorityList(authorities));
}
可以看到，本质上role就是authority，只是存储的时候增加了前缀ROLE_。
注：这里有一个点需要注意，否则有大坑，User#hasRole和User#authorities内部最终都调用了方法User#authorities(Collection)，其源码如下：
// org\springframework\security\core\userdetails\User.java
public UserBuilder authorities(Collection<? extends GrantedAuthority> authorities) {
// 更改指向
this.authorities = new ArrayList<>(authorities);
return this;
}
可以看到，User#authorities(Collection)内部会创建一个新的权限集合，赋值给User.authorities，所以，创建自定义用户时，不能同时使用User#roles和User#authorities，否则会导致相互覆盖，比如，User.builder().roles("xxx").authorities("yyy")，后面的yyy会覆盖掉xxx，导致实际上没有声明角色。如果要同时声明角色和权限，那么建议使用User#authorities方法，然后手动为角色添加前缀ROLE_即可，比如：
# 声明了角色 xxx 和权限 yyy
User.builder().authorities(“ROLE_xxx","yyy")
参考
附录
- 本篇博文所有例子源码可查看：Spring Security Demos
