Spring Security OAuth2.0认证授权

2023-05-16

文章目录

- 1、基本概念
- - 1.1.什么是认证
  - 1.2 什么是会话
  - 1.3什么是授权
  - 1.4授权的数据模型
  - 1.4 RBAC
  - - 1.4.1 基于角色的访问控制
- 2、基于Session的认证方式
- 3、整合案例
- - 3.1 SpringMVC+Servlet3.0模拟认证、会话、授权
  - - 3.1.1引入依赖
    - 3.1.2 Spring 容器配置ApplicationConfig
    - 3.1.3 servletContext配置 WebConfig
    - 3.1.4 加载 Spring容器SpringApplicationInitializer
    - 3.1.5实现认证功能
    - 3.1.6实现会话功能
    - 3.1.7实现授权功能
  - 3.2 Spring集成Security
  - 3.3 SpringBoot集成Security
- 4、工作原理
- - 4.1结构总览
  - 4.2认证流程
  - - AuthenticationProvider接口
    - UserDetailsService接口
    - PasswordEncoder接口
  - 4.3授权流程
  - - AccessDecisionManager（访问决策管理器）
    - 授权决策
- 5、自定认证
- - 5.1登录
  - 5.2会话
  - 5.3退出
  - 5.4授权
  - - web授权
    - 方法授权
- 6、分布式系统认证方案
- - 6.1什么是分布式系统
  - 6.2 分布式认证需求
  - - 统一认证授权
    - 应用接入认证
  - 6.3 分布式认证方案
  - - 选型分析
    - - 1、基于session的认证方式
      - 2、基于token的认证方式
    - 技术方案
- 7、OAuth2.0 开放授权
- - 7.1 OAuth2.0介绍
  - 7.2 Spring Cloud Security OAuth2 的实现
  - - 7.2.1代码略。。。。。。
    - 7.2.2授权服务器配置
    - - 1）@EnableAuthorizationServer 注解
      - 2）配置客户端详细信息
      - 3）管理令牌服务
      - 4）令牌访问端点配置
      - 5）配置授权端点的URL（Endpoint URLs）
      - 6）令牌端点的安全约束
    - 7.2.3.授权码模式
    - 7.2.4.简化模式
    - 7.2.5.密码模式
    - 7.2.6.客户端模式
    - 7.2.7.资源服务测试
    - - 资源服务器配置
      - 验证token
  - 7.3 JWT令牌
  - - 什么是JWT？
    - JWT令牌结构
- 8、Spring Security实现分布式系统授权
- - 需求分析
  - 网关

什么是认证、授权、会话。

Java Servlet为支持http会话做了哪些事儿。

基于session认证机制的运作流程。

基于token认证机制的运作流程。

理解Spring Security的工作原理，Spring Security结构总览，认证流程和授权，中间涉及到哪些组件，这些组件分

别处理什么，如何自定义这些组件满足个性需求。

OAuth2.0认证的四种模式？它们的大体流程是什么？

Spring cloud Security OAuth2包括哪些组件？职责？

分布式系统认证需要解决的问题？

代码参考：ahcfl_leon/work-study

1、基本概念

1.1.什么是认证

系统为什么要认证？

认证是为了保护系统的隐私数据与资源，用户的身份合法方可访问该系统的资源。

认证：用户认证就是判断一个用户的身份是否合法的过程，用户去访问系统资源时系统要求验证用户的身份信息，身份合法方可继续访问，不合法则拒绝访问。常见的用户身份认证方式有：用户名密码登录，二维码登录，手机短信登录，指纹认证等方式。

1.2 什么是会话

用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保证在会话中。会话就是系统为了保持当前用户的登录状态所提供的机制，常见的有基于session方式、基于token方式等。

1）基于session的认证方式如下图：

它的交互流程是，用户认证成功后，在服务端生成用户相关的数据保存在session(当前会话)中，发给客户端的 sesssion_id 存放到 cookie 中，这样用户客户端请求时带上 session_id 就可以验证服务器端是否存在 session 数据，以此完成用户的合法校验，当用户退出系统或session过期销毁时,客户端的session_id也就无效了。

2）基于token方式如下图：

它的交互流程是，用户认证成功后，服务端生成一个token发给客户端，客户端可以放到 cookie 或 localStorage 等存储中，每次请求时带上 token，服务端收到token通过验证后即可确认用户身份。

总结：

基于session的认证方式由Servlet规范定制，服务端要存储session信息需要占用内存资源，客户端需要支持 cookie；

基于token的方式则一般不需要服务端存储token，并且不限制客户端的存储方式。如今移动互联网时代更多类型的客户端需要接入系统，系统多是采用前后端分离的架构进行实现，所以基于token的方式更适合。

1.3什么是授权

微信来举例，微信登录成功后用户即可使用微信的功能，比如，发红包、发朋友圈、添加好友等，没有绑定银行卡的用户是无法发送红包的，绑定银行卡的用户才可以发红包，发红包功能、发朋友圈功能都是微信的资源即功能资源，用户拥有发红包功能的权限才可以正常使用发送红包功能，拥有发朋友圈功能的权限才可以使用发朋友圈功能，这个根据用户的权限来控制用户使用资源的过程就是授权。

为什么要授权？

认证是为了保证用户身份的合法性，授权则是为了更细粒度的对隐私数据进行划分，授权是在认证通过后发生的，控制不同的用户能够访问不同的资源。

授权：

授权是用户认证通过根据用户的权限来控制用户访问资源的过程，拥有资源的访问权限则正常访问，没有权限则拒绝访问。

1.4授权的数据模型

如何进行授权即如何对用户访问资源进行控制，首先需要学习授权相关的数据模型。

授权可简单理解为Who对What(which)进行How操作，包括如下：

Who，即主体（Subject），主体一般是指用户，也可以是程序，需要访问系统中的资源。

What，即资源（Resource），如系统菜单、页面、按钮、代码方法、系统商品信息、系统订单信息等。系统菜单、页面、按钮、代码方法都属于系统功能资源，对于web系统每个功能资源通常对应一个URL；系统商品信息、系统订单信息都属于实体资源（数据资源），实体资源由资源类型和资源实例组成，比如商品信息为资源类型，商品编号为001的商品为资源实例。

How，权限/许可（Permission），规定了用户对资源的操作许可，权限离开资源没有意义，如用户查询权限、用户添加权限、某个代码方法的调用权限、编号为001的用户的修改权限等，通过权限可知用户对哪些资源都有哪些操作许可。

主体、资源、权限相关的数据模型如下：

主体（用户id、账号、密码、…）

资源（资源id、资源名称、访问地址、…）

权限（权限id、权限标识、权限名称、资源id、…）

角色（角色id、角色名称、…）

角色和权限关系（角色id、权限id、…）

主体（用户）和角色关系（用户id、角色id、…）

主体（用户）、资源、权限关系如下图：

通常企业开发中将资源和权限表合并为一张权限表，如下：

资源（资源id、资源名称、访问地址、…）

权限（权限id、权限标识、权限名称、资源id、…）

合并为：

权限（权限id、权限标识、权限名称、资源名称、资源访问地址、…）

修改后数据模型之间的关系如下图：

1.4 RBAC

如何实现授权？业界通常基于RBAC实现授权。

1.4.1 基于角色的访问控制

RBAC基于角色的访问控制（Role-Based Access Control）是按角色进行授权，比如：主体的角色为总经理可以查询企业运营报表，查询员工工资信息等，访问控制流程如下：

根据上边的例子发现，当需要修改角色的权限时就需要修改授权的相关代码，系统可扩展性差。

1.4.2 基于资源的访问控制

RBAC基于资源的访问控制（Resource-Based Access Control）是按资源（或权限）进行授权，比如：用户必须具有查询工资权限才可以查询员工工资信息等，访问控制流程如下：

优点：系统设计时定义好查询工资的权限标识，即使查询工资所需要的角色变化为总经理和部门经理也不需要修改

授权代码，系统可扩展性强。

2、基于Session的认证方式

认证流程

基于Session认证方式的流程是，用户认证成功后，在服务端生成用户相关的数据保存在session(当前会话)，而发给客户端的 sesssion_id 存放到 cookie 中，这样用客户端请求时带上 session_id 就可以验证服务器端是否存在 session 数据，以此完成用户的合法校验。当用户退出系统或session过期销毁时,客户端的session_id也就无效了。

基于Session的认证机制由Servlet规范定制，Servlet容器已实现，用户通过HttpSession的操作方法即可实现，如下是HttpSession相关的操作API。

3、整合案例

3.1 SpringMVC+Servlet3.0模拟认证、会话、授权

3.1.1引入依赖

1、由于是web工程，packaging设置为war

2、使用tomcat7-maven-plugin插件来运行工程

  <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>5.1.5.RELEASE</version>
        </dependency>

        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>3.0.1</version>
            <scope>provided</scope>
        </dependency>
      
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.18.8</version>
        </dependency>
    </dependencies>

3.1.2 Spring 容器配置ApplicationConfig

在confifig包下定义ApplicationConfig.java，它对应web.xml中ContextLoaderListener的配置

@Configuration //相当于applicationContext.xml
@ComponentScan(basePackages = "com.cfl"
            ,excludeFilters = {@ComponentScan.Filter(type = FilterType.ANNOTATION,value = Controller.class)})
public class ApplicationConfig {
    //在此配置  除了Controller的其它bean，比如：数据库链接池、事务管理器、业务bean等。
}

3.1.3 servletContext配置 WebConfig

本案例采用Servlet3.0无web.xml方式，的confifig包下定义WebConfifig.java，它对应s对应于DispatcherServlet配置。

@Configuration  //就相当于springmvc.xml文件
@EnableWebMvc
@ComponentScan(basePackages = "com.cfl"
        ,includeFilters = {@ComponentScan.Filter(type = FilterType.ANNOTATION,value = Controller.class)})
public class WebConfig implements WebMvcConfigurer {
    
    //视频解析器
    @Bean
    public InternalResourceViewResolver viewResolver(){
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        viewResolver.setPrefix("/WEB-INF/view/");
        viewResolver.setSuffix(".jsp");
        return viewResolver;
    }

}

3.1.4 加载 Spring容器SpringApplicationInitializer

在init包下定义Spring容器初始化类SpringApplicationInitializer，此类实现WebApplicationInitializer接口， Spring容器启动时加载WebApplicationInitializer接口的所有实现类。

public class SpringApplicationInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {

    //spring容器，相当于加载 applicationContext.xml
    @Override
    protected Class<?>[] getRootConfigClasses() {
        return new Class[]{ApplicationConfig.class, WebSecurityConfig.class};
    }

    //servletContext，相当于加载springmvc.xml
    @Override
    protected Class<?>[] getServletConfigClasses() {
        return new Class[]{WebConfig.class};
    }

    //url-mapping
    @Override
    protected String[] getServletMappings() {
        return new String[]{"/"};
    }
}

SpringApplicationInitializer相当于web.xml，使用了servlet3.0开发则不需要再定义web.xml， ApplicationConfifig.class对应以下配置的application-context.xml，WebConfifig.class对应以下配置的spring- mvc.xml，web.xml的内容参考：

<web‐app>
    <listener>
    <listener‐class>org.springframework.web.context.ContextLoaderListener</listener‐class>
    </listener>
    
    <context‐param> 
        <param‐name>contextConfigLocation</param‐name> 
        <param‐value>/WEB‐INF/application‐context.xml</param‐value> 
    </context‐param> 
    
    <servlet>
        <servlet‐name>springmvc</servlet‐name> 
        <servlet‐class>org.springframework.web.servlet.DispatcherServlet</servlet‐class> 
        <init‐param> 
            <param‐name>contextConfigLocation</param‐name>
            <param‐value>/WEB‐INF/spring‐mvc.xml</param‐value>
        </init‐param> 
        <load‐on‐startup>1</load‐on‐startup> 
    </servlet> 
    
    <servlet‐mapping> 
        <servlet‐name>springmvc</servlet‐name> 
        <url‐pattern>/</url‐pattern> 
    </servlet‐mapping> 
    
</web‐app>

3.1.5实现认证功能

在WebConfifig中新增如下配置，将/直接导向login.jsp页面：

    @Override  // 视图控制器
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/").setViewName("login");
    }

认证接口

用户进入认证页面，输入账号和密码，点击登录，请求/login进行身份认证。

（1）定义认证接口，此接口用于对传来的用户名、密码校验，若成功则返回该用户的详细信息，否则抛出错误异常：

认证服务：
public interface AuthenticationService {

    /**
     * 用户认证
     * @param authenticationRequest 用户认证请求，账号和密码
     * @return 认证成功的用户信息
     */
    UserDto authentication(AuthenticationRequest authenticationRequest);
}

认证请求结构：
@Data
public class AuthenticationRequest {
    //认证请求参数，账号、密码。。
    /**
     * 用户名
     */
    private String username;

    /**
     * 密码
     */
    private String password;

}

认证成功后返回的用户详细信息，也就是当前登录用户的信息：
@Data
@AllArgsConstructor
public class UserDto {
    public static final String SESSION_USER_KEY = "_user";
    //用户身份信息
    private String id;
    private String username;
    private String password;
    private String fullname;
    private String mobile;
    /**
     * 用户权限
     */
    private Set<String> authorities;

}

（2）认证实现类，根据用户名查找用户信息，并校验密码，这里模拟了两个用户：

package com.cfl.service;


import com.cfl.model.AuthenticationRequest;
import com.cfl.model.UserDto;
import org.springframework.stereotype.Service;
import org.springframework.util.StringUtils;

import java.util.HashMap;
import java.util.HashSet;
import java.util.Map;
import java.util.Set;

/**
 * @author Administrator
 * @version 1.0
 **/
@Service
public class AuthenticationServiceImpl implements  AuthenticationService{
    /**
     * 用户认证，校验用户身份信息是否合法
     *
     * @param authenticationRequest 用户认证请求，账号和密码
     * @return 认证成功的用户信息
     */
    @Override
    public UserDto authentication(AuthenticationRequest authenticationRequest) {
        //校验参数是否为空
        if(authenticationRequest == null
            || StringUtils.isEmpty(authenticationRequest.getUsername())
            || StringUtils.isEmpty(authenticationRequest.getPassword())){
            throw new RuntimeException("账号和密码为空");
        }
        //根据账号去查询数据库,这里测试程序采用模拟方法
        UserDto user = getUserDto(authenticationRequest.getUsername());
        //判断用户是否为空
        if(user == null){
            throw new RuntimeException("查询不到该用户");
        }
        //校验密码
        if(!authenticationRequest.getPassword().equals(user.getPassword())){
            throw new RuntimeException("账号或密码错误");
        }
        //认证通过，返回用户身份信息
        return user;
    }


    //根据账号查询用户信息
    private UserDto getUserDto(String userName){
        return userMap.get(userName);
    }

    //用户信息
    private Map<String,UserDto> userMap = new HashMap<>();

    {
        Set<String> authorities1 = new HashSet<>();
        authorities1.add("p1");//这个p1我们人为让它和/r/r1对应
        Set<String> authorities2 = new HashSet<>();
        authorities2.add("p2");//这个p2我们人为让它和/r/r2对应
        userMap.put("zhangsan",new UserDto("1010","zhangsan","123","张三","133443",authorities1));
        userMap.put("lisi",new UserDto("1011","lisi","456","李四","144553",authorities2));
    }
}

（3）登录Controller，对/login请求处理，它调用AuthenticationService完成认证并返回登录结果提示信息：

@RestController
public class LoginController {

    @Autowired
    AuthenticationService authenticationService;

    @RequestMapping(value = "/login",produces = "text/plain;charset=utf-8")
    public String login(AuthenticationRequest authenticationRequest, HttpSession session){
        
        UserDetails userDetails = authenticationService.authentication(authenticationRequest);    
        return    userDetails.getFullname() + " 登录成功";
    }
}

启动项目，访问路径地址，进行测试

3.1.6实现会话功能

会话是指用户登入系统后，系统会记住该用户的登录状态，他可以在系统连续操作直到退出系统的过程。

认证的目的是对系统资源的保护，每次对资源的访问，系统必须得知道是谁在访问资源，才能对该请求进行合法性拦截。因此，在认证成功后，一般会把认证成功的用户信息放入Session中，在后续的请求中，系统能够从Session 中获取到当前用户，用这样的方式来实现会话机制。

增加会话控制：首先在UserDto中定义一个SESSION_USER_KEY，作为Session中存放登录用户信息的key。

public static final String SESSION_USER_KEY = "_user";

然后修改LoginController，认证成功后，将用户信息放入当前会话。并增加用户登出方法，登出时将session置为失效。

   @RequestMapping(value = "/login",produces = "text/plain;charset=utf-8")
    public String login(AuthenticationRequest authenticationRequest, HttpSession session){
        UserDto userDto = authenticationService.authentication(authenticationRequest);
        //存入session
        session.setAttribute(UserDto.SESSION_USER_KEY,userDto);
        return userDto.getUsername() +"登录成功";
    }

    @GetMapping(value = "/logout",produces = {"text/plain;charset=UTF-8"})
    public String logout(HttpSession session){
        session.invalidate();
        return "退出成功";
    }

启动项目，访问路径地址，进行测试

3.1.7实现授权功能

现在我们已经完成了用户身份凭证的校验以及登录的状态保持，并且我们也知道了如何获取当前登录用户(从 Session中获取)的信息，接下来，用户访问系统需要经过授权，即需要完成如下功能：

匿名用户（未登录用户）访问拦截：禁止匿名用户访问某些资源。

登录用户访问拦截：根据用户的权限决定是否能访问某些资源。

（1）增加权限数据

为了实现这样的功能，我们需要在UserDto里增加权限属性，用于表示该登录用户所拥有的权限，同时修改UserDto的构造方法。

并在AuthenticationServiceImpl中为模拟用户初始化权限，其中张三给了p1权限，李四给了p2权限。

（2）增加测试资源

我们想实现针对不同的用户能访问不同的资源，前提是得有多个资源，因此在LoginController中增加测试资源2。

如上代码所示

（3）实现授权拦截器

在interceptor包下定义SimpleAuthenticationInterceptor拦截器，实现授权拦截：

1、校验用户是否登录

2、校验用户是否拥有操作权限

@Component
public class SimpleAuthenticationInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        Object o = request.getSession().getAttribute(UserDto.SESSION_USER_KEY);
        if (Objects.isNull(o)) {
            writeContent(response,"请登录");
        }

        UserDto userDto = (UserDto) o;
        String requestURI = request.getRequestURI();
        if( userDto.getAuthorities().contains("p1") && requestURI.contains("/r/r1")){
            return true;
        }
        if( userDto.getAuthorities().contains("p2") && requestURI.contains("/r/r2")){
            return true;
        }
        writeContent(response,"没有权限，拒绝访问");

        return false;
    }

    private void writeContent(HttpServletResponse response, String msg) {
        response.setContentType("text/html;charset=utf-8");
        try {
            PrintWriter writer = response.getWriter();
            writer.print(msg);
            writer.close();
        } catch (IOException e) {
            System.out.println("e = " + e);
        }

    }
}

**在WebConfifig中配置拦截器，匹配/r/的资源为受保护的系统资源，访问该资源的请求进入 SimpleAuthenticationInterceptor拦器。

@Configuration//就相当于springmvc.xml文件
@EnableWebMvc
@ComponentScan(basePackages = "com.cfl"
        ,includeFilters = {@ComponentScan.Filter(type = FilterType.ANNOTATION,value = Controller.class)})
public class WebConfig implements WebMvcConfigurer {

    @Autowired
    SimpleAuthenticationInterceptor simpleAuthenticationInterceptor; // 自定义拦截器


    @Bean  // 视图解析器
    public InternalResourceViewResolver viewResolver(){
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        viewResolver.setPrefix("/WEB-INF/view/");
        viewResolver.setSuffix(".jsp");
        return viewResolver;
    }

    @Override  // 视图控制器
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/").setViewName("login");
    }

    @Override // 拦截器
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(simpleAuthenticationInterceptor).addPathPatterns("/r/**");
    }
}

测试

未登录情况下，/r/r1与/r/r2均提示 “请先登录”。

张三登录情况下，由于张三有p1权限，因此可以访问/r/r1，张三没有p2权限，访问/r/r2时提示 “权限不足 “。

李四登录情况下，由于李四有p2权限，因此可以访问/r/r2，李四没有p1权限，访问/r/r1时提示 “权限不足 “。

小结

基于Session的认证方式是一种常见的认证方式，至今还有非常多的系统在使用。我们在此小节使用Spring mvc技术对它进行简单实现，旨在让大家更清晰实在的了解用户认证、授权以及会话的功能意义及实现套路，也就是它们分别干了哪些事儿？大概需要怎么做？

而在正式生产项目中，我们往往会考虑使用第三方安全框架（如 spring security，shiro等安全框架）来实现认证授权功能，因为这样做能一定程度提高生产力，提高软件标准化程度，另外往往这些框架的可扩展性考虑的非常全面。但是缺点也非常明显，这些通用化组件为了提高支持范围会增加很多可能我们不需要的功能，结构上也会比较抽象，如果我们不够了解它，一旦出现问题，将会很难定位。

3.2 Spring集成Security

Spring Security是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。由于它是Spring生态系统中的一员，因此它伴随着整个Spring生态系统不断修正、升级，在spring boot项目中加入spring security更是十分简单，使用Spring Security 减少了为企业系统安全控制编写大量重复代码的工作。

代码步骤略

    <dependencies>
        <dependency>
            <groupId>org.springframework.security</groupId>
            <artifactId>spring-security-web</artifactId>
            <version>5.1.4.RELEASE</version>
        </dependency>

        <dependency>
            <groupId>org.springframework.security</groupId>
            <artifactId>spring-security-config</artifactId>
            <version>5.1.4.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>5.1.5.RELEASE</version>
        </dependency>

        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>3.0.1</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.18.8</version>
        </dependency>
    </dependencies>

小结

通过快速上手，使用Spring Security实现了认证和授权，Spring Security提供了基于账号和密码的认证方式，通过安全配置即可实现请求拦截，授权功能，Spring Security能完成的不仅仅是这些。

3.3 SpringBoot集成Security

Spring Boot是一套Spring的快速开发框架，基于Spring 4.0设计，使用Spring Boot开发可以避免一些繁琐的工程搭建和配置，同时它集成了大量的常用框架，快速导入依赖包，避免依赖包的冲突。基本上常用的开发框架都支持 Spring Boot开发，例如：MyBatis、Dubbo等，Spring 家族更是如此，例如：Spring cloud、Spring mvc、 Spring security等，使用Spring Boot开发可以大大得高生产率，所以Spring Boot的使用率非常高。

学习如何通过Spring Boot开发Spring Security应用，Spring Boot提供spring-boot-starter-security用于开发Spring Security应用。

引入依赖

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.3.RELEASE</version>
    </parent>

    <dependencies>
        <!-- 以下是>spring boot依赖-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <!-- 以下是>spring security依赖-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>


        <!-- 以下是jsp依赖-->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <!--jsp页面使用jstl标签 -->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>jstl</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
            <scope>provided</scope>
        </dependency>
        
        <!--用于编译jsp -->
        <dependency>
            <groupId>org.apache.tomcat.embed</groupId>
            <artifactId>tomcat-embed-jasper</artifactId>
            <scope>provided</scope>
        </dependency>
        
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.18.0</version>
        </dependency>
        
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jdbc</artifactId>
        </dependency>

        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>5.1.47</version>
        </dependency>
    </dependencies>

SpringBoot工程启动会自动扫描启动类所在包下的所有Bean，加载到spring容器。

Spring Boot配置文件：在resources下添加application.properties

server.port=8080
server.servlet.context-path=/security-springboot
spring.application.name = security-springboot

# 视频解析器配置在application.properties中
spring.mvc.view.prefix=/WEB-INF/view/
spring.mvc.view.suffix=.jsp

spring.datasource.url=jdbc:mysql://localhost:3306/test
spring.datasource.username=
spring.datasource.password=
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

Servlet Context配置：对于WebConfig，由于Spring boot starter自动装配机制，无需使用@EnableWebMvc @ComponentScan

安全配置 ：对于WebSecurityConfig，由于Spring boot starter自动装配机制，无需使用@EnableWebSecurity

详细代码略

4、工作原理

4.1结构总览

Spring Security所解决的问题就是安全访问控制，而安全访问控制功能其实就是对所有进入系统的请求进行拦截，校验每个请求是否能够访问它所期望的资源。

根据前边知识的学习，可以通过Filter或AOP等技术来实现，Spring Security对Web资源的保护是靠Filter实现的，所以从这个Filter来入手，逐步深入Spring Security原理。

当初始化Spring Security时，会创建一个名为 SpringSecurityFilterChain 的Servlet过滤器，

类型为org.springframework.security.web.FilterChainProxy，它实现了javax.servlet.Filter，因此外部的请求会经过此类，

下图是Spring Security过虑器链结构图：

FilterChainProxy是一个代理，真正起作用的是FilterChainProxy中SecurityFilterChain所包含的各个Filter，同时这些Filter作为Bean被Spring管理，它们是Spring Security核心，各有各的职责，但他们并不直接处理用户的认证，也不直接处理用户的授权，而是把它们交给了认证管理器（AuthenticationManager）和决策管理器（AccessDecisionManager）进行处理，

下图是FilterChainProxy相关类的UML图示：

spring Security功能的实现主要是由一系列过滤器链相互配合完成。

下面介绍过滤器链中主要的几个过滤器及其作用：

SecurityContextPersistenceFilter 这个Filter是整个拦截过程的入口和出口（也就是第一个和最后一个拦截器），会在请求开始时从配置好的 SecurityContextRepository 中获取 SecurityContext，然后把它设置给 SecurityContextHolder。在请求完成后将 SecurityContextHolder 持有的 SecurityContext 再保存到配置好的 SecurityContextRepository，同时清除 securityContextHolder 所持有的 SecurityContext；

UsernamePasswordAuthenticationFilter 用于处理来自表单提交的认证。该表单必须提供对应的用户名和密码，其内部还有登录成功或失败后进行处理的 AuthenticationSuccessHandler 和 AuthenticationFailureHandler，这些都可以根据需求做相关改变；

FilterSecurityInterceptor 是用于保护web资源的，使用AccessDecisionManager对当前用户进行授权访问，前面已经详细介绍过了；

ExceptionTranslationFilter 能够捕获来自 FilterChain 所有的异常，并进行处理。

但是它只会处理两类异常： AuthenticationException 和 AccessDeniedException，其它的异常它会继续抛出。

4.2认证流程

用户提交用户名、密码被SecurityFilterChain中的 UsernamePasswordAuthenticationFilter 过滤器获取到，封装为请求Authentication，通常情况下是UsernamePasswordAuthenticationToken这个实现类。

然后过滤器将Authentication提交至认证管理器（AuthenticationManager）进行认证

认证成功后， AuthenticationManager 身份管理器返回一个被填充满了信息的（包括上面提到的权限信息，身份信息，细节信息，但密码通常会被移除） Authentication 实例。

SecurityContextHolder 安全上下文容器将第3步填充了信息的 Authentication ，通过SecurityContextHolder.getContext().setAuthentication(…)方法，设置到其中。可以看出AuthenticationManager接口（认证管理器）是认证相关的核心接口，也是发起认证的出发点，它的实现类为ProviderManager。而Spring Security支持多种认证方式，因此ProviderManager维护着一个 List 列表，存放多种认证方式，最终实际的认证工作是由 AuthenticationProvider完成的。咱们知道web表单的对应的AuthenticationProvider实现类为 DaoAuthenticationProvider，它的内部又维护着一个UserDetailsService负责UserDetails的获取。最终 AuthenticationProvider将UserDetails填充至Authentication。

认证核心组件的大体关系如下：

AuthenticationProvider接口

通过前面的Spring Security认证流程我们得知，认证管理器（AuthenticationManager）委托 AuthenticationProvider完成认证工作。

AuthenticationProvider是一个接口，定义如下：

public interface AuthenticationProvider { 
    Authentication authenticate(Authentication authentication) throws AuthenticationException;
    boolean supports(Class<?> var1);
}

authenticate()方法定义了认证的实现过程，它的参数是一个Authentication，里面包含了登录用户所提交的用户、密码等。而返回值也是一个Authentication，这个Authentication则是在认证成功后，将用户的权限及其他信息重新组装后生成。 Spring Security中维护着一个 List 列表，存放多种认证方式，不同的认证方式使用不同的AuthenticationProvider。如使用用户名密码登录时，使用AuthenticationProvider1，短信登录时使用 AuthenticationProvider2等等这样的例子很多。

每个AuthenticationProvider需要实现**supports（）**方法来表明自己支持的认证方式，如我们使用表单方式认证，

在提交请求时Spring Security会生成UsernamePasswordAuthenticationToken，它是一个Authentication，里面封装着用户提交的用户名、密码信息。而对应的，哪个AuthenticationProvider来处理它？

我们在DaoAuthenticationProvider的基类AbstractUserDetailsAuthenticationProvider发现以下代码：

也就是说当web表单提交用户名密码时，Spring Security由DaoAuthenticationProvider处理。

最后，我们来看一下Authentication(认证信息)的结构，它是一个接口，我们之前提到的UsernamePasswordAuthenticationToken就是它的实现之一：

public interface Authentication extends Principal, Serializable { 
    （1） Collection<? extends GrantedAuthority> getAuthorities(); 
    （2） Object getCredentials(); 
    （3） Object getDetails(); 
    （4） Object getPrincipal(); 
    （5） boolean isAuthenticated(); 
    void setAuthenticated(boolean var1) throws IllegalArgumentException; 
}

（1）Authentication是spring security包中的接口，直接继承自Principal类，而Principal是位于 java.security 包中的。它是表示着一个抽象主体身份，任何主体都有一个名称，因此包含一个getName()方法。

（2）getAuthorities()，权限信息列表，默认是GrantedAuthority接口的一些实现类，通常是代表权限信息的一系列字符串。

（3）getCredentials()，凭证信息，用户输入的密码字符串，在认证过后通常会被移除，用于保障安全。

（4）getDetails()，细节信息，web应用中的实现接口通常为 WebAuthenticationDetails，它记录了访问者的ip地址和sessionId的值。

（5）getPrincipal()，身份信息，大部分情况下返回的是UserDetails接口的实现类，UserDetails代表用户的详细信息，那从Authentication中取出来的UserDetails就是当前登录用户信息，它也是框架中的常用接口之一。

UserDetailsService接口

现在咱们现在知道DaoAuthenticationProvider处理了web表单的认证逻辑，认证成功后既得到一个 Authentication(UsernamePasswordAuthenticationToken实现)，里面包含了身份信息（Principal）。这个身份信息就是一个 Object，大多数情况下它可以被强转为UserDetails对象。 DaoAuthenticationProvider中包含了一个UserDetailsService实例，它负责根据用户名提取用户信息 UserDetails(包含密码)，而后DaoAuthenticationProvider会去对比UserDetailsService提取的用户密码与用户提交的密码是否匹配作为认证成功的关键依据，因此可以通过将自定义的 UserDetailsService 公开为spring bean来定义自定义身份验证。

public interface UserDetailsService {
    UserDetails loadUserByUsername(String username) throws UsernameNotFoundException; 
}

DaoAuthenticationProvider和UserDetailsService的职责搞混淆，其实UserDetailsService只负责从特定的地方（通常是数据库）加载用户信息，仅此而已。而DaoAuthenticationProvider的职责更大，它完成完整的认证流程，同时会把UserDetails填充Authentication。

上面一直提到UserDetails是用户信息，咱们看一下它：

public interface UserDetails extends Serializable { 
    Collection<? extends GrantedAuthority> getAuthorities();
    String getPassword(); String getUsername();
    boolean isAccountNonExpired();
    boolean isAccountNonLocked(); 
    boolean isCredentialsNonExpired();
    boolean isEnabled(); 
}

它和Authentication接口很类似，比如它们都拥有username，authorities。

Authentication的getCredentials()与 UserDetails中的getPassword()需要被区分对待，前者是用户提交的密码凭证，后者是用户实际存储的密码，认证其实就是对这两者的比对。Authentication中的getAuthorities()实际是由UserDetails的getAuthorities()传递而形成的。

还记得Authentication接口中的getDetails()方法吗？其中的UserDetails用户详细信息便是经过了 AuthenticationProvider认证之后被填充的。

通过实现UserDetailsService和UserDetails，我们可以完成对用户信息获取方式以及用户信息字段的扩展。

Spring Security提供的InMemoryUserDetailsManager(内存认证)，JdbcUserDetailsManager(jdbc认证)就是UserDetailsService的实现类，主要区别无非就是从内存还是从数据库加载用户

自定义UserDetailsService

@Service public class SpringDataUserDetailsService implements UserDetailsService {
    @Override 
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        //登录账号
        System.out.println("username="+username); 
        //根据账号去数据库查询...
        //这里暂时使用静态数据 
        UserDetails userDetails = User.withUsername(username).password("123").authorities("p1").build(); 			return userDetails; 
    } 
}

屏蔽安全配置类中UserDetailsService的定义

/* @Bean 
public UserDetailsService userDetailsService() { 
    InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager(); manager.createUser(User.withUsername("zhangsan").password("123").authorities("p1").build()); manager.createUser(User.withUsername("lisi").password("456").authorities("p2").build());
    return manager; 
}*/

重启工程，请求认证，SpringDataUserDetailsService的loadUserByUsername方法被调用，查询用户信息。

PasswordEncoder接口

DaoAuthenticationProvider认证处理器通过UserDetailsService获取到UserDetails后，它是如何与请求 Authentication中的密码做对比呢？在这里Spring Security为了适应多种多样的加密类型，又做了抽象，DaoAuthenticationProvider通过 PasswordEncoder接口的matches方法进行密码的对比，而具体的密码对比细节取决于实现：

public interface PasswordEncoder { 
    String encode(CharSequence var1); 
                                  
    boolean matches(CharSequence var1, String var2);
    
    default boolean upgradeEncoding(String encodedPassword) {
        return false;
    }
}

而Spring Security提供很多内置的PasswordEncoder，能够开箱即用，使用某种PasswordEncoder只需要进行如下声明即可，如下：

@Bean public PasswordEncoder passwordEncoder() { 
    return NoOpPasswordEncoder.getInstance(); 
}

**NoOpPasswordEncoder采用字符串匹配方法，不对密码进行加密比较处理，**密码比较流程如下：

1、用户输入密码（明文）

2、DaoAuthenticationProvider获取UserDetails（其中存储了用户的正确密码）

3、DaoAuthenticationProvider使用PasswordEncoder对输入的密码和正确的密码进行校验，密码一致则校验通过，否则校验失败。

NoOpPasswordEncoder的校验规则拿输入的密码和UserDetails中的正确密码进行字符串比较，字符串内容一致则校验通过，否则校验失败。实际项目中推荐使用BCryptPasswordEncoder, Pbkdf2PasswordEncoder, SCryptPasswordEncoder等。

例如使用BCryptPasswordEncoder

1、配置BCryptPasswordEncoder 在安全配置类中定义

@Bean public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

测试认证失败，提示：Encoded password does not look like BCrypt。

原因：由于UserDetails中存储的是原始密码（比如：123），它不是BCrypt格式。

跟踪 DaoAuthenticationProvider第33行代码查看 userDetails中的内容，跟踪第38行代码查看 PasswordEncoder的类型。

@RunWith(SpringRunner.class) public class TestBCrypt { 
    @Test 
    public void test1(){
        //对原始密码加密 
        String hashpw = BCrypt.hashpw("123",BCrypt.gensalt());
        System.out.println(hashpw); 
        //校验原始密码和BCrypt密码是否一致 
        boolean checkpw = BCrypt.checkpw("123", "$2a$10$NlBC84MVb7F95EXYTXwLneXgCca6/GipyWR5NHm8K0203bSQMLpvm");
        System.out.println(checkpw); 
    }
}

实际项目中存储在数据库中的密码并不是原始密码，都是经过加密处理的密码。

4.3授权流程

通过快速上手我们知道，Spring Security可以通过 http.authorizeRequests() 对web请求进行授权保护。Spring Security使用标准Filter建立了对web请求的拦截，最终实现对资源的授权访问。

Spring Security的授权流程如下：

拦截请求，已认证用户访问受保护的web资源将被SecurityFilterChain中的 FilterSecurityInterceptor 的子类拦截。
获取资源访问策略，FilterSecurityInterceptor会从 SecurityMetadataSource 的子类 DefaultFilterInvocationSecurityMetadataSource 获取要访问当前资源所需要的权限 Collection 。 SecurityMetadataSource其实就是读取访问策略的抽象，而读取的内容，其实就是我们配置的访问规则，读取访问策略如：

http.authorizeRequests() 
    .antMatchers("/r/r1")
    .hasAuthority("p1") 
    .antMatchers("/r/r2")
    .hasAuthority("p2") 
    ...

最后，FilterSecurityInterceptor会调用 AccessDecisionManager 进行授权决策，若决策通过，则允许访问资源，否则将禁止访问。

AccessDecisionManager（访问决策管理器）

public interface AccessDecisionManager { 
    /** 通过传递的参数来决定用户是否有访问对应受保护资源的权限 */
    void decide(Authentication authentication , Object object,
                Collection<ConfigAttribute> configAttributes ) 
        throws AccessDeniedException, InsufficientAuthenticationException;
    //略.. 
}

decide的参数：

authentication：要访问资源的访问者的身份

object：要访问的受保护资源，web请求对应FilterInvocation

configAttributes：是受保护资源的访问策略，通过SecurityMetadataSource获取。

decide接口就是用来鉴定当前用户是否有访问对应受保护资源的权限。

授权决策

AccessDecisionManager采用投票的方式来确定是否能够访问受保护资源。

通过上图可以看出，AccessDecisionManager中包含的一系列AccessDecisionVoter将会被用来对Authentication

是否有权访问受保护对象进行投票，AccessDecisionManager根据投票结果，做出最终决策。

AccessDecisionVoter是一个接口，其中定义有三个方法，具体结构如下所示。

public interface AccessDecisionVoter<S> { 
    int ACCESS_GRANTED = 1;
    int ACCESS_ABSTAIN = 0; 
    int ACCESS_DENIED = ‐1; 
    
    boolean supports(ConfigAttribute var1);
    
    boolean supports(Class<?> var1); 
    
    int vote(Authentication var1, S var2, Collection<ConfigAttribute> var3);
}

vote()方法的返回结果会是AccessDecisionVoter中定义的三个常量之一。

ACCESS_GRANTED表示同意，

ACCESS_DENIED表示拒绝，

ACCESS_ABSTAIN表示弃权。

如果一个AccessDecisionVoter不能判定当前 Authentication是否拥有访问对应受保护对象的权限，则其vote()方法的返回值应当为弃权ACCESS_ABSTAIN。 Spring Security内置了三个基于投票的AccessDecisionManager实现类如下，它们分别是 :

AffirmativeBased、ConsensusBased、UnanimousBased

AffirmativeBased的逻辑：

（1）只要有AccessDecisionVoter的投票为ACCESS_GRANTED则同意用户进行访问；

（2）如果全部弃权也表示通过；

（3）如果没有一个人投赞成票，但是有人投反对票，则将抛出AccessDeniedException。

Spring security默认使用的是AffirmativeBased。

ConsensusBased的逻辑：

（1）如果赞成票多于反对票则表示通过。

（2）反过来，如果反对票多于赞成票则将抛出AccessDeniedException。

（3）如果赞成票与反对票相同且不等于0，并且属性allowIfEqualGrantedDeniedDecisions的值为true，则表示通过，否则将抛出异常AccessDeniedException。参数allowIfEqualGrantedDeniedDecisions的值默认为true。

（4）如果所有的AccessDecisionVoter都弃权了，则将视参数allowIfAllAbstainDecisions的值而定，如果该值为true则表示通过，否则将抛出异常AccessDeniedException。参数allowIfAllAbstainDecisions的值默认为false。

UnanimousBased的逻辑：

与另外两种实现有点不一样，另外两种会一次性把受保护对象的配置属性全部传递给AccessDecisionVoter进行投票，而UnanimousBased会一次只传递一个ConfigAttribute给 AccessDecisionVoter进行投票。

这也就意味着如果我们的AccessDecisionVoter的逻辑是只要传递进来的 ConfigAttribute中有一个能够匹配则投赞成票，但是放到UnanimousBased中其投票结果就不一定是赞成了。

具体来说是这样的：

（1）如果受保护对象配置的某一个ConfigAttribute被任意的AccessDecisionVoter反对了，则将抛出 AccessDeniedException。

（2）如果没有反对票，但是有赞成票，则表示通过。

（3）如果全部弃权了，则将视参数allowIfAllAbstainDecisions的值而定，true则通过，false则抛出AccessDeniedException。

Spring Security也内置一些投票者实现类如RoleVoter、AuthenticatedVoter和WebExpressionVoter等可以查阅资料进行学习。

5、自定认证

Spring Security提供了非常好的认证扩展方法，比如：快速上手中将用户信息存储到内存中，实际开发中用户信息通常在数据库，Spring security可以实现从数据库读取用户信息，Spring security还支持多种授权方法。

5.1登录

在快速上手中，你可能会想知道登录页面从哪里来的？因为我们并没有提供任何的HTML或JSP文件。Spring Security的默认配置没有明确设定一个登录页面的URL，因此Spring Security会根据启用的功能自动生成一个登录页面URL，并使用默认URL处理登录的提交内容，登录后跳转的到默认URL等等。尽管自动生成的登录页面很方便快速启动和运行，但大多数应用程序都希望定义自己的登录页面。

配置认证页面 ：在WebConfifig.java中配置认证页面地址：

//默认Url根路径跳转到/login，此url为spring security提供 
@Override
    public void addViewControllers(ViewControllerRegistry registry) {        registry.addViewController("/").setViewName("redirect:/login‐view");
    registry.addViewController("/login‐view").setViewName("login"); 
 }

安全配置 ：在WebSecurityConfig中配置表章登录信息

//配置安全拦截机制
@Override protected void configure(HttpSecurity http) throws Exception {
    http .authorizeRequests() 
        .antMatchers("/r/**").authenticated() 
        .anyRequest().permitAll() 
        .and() .formLogin()   // 允许表单登录
        .loginPage("/login‐view") //指定我们自己的登录页,spring security以重定向方式跳转到/login-view
        .loginProcessingUrl("/login") //指定登录处理的URL，也就是用户名、密码表单提交的目的路径
        .successForwardUrl("/login‐success") //指定登录成功后的跳转URL
        .permitAll(); //允许 任意用户访问基于表单登录的所有的URL
}

测试：当用户没有认证时访问系统的资源会重定向到login-view页面

问题解决：

spring security为防止CSRF（Cross-site request forgery跨站请求伪造）的发生，限制了除了get以外的大多数方法。

解决方法1：屏蔽CSRF控制，即spring security不再限制CSRF。 配置WebSecurityConfig

@Override protected void configure(HttpSecurity http) throws Exception {
    http.csrf().disable() //屏蔽CSRF控制，即spring security不再限制CSRF
    ......
}

解决方法2：

在login.jsp页面添加一个token，spring security会验证token，如果token合法则可以继续请求。修改login.jsp

<form action="login" method="post"> 
    <input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>
    ......
</form>

连接数据库认证

定义dataSource 在application.properties配置

spring.datasource.url=jdbc:mysql://localhost:3306/user_db 
spring.datasource.username=root 
spring.datasource.password=
spring.datasource.driver‐class‐name=com.mysql.jdbc.Driver

UserDao

@Repository
public class UserDao {

    @Autowired
    JdbcTemplate jdbcTemplate;

    //根据账号查询用户信息
    public UserDto getUserByUsername(String username){
        String sql = "select id,username,password,fullname,mobile from t_user where username = ?";
        //连接数据库查询用户
        List<UserDto> list = jdbcTemplate.query(sql, new Object[]{username}, new BeanPropertyRowMapper<>(UserDto.class));
        if(list !=null && list.size()==1){
            return list.get(0);
        }
        return null;
    }
    
}

定义UserDetailService

@Service public class SpringDataUserDetailsService implements UserDetailsService { 
    @Autowired UserDao userDao; 
    
    @Override public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException { 
        //登录账号 
        System.out.println("username="+username);
        //根据账号去数据库查询... 
        UserDto user = userDao.getUserByUsername(username); 
        if(user == null){
            return null;
		}
       //这里暂时使用静态数据
        UserDetails userDetails = User.withUsername(user.getFullname()).password(user.getPassword()).authorities("p1").build(); 
        return userDetails; 
    } 
}

测试：输入账号和密码请求认证，跟踪代码。

使用BCryptPasswordEncoder

使用BCryptPasswordEncoder需要完成如下工作：

在安全配置类中定义BCryptPasswordEncoder

@Bean public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

UserDetails中的密码存储BCrypt格式，前边实现了从数据库查询用户信息，所以数据库中的密码应该存储BCrypt格式

5.2会话

用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保存在会话中。spring security提供会话管理，认证通过后将身份信息放入SecurityContextHolder上下文，SecurityContext与当前线程进行绑定，方便获取用户身份。

获取用户身份

@RestController public class LoginController {

}

会话控制

我们可以通过以下选项准确控制会话何时创建以及Spring Security如何与之交互：

机制	描述
always	如果没有session存在就创建一个
ifRequired	如果需要就创建一个Session（默认）登录时
never	SpringSecurity 将不会创建Session，但是如果应用中其他地方创建了Session，那么Spring
stateless	SpringSecurity将绝对不会创建Session，也不使用Session

通过以下配置方式对该选项进行配置：

@Override protected void configure(HttpSecurity http) throws Exception {
    http.sessionManagement()
        .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED) 
}

默认情况下，Spring Security会为每个登录成功的用户会新建一个Session，就是ifRequired 。

若选用never，则指示Spring Security对登录成功的用户不创建Session了，但若你的应用程序在某地方新建了 session，那么Spring Security会用它的。

若使用stateless，则说明Spring Security对登录成功的用户不会创建Session了，你的应用程序也不会允许新建 session。并且它会暗示不使用cookie，所以每个请求都需要重新进行身份验证。这种无状态架构适用于REST API 及其无状态认证机制。

会话超时

可以再sevlet容器中设置Session的超时时间，如下设置Session有效期为3600s；

spring boot 配置文件：

server.servlet.session.timeout=3600s

session超时之后，可以通过Spring Security 设置跳转的路径。

http.sessionManagement() 
    .expiredUrl("/login‐view?error=EXPIRED_SESSION")
    .invalidSessionUrl("/login‐view?error=INVALID_SESSION");

// expired指session过期，invalidSession指传入的sessionid无效。

安全会话cookie

我们可以使用httpOnly和secure标签来保护我们的会话cookie：

httpOnly：如果为true，那么浏览器脚本将无法访问cookie

secure：如果为true，则cookie将仅通过HTTPS连接发送

spring boot 配置文件：

server.servlet.session.cookie.http‐only=true 
server.servlet.session.cookie.secure=true

5.3退出

Spring security默认实现了logout退出，访问/logout

点击“Log Out”退出成功。退出后访问其它url判断是否成功退出。

这里也可以自定义退出成功的页面：在WebSecurityConfifig的protected void confifigure(HttpSecurity http)中配置：

.and() .logout() .logoutUrl("/logout") .logoutSuccessUrl("/login‐view?logout");

当退出操作出发时，将发生：

使HTTP Session 无效

清除 SecurityContextHolder

跳转到 /login-view?logout

但是，类似于配置登录功能，可以进一步自定义退出功能

@Override protected void configure(HttpSecurity http) throws Exception { 
    http .authorizeRequests()
        //... 
        .and() .logout() //提供系统退出支持，使用 WebSecurityConfigurerAdapter 会自动被应用
        .logoutUrl("/logout") //设置触发退出操作的URL (默认是 /logout )
        .logoutSuccessUrl("/login‐view?logout") //退出之后跳转的URL。默认是 /login?logout 。
        .logoutSuccessHandler(logoutSuccessHandler) //定制的 LogoutSuccessHandler ，用于实现用户退出成功时的处理。如果指定了这个选项那么 logoutSuccessUrl() 的设置会被忽略。
        .addLogoutHandler(logoutHandler)//添加一个 LogoutHandler ，用于实现用户退出时的清理工作.默认 SecurityContextLogoutHandler 会被添加 为最后一个 LogoutHandler 。
        .invalidateHttpSession(true); //指定是否在退出时让 HttpSession 无效。 默认设置为 true。
}

注意：

如果让logout在GET请求下生效，必须关闭防止CSRF攻击csrf().disable()。如果开启了CSRF，必须使用 post方式请求/logout

logoutHandler：

一般来说， LogoutHandler 的实现类被用来执行必要的清理，因而他们不应该抛出异常。

下面是Spring Security提供的一些实现：

PersistentTokenBasedRememberMeServices 基于持久化token的RememberMe功能的相关清理

TokenBasedRememberMeService 基于token的RememberMe功能的相关清理

CookieClearingLogoutHandler 退出时Cookie的相关清理

CsrfLogoutHandler 负责在退出时移除csrfToken

SecurityContextLogoutHandler 退出时SecurityContext的相关清理

链式API提供了调用相应的 LogoutHandler 实现的快捷方式，比如deleteCookies()

5.4授权

授权的方式包括 web授权和方法授权，web授权是通过 url拦截进行授权，方法授权是通过方法拦截进行授权。

他们都会调用accessDecisionManager进行授权决策，若为web授权则拦截器为FilterSecurityInterceptor；

若为方法授权则拦截器为MethodSecurityInterceptor。如果同时通过web授权和方法授权则先执行web授权，再执行方法授权，

最后决策通过，则允许访问资源，否则将禁止访问。

类关系如下：

web授权

在上面例子中我们完成了认证拦截，并对/r/**下的某些资源进行简单的授权保护，但是我们想进行灵活的授权控制该怎么做呢？

通过给 http.authorizeRequests() 添加多个子节点来定制需求到我们的URL，如下代码：

@Override protected void configure(HttpSecurity http) throws Exception {
    http .authorizeRequests() (1) 
        .antMatchers("/r/r1").hasAuthority("p1") (2) 
        .antMatchers("/r/r2").hasAuthority("p2") (3)
        .antMatchers("/r/r3").access("hasAuthority('p1') and hasAuthority('p2')") (4) .antMatchers("/r/**").authenticated() (5)
        .anyRequest().permitAll() (6) 
        .and() .formLogin() // ... }

（1） http.authorizeRequests() 方法有多个子节点，每个macher按照他们的声明顺序执行。

（2）指定"/r/r1"URL，拥有p1权限能够访问

（3）指定"/r/r2"URL，拥有p2权限能够访问

（4）指定了"/r/r3"URL，同时拥有p1和p2权限才能够访问

（5）指定了除了r1、r2、r3之外"/r/**"资源，同时通过身份认证就能够访问，这里使用SpEL（Spring Expression Language）表式

（6）剩余的尚未匹配的资源，不做保护

注意：

规则的顺序是重要的,更具体的规则应该先写现在以/ admin开始的所有内容都需要具有ADMIN角色的身份验证用户,

即使是/ admin / login路径(因为/ admin / login已经被/ admin / **规则匹配,因此第二个规则被忽略)

.antMatchers("/admin/**").hasRole("ADMIN")
.antMatchers("/admin/login").permitAll()

因此,登录页面的规则应该在/ admin / **规则之前.例如

.antMatchers("/admin/login").permitAll() 
.antMatchers("/admin/**").hasRole("ADMIN")

保护URL常用的方法有：

authenticated() 保护URL，需要用户登录

permitAll() 指定URL无需保护，一般应用与静态资源文件

hasRole(String role) 限制单个角色访问，角色将被增加 “ROLE_” .所以”ADMIN” 将和 “ROLE_ADMIN”进行比较.

hasAuthority(String authority) 限制单个权限访问

**hasAnyRole(String… roles)**允许多个角色访问.

hasAnyAuthority(String… authorities) 允许多个权限访问.

access(String attribute) 该方法使用 SpEL表达式, 所以可以创建复杂的限制.

hasIpAddress(String ipaddressExpression) 限制IP地址或子网

方法授权

现在我们已经掌握了使用如何使用 http.authorizeRequests() 对web资源进行授权保护，从Spring Security2.0版本开始，它支持服务层方法的安全性的支持。

@PreAuthorize,@PostAuthorize, @Secured三类注解。我们可以在任何 @Configuration 实例上使用 @EnableGlobalMethodSecurity 注释来启用基于注解的安全性。

以下内容将启用Spring Security的 @Secured 注释。

@EnableGlobalMethodSecurity(securedEnabled = true) 
public class MethodSecurityConfig {// ...}

然后向方法（在类或接口上）添加注解就会限制对该方法的访问。 Spring Security的原生注释支持为该方法定义了一组属性。这些将被传递给AccessDecisionManager以供它作出实际的决定：

public interface BankService { 
    @Secured("IS_AUTHENTICATED_ANONYMOUSLY")
    public Account readAccount(Long id);
    
    @Secured("IS_AUTHENTICATED_ANONYMOUSLY") 
    public Account[] findAccounts(); 
    
    @Secured("ROLE_TELLER") 
    public Account post(Account account, double amount); 
}

以上配置标明readAccount、fifindAccounts方法可匿名访问，底层使用WebExpressionVoter投票器，可从AffirmativeBased第23行代码跟踪。post方法需要有TELLER角色才能访问，底层使用RoleVoter投票器。

使用如下代码可启用prePost注解的支持

@EnableGlobalMethodSecurity(prePostEnabled = true) 
public class MethodSecurityConfig { // ... }

相应Java代码如下：

public interface BankService {
    @PreAuthorize("isAnonymous()") 
    public Account readAccount(Long id); 
    
    @PreAuthorize("isAnonymous()") 
    public Account[] findAccounts(); 
    
    @PreAuthorize("hasAuthority('p_transfer') and hasAuthority('p_read_account')")
    public Account post(Account account, double amount); 
}

以上配置标明readAccount、fifindAccounts方法可匿名访问，

post方法需要同时拥有p_transfer和p_read_account 权限才能访问，

底层使用WebExpressionVoter投票器，可从AffirmativeBased第23行代码跟踪。

6、分布式系统认证方案

6.1什么是分布式系统

分布式系统具体如下基本特点：

1、分布性：每个部分都可以独立部署，服务之间交互通过网络进行通信，比如：订单服务、商品服务。

2、伸缩性：每个部分都可以集群方式部署，并可针对部分结点进行硬件及软件扩容，具有一定的伸缩能力。

3、共享性：每个部分都可以作为共享资源对外提供服务，多个部分可能有操作共享资源的情况。

4、开放性：每个部分根据需求都可以对外发布共享资源的访问接口，并可允许第三方系统访问。

6.2 分布式认证需求

分布式系统的每个服务都会有认证、授权的需求，如果每个服务都实现一套认证授权逻辑会非常冗余，

考虑分布式系统共享性的特点，需要由独立的认证服务处理系统认证授权的请求；

考虑分布式系统开放性的特点，不仅对系统内部服务提供认证，对第三方系统也要提供认证。

分布式认证的需求总结如下：

统一认证授权

提供独立的认证服务，统一处理认证授权。无论是不同类型的用户，还是不同种类的客户端(web端，H5、APP)，均采用一致的认证、权限、会话机制，实现统一认证授权。

要实现统一则认证方式必须可扩展，支持各种认证需求，比如：用户名密码认证、短信验证码、二维码、人脸识别等认证方式，并可以非常灵活的切换。

应用接入认证

应提供扩展和开放能力，提供安全的系统对接机制，并可开放部分API给接入第三方使用，一方应用（内部系统服务）和三方应用（第三方应用）均采用统一机制接入。

6.3 分布式认证方案

选型分析

1、基于session的认证方式

在分布式的环境下，基于session的认证会出现一个问题，每个应用服务都需要在session中存储用户身份信息，通

过负载均衡将本地的请求分配到另一个应用服务需要将session信息带过去，否则会重新认证。

这个时候，通常的做法有下面几种：

Session****复制：多台应用服务器之间同步session，使session保持一致，对外透明。

Session****黏贴：当用户访问集群中某台服务器后，强制指定后续所有请求均落到此机器上。

Session****集中存储：将Session存入分布式缓存中，所有服务器应用实例统一从分布式缓存中存取Session。

总体来讲，基于session认证的认证方式，可以更好的在服务端对会话进行控制，且安全性较高。但是，session机

制方式基于cookie，在复杂多样的移动客户端上不能有效的使用，并且无法跨域，另外随着系统的扩展需提高

session的复制、黏贴及存储的容错性。

2、基于token的认证方式

基于token的认证方式，服务端不用存储认证数据，易维护扩展性强，客户端可以把token 存在任意地方，并且可

以实现web和app统一认证机制。

其缺点也很明显，token由于自包含信息，因此一般数据量较大，而且每次请求都需要传递，因此比较占带宽。另外，token的签名验签操作也会给cpu带来额外的处理负担。

技术方案

根据选型的分析，决定采用基于token的认证方式，它的优点是：

1、适合统一认证的机制，客户端、一方应用、三方应用都遵循一致的认证机制。

2、token认证方式对第三方应用接入更适合，因为它更开放，可使用当前有流行的开放协议Oauth2.0、JWT等。

3、一般情况服务端无需存储会话信息，减轻了服务端的压力。

分布式系统认证技术方案见下图：

流程描述：

（1）用户通过接入方（应用）登录，接入方采取OAuth2.0方式在统一认证服务(UAA)中认证。

（2）认证服务(UAA)调用验证该用户的身份是否合法，并获取用户权限信息。

（3）认证服务(UAA)获取接入方权限信息，并验证接入方是否合法。

（4）若登录用户以及接入方都合法，认证服务生成jwt令牌返回给接入方，其中jwt中包含了用户权限及接入方权限。

（5）后续，接入方携带jwt令牌对API网关内的微服务资源进行访问。

（6）API网关对令牌解析、并验证接入方的权限是否能够访问本次请求的微服务。

（7）如果接入方的权限没问题，API网关将原请求header中附加解析后的明文Token，并将请求转发至微服务。

（8）微服务收到请求，明文token中包含登录用户的身份和权限信息。因此后续微服务自己可以干两件事：

1，用户授权拦截（看当前用户是否有权访问该资源）

2，将用户信息存储进当前线程上下文（有利于后续业务逻辑随时获取当前用户信息）

流程所涉及到UAA服务、API网关这三个组件职责如下：

1）统一认证服务(UAA

它承载了OAuth2.0接入方认证、登入用户的认证、授权以及生成令牌的职责，完成实际的用户认证、授权功能。

2）API网关

作为系统的唯一入口，API网关为接入方提供定制的API集合，它可能还具有其它职责，如身份验证、监控、负载均衡、缓存等。

API网关方式的核心要点是，所有的接入方和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。

7、OAuth2.0 开放授权

7.1 OAuth2.0介绍

OAuth（开放授权）是一个开放标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0。很多大公司如Google，Yahoo，Microsoft等都提供了OAUTH认证服务，这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。 Oauth协议目前发展到2.0版本，1.0版本过于复杂，2.0版本已得到广泛应用。

参考：https://baike.baidu.com/item/oAuth/7153134?fr=aladdin

Oauth协议：https://tools.ietf.org/html/rfc6749

OAauth2.0包括以下角色：

1、客户端

本身不存储资源，需要通过资源拥有者的授权去请求资源服务器的资源，

比如：Android客户端、Web客户端（浏览器端）、微信客户端等。

2、资源拥有者

通常为用户，也可以是应用程序，即该资源的拥有者。

3、授权服务器（也称认证服务器）

用于服务提供商对资源拥有的身份进行认证、对访问资源进行授权，认证成功后会给客户端发放令牌（access_token），

作为客户端访问资源服务器的凭据。本例为微信的认证服务器。

4、资源服务器

存储资源的服务器，本例子为微信存储的用户信息。

现在还有一个问题，服务提供商能允许随便一个客户端就接入到它的授权服务器吗？

答案是否定的，服务提供商会给准入的接入方一个身份，用于接入时的凭据:

client_id：客户端标识 client_secret：客户端秘钥

因此，准确来说，授权服务器对两种OAuth2.0中的两个角色进行认证授权，分别是资源拥有者、客户端。

7.2 Spring Cloud Security OAuth2 的实现

Spring-Security-OAuth2是对OAuth2的一种实现，并且跟我们之前学习的Spring Security相辅相成，与Spring Cloud体系的集成也非常便利，学习它，最终使用它来实现我们设计的分布式认证授权解决方案。

OAuth2.0的服务提供方涵盖两个服务，即授权服务 (Authorization Server，也叫认证服务) 和资源服务 (Resource Server)，使用 Spring Security OAuth2 的时候你可以选择把它们在同一个应用程序中实现，也可以选择建立使用同一个授权服务的多个资源服务。

授权服务 **(Authorization Server）**应包含对接入端以及登入用户的合法性进行验证并颁发token等功能，

对令牌的请求端点由 Spring MVC 控制器进行实现，下面是配置一个认证服务必须要实现的endpoints：

AuthorizationEndpoint 服务于认证请求。默认 URL： /oauth/authorize 。

TokenEndpoint 服务于访问令牌的请求。默认 URL： /oauth/token 。

资源服务 (Resource Server)，应包含对资源的保护功能，对非法请求进行拦截，对请求中token进行解析鉴权等，

下面的过滤器用于实现 OAuth 2.0 资源服务：

OAuth2AuthenticationProcessingFilter用来对请求给出的身份令牌解析鉴权。

7.2.1代码略。。。。。。

7.2.2授权服务器配置

1）@EnableAuthorizationServer 注解

@EnableAuthorizationServer 注解用来注释 AuthorizationServerConfigurerAdapter的继承类配置OAuth2.0 授权服务器的参数。

AuthorizationServerConfigurerAdapter要求配置以下几个类，这几个类是由Spring创建的独立的配置对象，

它们会被Spring传入AuthorizationServerConfigurer中进行配置。

public class AuthorizationServerConfigurerAdapter implements AuthorizationServerConfigurer { 
    public AuthorizationServerConfigurerAdapter() {} 
    
    public void configure(AuthorizationServerSecurityConfigurer security) throws Exception {}
    public void configure(ClientDetailsServiceConfigurer clients) throws Exception {}
    public void configure(AuthorizationServerEndpointsConfigurer endpoints) throws Exception {} }

ClientDetailsServiceConfifigurer：用来配置客户端详情服务（ClientDetailsService），客户端详情信息在这里进行初始化，你能够把客户端详情信息写死在这里或者是通过数据库来存储调取详情信息。

AuthorizationServerEndpointsConfifigurer：用来配置令牌（token）的访问端点和令牌服务(token services)。

AuthorizationServerSecurityConfifigurer：用来配置令牌端点的安全约束.

2）配置客户端详细信息

ClientDetailsServiceConfigurer 能够使用内存或者JDBC来实现客户端详情服务（ClientDetailsService），

ClientDetailsService负责查找ClientDetails，而ClientDetails有几个重要的属性如下列表：

clientId：（必须的）用来标识客户的Id。

secret：（需要值得信任的客户端）客户端安全码，如果有的话。

scope：用来限制客户端的访问范围，如果为空（默认）的话，那么客户端拥有全部的访问范围。

authorizedGrantTypes：此客户端可以使用的授权类型，默认为空。

authorities：此客户端可以使用的权限（基于Spring Security authorities）。

客户端详情（Client Details）能够在应用程序运行的时候进行更新，可以通过访问底层的存储服务（例如将客户端详情存储在一个关系数据库的表中，

就可以使用 JdbcClientDetailsService）或者通过自己实现 ClientRegistrationService接口（同时你也可以实现 ClientDetailsService 口）来进行管理。

3）管理令牌服务

AuthorizationServerTokenServices 接口定义了一些操作使得你可以对令牌进行一些必要的管理，令牌可以被用来加载身份信息，里面包含了这个令牌的相关权限。

自己可以创建 AuthorizationServerTokenServices 这个接口的实现，则需要继承 DefaultTokenServices 这个类，里面包含了一些有用实现，你可以使用它来修改令牌的格式和令牌的存储。默认的，当它尝试创建一个令牌的时候，是使用随机值来进行填充的，除了持久化令牌是委托一个 TokenStore 接口来实现以外，这个类几乎帮你做了所有的事情。并且 TokenStore 这个接口有一个默认的实现，它就是 InMemoryTokenStore ，如其命名，所有的令牌是被保存在了内存中。除了使用这个类以外，你还可以使用一些其他的预定义实现，下面有几个版本，它们都实现了TokenStore接口：

**InMemoryTokenStore：**这个版本的实现是被默认采用的，它可以完美的工作在单服务器上（即访问并发量压力不大的情况下，并且它在失败的时候不会进行备份），大多数的项目都可以使用这个版本的实现来进行尝试，你可以在开发的时候使用它来进行管理，因为不会被保存到磁盘中，所以更易于调试。

**JdbcTokenStore：**这是一个基于JDBC的实现版本，令牌会被保存进关系型数据库。使用这个版本的实现时，你可以在不同的服务器之间共享令牌信息，使用这个版本的时候请注意把"spring-jdbc"这个依赖加入到你的 classpath当中。

**JwtTokenStore：**这个版本的全称是 JSON Web Token（JWT），它可以把令牌相关的数据进行编码（因此对于后端服务来说，它不需要进行存储，这将是一个重大优势），但是它有一个缺点，那就是撤销一个已经授权令牌将会非常困难，所以它通常用来处理一个生命周期较短的令牌以及撤销刷新令牌（refresh_token）。另外一个缺点就是这个令牌占用的空间会比较大，如果你加入了比较多用户凭证息。JwtTokenStore 不会保存任何数据，但是它在转换令牌值以及授权信息方面与 DefaultTokenServices 所扮演的角色是一样的。

4）令牌访问端点配置

AuthorizationServerEndpointsConfifigurer 这个对象的实例可以完成令牌服务以及令牌endpoint配置。

配置授权类型（Grant Types），AuthorizationServerEndpointsConfifigurer 通过设定以下属性决定支持的授权类型（Grant Types）:

authenticationManager：

认证管理器，当你选择了资源所有者密码（password）授权类型的时候，请设置这个属性注入一个AuthenticationManager 对象。

userDetailsService：

如果你设置了这个属性的话，那说明你有一个自己的 UserDetailsService 接口的实现，或者你可以把这个东西设置到全局域上面去（例如 GlobalAuthenticationManagerConfifigurer 这个配置对象），当你设置了这个之后，那么 “refresh_token” 即刷新令牌授权类型模式的流程中就会包含一个检查，用来确保这个账号是否仍然有效，假如说你禁用了这个账户的话。

authorizationCodeServices：

这个属性是用来设置授权码服务的（AuthorizationCodeServices 的实例对象），主要用于 “authorization_code” 授权码类型模式。

implicitGrantService：

这个属性用于设置隐式授权模式，用来管理隐式授权模式的状态。

tokenGranter：

当你设置了这个东西（即 TokenGranter 接口实现），那么授权将会交由你来完全掌控，并且会忽略掉上面的这几个属性，这个属性一般是用作拓展用途的，即标准的四种授权模式已经满足不了你的需求的时候，才会考虑使用这个。

5）配置授权端点的URL（Endpoint URLs）

AuthorizationServerEndpointsConfigurer 这个配置对象有一个叫做 pathMapping() 的方法用来配置端点URL链接，它有两个参数：

第一个参数：String 类型的，这个端点URL的默认链接。

第二个参数：String 类型的，你要进行替代的URL链接。

以上的参数都将以 “/” 字符为开始的字符串，框架的默认URL链接如下列表，可以作为这个 pathMapping() 方法的第一个参数：

/oauth/authorize：授权端点。

/oauth/token：令牌端点。

/oauth/confirm_access：用户确认授权提交端点。

/oauth/error：授权服务错误信息端点。

/oauth/check_token：用于资源服务访问的令牌解析端点。

/oauth/token_key：提供公有密匙的端点，如果你使用JWT令牌的话。

**注意：**授权端点这个URL应该被Spring Security保护起来只供授权用户访问.

6）令牌端点的安全约束

AuthorizationServerSecurityConfifigurer：用来配置令牌端点(Token Endpoint)的安全约束，在

AuthorizationServer中配置如下

@Override public void configure(AuthorizationServerSecurityConfigurer security){ 
    security .tokenKeyAccess("permitAll()") (1) // tokenkey这个endpoint当使用JwtToken且使用非对称加密时，资源服务用于获取公钥而开放的，这里指这个endpoint完全公开。 
        .checkTokenAccess("permitAll()") (2) // checkToken这个endpoint完全公开 
        .allowFormAuthenticationForClients() (3) //  允许表单认证 
        ; 
}

授权服务配置总结：授权服务配置分成三大块，可以关联记忆。

既然要完成认证，它首先得知道客户端信息从哪儿读取，因此要进行客户端详情配置。

既然要颁发token，那必须得定义token的相关endpoint，以及token如何存取，以及客户端支持哪些类型的 token。

既然暴露除了一些endpoint，那对这些endpoint可以定义一些安全上的约束等

7.2.3.授权码模式

1）资源拥有者打开客户端，客户端要求资源拥有者给予授权，它将浏览器被重定向到授权服务器，

重定向时会附加客户端的身份信息。如：

/uaa/oauth/authorize?client_id=c1&response_type=code&scope=all&redirect_uri=http://www.baidu.com

参数列表如下：

client_id：客户端准入标识。

response_type：授权码模式固定为code。

scope：客户端权限。

redirect_uri：跳转uri，当授权码申请成功后会跳转到此地址，并在后边带上code参数（授权码）。

2）浏览器出现向授权服务器授权页面，之后将用户同意授权。

3）授权服务器将授权码（AuthorizationCode）转经浏览器发送给client(通过redirect_uri)。

4）客户端拿着授权码向授权服务器索要访问access_token，请求如下：

/uaa/oauth/token?client_id=c1&client_secret=secret&grant_type=authorization_code&code=5PgfcD&redirect_uri=http://w
ww.baidu.com

参数列表如下

client_id：客户端准入标识。

client_secret：客户端秘钥。

grant_type：授权类型，填写authorization_code，表示授权码模式

code：授权码，就是刚刚获取的授权码，注意：授权码只使用一次就无效了，需要重新申请。

redirect_uri：申请授权码时的跳转url，一定和申请授权码时用的redirect_uri一致。

5）授权服务器返回令牌(access_token)

这种模式是四种模式中最安全的一种模式。一般用于client是Web服务器端应用或第三方的原生App调用资源服务的时候。因为在这种模式中access_token不会经过浏览器或移动端的App，而是直接从服务端去交换，这样就最大限度的减小了令牌泄漏的风险。

7.2.4.简化模式

1）资源拥有者打开客户端，客户端要求资源拥有者给予授权，它将浏览器被重定向到授权服务器，

重定向时会附加客户端的身份信息。如：

/uaa/oauth/authorize?client_id=c1&response_type=code&scope=all&redirect_uri=http://www.baidu.com

参数描述同授权码模式 ，注意response_type=token，说明是简化模式。

2）浏览器出现向授权服务器授权页面，之后将用户同意授权。

3）授权服务器将授权码将令牌（access_token）以Hash的形式存放在重定向uri的fargment中发送给浏览器。

**注：**fragment 主要是用来标识 URI 所标识资源里的某个资源，在 URI 的末尾通过（#）作为 fragment 的开头，其中 # 不属于 fragment 的值。如https://domain/index#L18这个 URI 中 L18 就是 fragment 的值。只需要知道js通过响应浏览器地址栏变化的方式能获取到fragment 就行了。

一般来说，简化模式用于没有服务器端的第三方单页面应用，因为没有服务器端就无法接收授权码。

7.2.5.密码模式

1）资源拥有者将用户名、密码发送给客户端

2）客户端拿着资源拥有者的用户名、密码向授权服务器请求令牌（access_token），请求如下：

/uaa/oauth/token?client_id=c1&client_secret=secret&grant_type=password&username=shangsan&password=123

参数列表如下：

client_id：客户端准入标识。

client_secret：客户端秘钥。

grant_type：授权类型，填写password表示密码模式

username：资源拥有者用户名。

password：资源拥有者密码。

3）授权服务器将令牌（access_token）发送给client

这种模式十分简单，但是却意味着直接将用户敏感信息泄漏给了client，因此这就说明这种模式只能用于client是我们自己开发的情况下。因此密码模式一般用于我们自己开发的，第一方原生App或第一方单页面应用。

7.2.6.客户端模式

1）客户端向授权服务器发送自己的身份信息，并请求令牌（access_token）

2）确认客户端身份无误后，将令牌（access_token）发送给client，请求如下：

/uaa/oauth/token?client_id=c1&client_secret=secret&grant_type=client_credentials

参数列表如下：

client_id：客户端准入标识。

client_secret：客户端秘钥。

grant_type：授权类型，填写client_credentials表示客户端模式

这种模式是最方便但最不安全的模式。因此这就要求我们对client完全的信任，而client本身也是安全的。因此这种模式一般用来提供给我们完全信任的服务器端服务。比如，合作方系统对接，拉取一组用户信息。

7.2.7.资源服务测试

资源服务器配置

@EnableResourceServer 注解到一个 @Confifiguration 配置类上，

并且必须使用 ResourceServerConfigurer 这个配置对象来进行配置（可以选择继承自 ResourceServerConfifigurerAdapter 然后覆写其中的方法，参数就是这个对象的实例），下面是一些可以配置的属性：

ResourceServerSecurityConfifigurer中主要包括：

tokenServices：ResourceServerTokenServices 类的实例，用来实现令牌服务。

tokenStore：TokenStore类的实例，指定令牌如何访问，与tokenServices配置可选

resourceId：这个资源服务的ID，这个属性是可选的，但是推荐设置并在授权服务中进行验证。其他的拓展属性例如 tokenExtractor 令牌提取器用来提取请求中的令牌。

HttpSecurity配置这个与Spring Security类似：

请求匹配器，用来设置需要进行保护的资源路径，默认的情况下是保护资源服务的全部路径。

通过http.authorizeRequests()来设置受保护资源的访问规则

其他的自定义权限保护规则通过 HttpSecurity 来进行配置。

@EnableResourceServer 注解自动增加了一个类型为 OAuth2AuthenticationProcessingFilter 的过滤器链

编写ResouceServerConfig类略。。。

验证token

ResourceServerTokenServices 是组成授权服务的另一半，如果你的授权服务和资源服务在同一个应用程序上的话，你可以使用 DefaultTokenServices ，这样的话，你就不用考虑关于实现所有必要的接口的一致性问题。如果你的资源服务器是分离开的，那么你就必须要确保能够有匹配授权服务提供的 ResourceServerTokenServices，它知道如何对令牌进行解码。

令牌解析方法：

使用 DefaultTokenServices 在资源服务器本地配置令牌存储、解码、解析方式使用RemoteTokenServices 资源服务器通过 HTTP 请求来解码令牌，每次都请求授权服务器端点 /oauth/check_token使用授权服务的 /oauth/check_token 端点你需要在授权服务将这个端点暴露出去，以便资源服务可以进行访问，

7.3 JWT令牌

通过上边的测试我们发现，当资源服务和授权服务不在一起时资源服务使用RemoteTokenServices 远程请求授权服务验证token，

如果访问量较大将会影响系统的性能。

解决上边问题：

令牌采用JWT格式即可解决上边的问题，用户认证通过会得到一个JWT令牌，

JWT令牌中已经包括了用户相关的信息，客户端只需要携带JWT访问资源服务，资源服务根据事先约定的算法自行完成令牌校验，无需每次都请求认证服务完成授权。

什么是JWT？

JSON Web Token（JWT）是一个开放的行业标准（RFC 7519），它定义了一种简介的、自包含的协议格式，用于在通信双方传递json对象，传递的信息经过数字签名可以被验证和信任。JWT可以使用HMAC算法或使用RSA的公钥/私钥对来签名，防止被篡改。

官网：https://jwt.io/

标准：https://tools.ietf.org/html/rfc7519

JWT令牌的优点：

1）jwt基于json，非常方便解析。

2）可以在令牌中自定义丰富的内容，易扩展。

3）通过非对称加密算法及数字签名技术，JWT防止篡改，安全性高。

4）资源服务使用JWT可不依赖认证服务即可完成授权。

缺点：

１）JWT令牌较长，占存储空间比较大。

JWT令牌结构

通过学习JWT令牌结构为自定义jwt令牌打好基础。

JWT令牌由三部分组成，每部分中间使用点 . 分隔，比如：xxxxx.yyyyy.zzzzz

base64UrlEncode(header)：jwt令牌的第一部分。

base64UrlEncode(payload)：jwt令牌的第二部分。

secret：签名所使用的密钥。jwt令牌的第三部分。

Header

头部包括令牌的类型（即JWT）及使用的哈希算法（如HMAC SHA256或RSA）

一个例子如下：下边是Header部分的内容

{ "alg": "HS256", "typ": "JWT" }

将上边的内容使用Base64Url编码，得到一个字符串就是JWT令牌的第一部分

Payload

第二部分是负载，内容也是一个json对象，它是存放有效信息的地方，它可以存放jwt提供的现成字段，比如：

iss（签发者） exp（过期时间戳） sub（面向的用户）等，也可自定义字段。

此部分不建议存放敏感信息，因为此部分可以解码还原原始内容。

最后将第二部分负载使用Base64Url编码，得到一个字符串就是JWT令牌的第二部分。

{ "sub": "1234567890", "name": "456", "admin": true }

Signature

第三部分是签名，此部分用于防止jwt内容被篡改。

这个部分使用base64url将前两部分进行编码，编码后使用点 . 连接组成字符串，最后使用header中声明签名算法进行签名。

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

8、Spring Security实现分布式系统授权

d336a09ff60a21bcd2950960b34d999e

需求分析

1、UAA认证服务负责认证授权。

2、所有请求经过网关到达微服务

3、网关负责鉴权客户端以及请求转发

4、网关将token解析后传给微服务，微服务进行授权。

所有微服务的请求都经过网关，网关从注册中心读取微服务的地址，将请求转发至微服务。

网关

网关整合 OAuth2.0 有两种思路，一种是认证服务器生成jwt令牌, 所有请求统一在网关层验证，判断权限等操作；

另一种是由各资源服务处理，网关只做请求转发。

我们选用第一种。我们把API网关作为OAuth2.0的资源服务器角色，实现接入客户端权限拦截、令牌解析并转发当

前登录用户信息(jsonToken)给微服务，这样下游微服务就不需要关心令牌格式解析以及OAuth2.0相关机制了。

API网关在认证授权体系里主要负责两件事：

（1）作为OAuth2.0的资源服务器角色，实现接入方权限拦截。

（2）令牌解析并转发当前登录用户信息（明文token）给微服务

微服务拿到明文token(明文token中包含登录用户的身份和权限信息)后也需要做两件事：

（1）用户授权拦截（看当前用户是否有权访问该资源）

（2）将用户信息存储进当前线程上下文（有利于后续业务逻辑随时获取当前用户信息）

其他代码略。。。。。。。。

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)

Spring Security OAuth2.0认证授权

文章目录

1、基本概念

1.1.什么是认证

1.2 什么是会话

1.3什么是授权

1.4授权的数据模型

1.4 RBAC

1.4.1 基于角色的访问控制

2、基于Session的认证方式

3、整合案例

3.1 SpringMVC+Servlet3.0模拟认证、会话、授权

3.1.1引入依赖

3.1.2 Spring 容器配置ApplicationConfig

3.1.3 servletContext配置 WebConfig

3.1.4 加载 Spring容器SpringApplicationInitializer

3.1.5实现认证功能

3.1.6实现会话功能

3.1.7实现授权功能

3.2 Spring集成Security

3.3 SpringBoot集成Security

4、工作原理

4.1结构总览

4.2认证流程

AuthenticationProvider接口

UserDetailsService接口

PasswordEncoder接口

4.3授权流程

AccessDecisionManager（访问决策管理器）

授权决策

5、自定认证

5.1登录

5.2会话

5.3退出

5.4授权

web授权

方法授权

6、分布式系统认证方案

6.1什么是分布式系统

6.2 分布式认证需求

统一认证授权

应用接入认证

6.3 分布式认证方案

选型分析

1、基于session的认证方式

2、基于token的认证方式

技术方案

7、OAuth2.0 开放授权

7.1 OAuth2.0介绍

7.2 Spring Cloud Security OAuth2 的实现

7.2.1代码略。。。。。。

7.2.2授权服务器配置

1）@EnableAuthorizationServer 注解

2）配置客户端详细信息

3）管理令牌服务

4）令牌访问端点配置

5）配置授权端点的URL（Endpoint URLs）

6）令牌端点的安全约束

7.2.3.授权码模式

7.2.4.简化模式

7.2.5.密码模式

7.2.6.客户端模式

7.2.7.资源服务测试

资源服务器配置

验证token

7.3 JWT令牌

什么是JWT？

JWT令牌结构

8、Spring Security实现分布式系统授权

需求分析

网关

Spring Security OAuth2.0认证授权 的相关文章

随机推荐

热门标签

Spring Security OAuth2.0认证授权的相关文章