Spring Boot - 集成 Spring Security

Spring Security

简介

Spring Security 对认证、授权和常见漏洞保护提供了全方位支持。

注：本篇博文使用的版本为：Spring Security 5.5.2

两个概念释义

认证（Authentication）：认证就是对试图访问资源的用户进行验证。

认证的一个典型的场景就是登录流程，常见的方式就是要求提供用户名和密码，当验证通过的时候，就可以执行授权操作。
授权（Authority）：授权就是对资源进行权限设置，只有用户具备相应权限才能访问。

简单来讲：

认证：你是谁？
授权：你能做什么？

架构总览

原理

Spring Security 在基于 Servlet应用中，其底层是采用了Filter机制实现了对请求的认证、授权和漏洞防御等功能。

简单来说，我们可以为 Servlet 设置一些Filters，这些Filters 就构成了一个FilterChain。每次当请求进来时，首先会被FilterChain中的Filters 依次捕获得到，每个Filter可以对请求进行一些预处理或对响应进行一些后置处理，最后才会到达Servlet。具体流程如下图所示：

FilterChain

注：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

当请求到来时，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

注：FilterChainProxy就是 Spring Security 真正的入口起始点，调式代码时，将断点设置在FilterChainProxy#doFilter就可以追踪 Spring Security 完整调用流程。

SecurityFilterChain

SecurityFilterChain作用其实跟 Servlet 的FilterChain一样，同样维护了很多Filters，这些Filters 是由 Spring Security 提供的，每个 Security Filter 都有不同的职能，比如登录认证、CSRF防御...如下图所示：

SecurityFilterChain

同时，Spring Security 支持添加多个SecurityFilterChain，每个SecurityFilterChain负责不同的请求（比如依据请求地址进行区分），这样可以为不同的请求设置不同的认证规则。其源码如下所示：

public interface SecurityFilterChain {
    // 匹配请求
    boolean matches(HttpServletRequest request);

    // 获取该 SecurityFilterChain 中的所有 Filter
    List getFilters();
}

具体来说，当请求到达FilterChainProxy时，其内部会根据当前请求匹配得到对应的SecurityFilterChain，然后将请求依次转发给到该SecurityFilterChain中的所有 Security Filters。如下图所示：

Multiple SecurityFilterChain

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 相关配置源码分析，更加详细内容，可参考：

Spring Boot 自动装配 Spring Security 详解
深入浅出Spring Security（二）：FilterChainProxy的创建过程

总结

总结一下，在 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 Security structure

基本使用

在 Spring Boot 中集成 Spring Security，只需导入如下依赖：


    
        org.springframework.boot
        spring-boot-starter-security

无需其他操作，此时项目便已成功使能 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) {
        // 用户信息来自 SecurityProperties
        SecurityProperties.User user = properties.getUser();
        List 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 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页（即网页端）端访问该接口时，浏览器就会弹出一个输入框，供用户输入用户名和密码，如下如所示：

Http Basic Auth

这里我们直接在终端进行访问，查看下访问详情：

$ 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页面，如下图所示：

Form 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，具体配置步骤如下：
1. 首先配置 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，即登录页面和登录接口一样。
1. 后端创建配置对应的登录接口：
```
@Controller
public class LoginApi {
    // 登录页面接口
    @GetMapping("/login.html")
    public String loginPage() {
        return "login";
    }
```
  注：loginProcessingUrl的作用是为了告诉UsernamePasswordAuthenticationFilter用户名和密码获取地址，自己项目中无需声明一个对应的Controller接口，声明了也没用，因为不会走自己定义的接口。
  建议不要配置loginProcessingUrl，让他默认跟loginPage一致即可，免得搞乱自己。
2. 导入模板引擎 Thymeleaf：
```
    org.springframework.boot
    spring-boot-starter-thymeleaf
```
3. 创建登录页面：resources/templates/login.html，内容如下：
```
    
    Custom Login Page


    
        
            
            
        
        
            
            
        
        
    
```
  注：表单中action接口地址必须与loginProcessingUrl一致。
以上，便已完成配置。初次访问时，就会重定向到我们自定义登录界面/login.html，认证成功后即可访问其余页面。

登录成功跳转：登录成功后，设置跳转页面，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




    
    Failure


    登录是失败，请重新登录

配置登录失败处理：

@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表单中的登录参数：




    
    Custom Login Page

退出登录：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：


    io.jsonwebtoken
    jjwt-api
    0.11.2


    io.jsonwebtoken
    jjwt-impl
    0.11.2
    runtime


    io.jsonwebtoken
    jjwt-jackson 
    0.11.2
    runtime

编写 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 parseToken(String token) {
        Map userDetails = new HashMap<>();
        try {
            token = validateToken(token);
            Jws claimsJws = Jwts.parserBuilder()
                    .setSigningKey(getSecretKey()).build().parseClaimsJws(token);
            // 用户名
            String username = claimsJws.getBody().getSubject();
            // 用户权限
            List> authorities = (List>) claimsJws.getBody().get(KEY_USER_AUTHORITIES);
            Collection 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 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 userDetails = JwtTokenUtils.parseToken(token);
            String username = (String) userDetails.get(JwtTokenUtils.KEY_USER_NAME);
            Collection authorities =
                    (Collection) 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 认证和授权具体流程，可参考：

官网文档 - Authentication
Spring Security做JWT认证和授权

最后，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 users = Arrays.asList("David", "Roy", "Linda");

    @GetMapping
    public List 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 users = Stream.of("David","Roy","Linda").collect(Collectors.toList());

    @GetMapping
    public List getUsers() {
        return this.users;
    }

    @GetMapping("/{userId}")
    public String getUser(@PathVariable("userId") Integer userId) {
        return this.users.get(userId);
    }

    @PostMapping
    public List 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 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 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")

参考

Sprnig Security - 官网
最新版 Spring Security5.x 教程合集
spring Sercurity 介绍

附录

本篇博文所有例子源码可查看：Spring Security Demos

Spring Boot - 集成 Spring Security

简介

两个概念释义

架构总览

原理

DelegatingFilterProxy

FilterChainProxy

SecurityFilterChain

Security Filters

自动配置

自动装配FilterChainProxy

自动装配DelegatingFilterProxy

总结

基本使用

默认 SecurityFilterChain

默认用户配置

自定义配置入口

接口放行

用户与密码配置

安全防护

常见认证机制

HTTP Baisc Auth

Session-Cookie Auth

Token Auth

OAuth

SSO

授权

参考

附录

你可能感兴趣的:(Spring Boot - 集成 Spring Security)

自动装配`FilterChainProxy`

自动装配`DelegatingFilterProxy`