统一身份管理系统的权限设计方案与实践探索

文摘职场 2024-08-01 21:21 广东

序言

摘要

第 1 章：权限概述

第 2 章：通用权限设计方案

第 3 章：常见的权限框架

第 4 章：单点登录

第 5 章：作者介绍

吴灿锦，吉林财经大学2019级本科生，曾作为长春鹰迅网络科技有限责任公司CEO，带领鹰迅公司团队在“互联网 +"和"挑战杯"等竞赛中斩获3个国家级，11个省部级奖项。

目前在上市公司从事Java开发工作已经超过两年了，参与了两个千万级用户的分布式系统的开发和维护工作，在做项目期间，对Mysql优化，分库分表，多线程，分布式锁，分布式事务，Redis缓存，RabbitMQ，xxl-job，ElasticSearch，SpringCloud微服务框架以及前端的Vue框架都有比较深入的研究，积累了丰富的实际经验和良好的职业履历。

欢迎访问我的个人网站:

www.yxclass.net

第 1 章

权限概述

1.1、权限介绍

1.1.1、权限介绍

1、权限管理是一种核心的系统安全机制，用户可以访问而且只能访问自己被授权的资源，不多不少，防止未授权访问与数据泄露的风险。权限管理几乎出现在所有系统里面，只要有用户和密码的系统。

2、权限管理分类：

(1) 访问权限：超级管理员拥有整个系统所有权限，普通管理员有增删改查权限，普通用户只有查询权限。

(2) 数据权限：超级管理员可以看到系统所有信息，普通管理员可以看到下属员工信息，员工只能看到自己的信息。

1.1.2、访问权限

访问权限关注的是用户能够执行哪些操作，以及可以访问哪些资源。它定义了用户角色及其对应的操作权限集。例如，在一个零售管理系统中，为“店铺主管”角色分配了包括“查询员工信息”、“新增员工”、“编辑员工信息”及“删除员工”等在内的操作权限。这意味着任何担任“店铺主管”角色的用户（如张三），在被认证进入系统后，将能够执行上述所有操作，而不会超出其权限范围。

1.1.3、数据权限

数据权限进一步细化了用户对其操作数据的访问范围。它决定了用户能够查看、修改或管理哪些具体的数据记录。继续以零售管理系统为例，尽管张三作为“店铺主管”可以访问客服人员的买家订单信息，但系统可以通过数据权限控制，使得张三仅能查看其直接下属客服人员处理的订单，而其他客服人员则只能查看各自负责的订单信息。这种机制有效防止了数据泄露和未经授权的访问，确保了数据的安全性和隐私性。

1.2、认证概述

1.2.1、认证介绍

身份认证，就是判断一个用户是否为合法用户的处理过程。最常用的简单身份认证方式是系统通过核对用户输入的用户名和密码，看其是否与系统中存储的该用户的用户名和密码一致，来判断用户身份是否正确。例如：密码登录，手机短信验证、三方授权等。

1.2.2、认证流程

认证流程通常包括用户提交认证请求、系统接收并处理请求、核对用户凭证信息、判断用户身份是否合法，并最终返回认证结果等步骤。

1.2.3、关键对象与概念

上边的流程图中需要理解以下关键对象：

1. Subject（主体）：发起认证请求的用户或程序。它可以是任何需要访问系统资源的实体。

2. Principal（身份信息）：身份信息是主体（subject）进行身份认证的标识，标识必须具有唯一性，如用户名、手机号、邮箱地址等，一个主体可以有多个身份，但是必须有一个主身份（Primary Principal）。

3. Credential（凭证信息）：只有Subject自己知道的安全信息，用于验证Subject身份的真实性，如密码、私钥、动态验证码等。

1.3、授权概述

1.3.1、授权的定义

授权，又称访问控制，是指系统根据用户的身份和角色，控制其对系统资源的访问权限。用户通过认证后，系统会为其分配相应的权限，以决定其能够访问哪些资源以及如何进行访问。

1.3.2、授权流程

授权流程涉及用户请求访问资源、系统根据用户身份和角色检查其权限、判断用户是否有权访问该资源，并最终执行相应的访问控制策略。

1.3.3、关键对象与概念

1. Who（主体）：即Subject，进行访问操作的用户或程序。

2. What（资源）：被访问的对象，可以是系统菜单、页面、按钮、API接口、数据记录等。资源可以根据访问类型和数据类型进行细分。

3. Role（角色）：一组权限的集合，用于将用户与权限关联起来。角色简化了权限管理，使得可以将相同权限的用户归为一组进行管理。

4. Permission（权限/许可）：定义了用户对特定资源的访问方式和范围。例如，查看商品信息、编辑订单、删除评价等。

1.3.4、授权逻辑总结

授权过程可以简单理解为“谁（Who）可以对什么（What）进行何种操作（How）”。系统通过检查用户的角色和权限，来判断其是否有权对特定资源执行特定操作。这种机制确保了系统的安全性和数据的保密性，同时提高了用户操作的灵活性和便捷性。

第 2 章

通用权限设计方案

2.1、通用权限解决方案

2.1.1、权限概述

权限管理系统虽可借助Shiro、SpringSecurity等框架快速实现，但学习成本较高，未学习者需投入较多时间学习框架才能有效应用。

因此，我先提供一种基于用户、角色、资源多对多关系模型的通用权限设计，简化实施流程，精准控制用户对菜单、路由、接口等资源的访问，通过构建用户、角色、资源三者的灵活关系，实现细粒度权限管理，既降低了学习门槛，又增强了系统灵活性。

2.1.2、核心概念

1. 用户：系统使用者，拥有唯一的身份标识。

2. 角色：用户集合的抽象，用于定义一组具有共同权限的用户。

3. 资源：需要被保护访问的对象，如页面、API接口、操作按钮等。

2.1.3、权限配置

1. 用户管理：

(1）设计用户表，包含用户基本信息如ID、用户名、密码（加密存储）、状态等。

(2）开发用户管理界面，支持增删改查用户信息，以及密码重置等功能。

2. 资源配置：

(1）设计资源表，记录资源的唯一标识、名称、类型（如菜单、路由、接口、按钮）及描述。

(2）开发资源配置界面，允许管理员定义和修改系统中的资源。

3. 角色管理：

(1）设计角色表，包含角色ID、名称、描述等基本信息。

(2）开发角色管理界面，支持角色的增删改查。同时，复用此界面进行用户与角色的关联配置，展示当前角色关联的用户列表及关联操作。

4. 角色资源关联：

(1）设计角色资源关联表，记录角色与资源的对应关系。

(2）通过后台逻辑，实现角色与资源的灵活关联与解绑，确保权限分配的灵活性。

2.1.4、用户权限读取

1. 用户登录时，系统通过用户ID查询用户角色关联表，获取用户所属的所有角色。

2. 再根据角色ID查询角色资源关联表，汇总出用户可访问的所有资源权限。

3. 将权限信息以合适的形式（如JWT Token中的Claims）返回给前端，以及存储到后端的Redis中，供后续访问控制使用。

2.1.5、权限拦截

1. 前端拦截：

(1) 菜单与路由：根据用户权限动态生成菜单和路由表，未授权的资源对应的菜单项隐藏或不可访问。

(2) 按钮：通过Vue、React等前端框架的指令（如v-if、v-show、disabled等），根据用户权限控制按钮的显示与可操作性。

2. 后端拦截：

(1) 使用API网关（如Spring Cloud Gateway）的过滤器功能，对进入系统的所有API请求进行权限校验。

(2) 在过滤器中解析请求头中的权限信息（如JWT Token），与预定义的资源权限进行比对，决定是否放行请求。

(3) 对于未授权请求，返回统一的权限拒绝响应，并可选择记录相关日志。

2.2、数据库设计

2.2.1、用户表

2.2.2、资源表

2.2.3、角色表

2.2.4、用户角色表

2.2.5、角色资源表

2.2.6、权限初始化

系统上线时，要初始化这五张表的数据。初始要有一个admin用户能登录，等管理角色，管理资源，分配权限。

2.3、角色权限管理

2.3.1、前端角色授权

2.3.2、后端实体类

2.3.3、后端接口

2.3.4、Service层业务代码

2.3.5、Mapper层代码

2.3.6、其他SQL代码

2.4、登录时获取资源权限

当用户通过用户名和密码成功登录系统后，系统将会根据用户id获取用户的资源权限。

用户登录成功后，系统将执行以下步骤以获取用户的资源权限：

1. 角色查询：通过内连接查询role_user用户角色表，以用户ID为条件，检索出该用户关联的所有角色ID。

2. 资源权限查询：利用上一步获取的角色ID，再次通过内连接查询role_resource角色资源表，以角色ID为条件，查找出该用户通过其角色能够访问的所有资源ID。

3. 资源详情获取：最后，使用上一步得到的资源ID作为条件，查询resource资源表，获取这些资源的详细信息（如资源名称、类型、描述等）。

4. 权限实体映射：将查询到的资源表字段值映射到一个或多个自定义的权限实体类中，这些实体类将用于后续在系统中的权限验证和展示。

5. 缓存权限信息：为了提高后续权限验证的效率，将获取到的用户资源权限信息存储到Redis等缓存系统中，设置合适的过期时间，确保数据的时效性和准确性。

2.5、权限拦截功能开发

所有的前端拦截都是不安全的，所有的权限设置都要在API网关（如Spring Cloud Gateway）服务中进行校验，开发一个自定义的过滤器（Filter）来实现权限拦截功能。该过滤器将执行以下步骤：

1. 请求路径解析：在过滤器中，首先解析当前HTTP请求的URL路径，提取出需要访问的资源标识符（如API路径）。

2. 用户权限验证：用户登录成功时就会将用户的权限信息存储到redis中，当用户再次发起请求时，在gateway服务的过滤器中，检查用户请求的资源标识符是否存在于用户的权限列表中。

3. 拦截决策：如果用户请求的资源在其权限范围内，则允许请求继续传递到下游服务。如果用户请求的资源不在其权限列表中，则拦截该请求，并返回适当的错误响应（如403 Forbidden），同时可记录相关的安全日志以供审计。

2.6、限制密码重试次数

为了实现密码重试次数的限制，并在达到限制后锁定用户一段时间，我们可以使用Redis来存储用户的重试次数和锁定状态。

1. 我们使用RETRY_KEY_PREFIX来构建Redis的key，以便区分不同的用户。

2. 使用incrementRetryCount方法来增加重试次数，并设置了一个有效期（这里是600秒），以防止Redis中数据永久存储。

3. 在检查用户是否锁定时，我们还检查了锁定是否已过期。如果已过期，则允许用户再次尝试登录。

4. 当用户成功登录时，重置重试次数。

5. 当达到最大重试次数时，使用redisTemplate.opsForValue().set方法设置锁定状态，并指定锁定时间

2.7、在线并发登录人数控制

2.7.1、Redis数据结构使用

使用String类型：我们将一个由“业务前缀”和用户ID组成的复合字符串作为key，用户当前登录的token作为value存储在Redis中。这样，每个用户都有一个唯一的key来标识其当前的登录状态。

2.7.2、登录流程

1. 用户提交登录信息：用户输入用户名和密码并提交给服务器。

2. 验证登录信息：服务器验证用户名和密码。

3. 生成新token：如果验证成功，服务器生成一个新的token，将token作为key，用户权限作为value存储到redis中。

2.7.3、检查并发登录

1. 使用“业务前缀”+用户ID作为key，查询Redis中是否已存在对应的token。如果存在，说明用户已在其他设备上登录。此时，可以选择删除旧token（即让旧设备下线），或者根据业务需求采取其他措施（如发送通知）。

2. 如果不存在，更新Redis，使用“业务前缀”+用户ID作为key，将新生成的token作为value存储到Redis中，以标记用户当前登录的设备。

3. 返回登录结果：将新token返回给用户，用于后续请求的身份验证。

2.7.4、请求验证流程

在API网关或请求过滤器中，对每个携带token的请求进行验证：

1. 首先，从请求中提取token。

2. 然后，使用“业务前缀”+用户ID作为key，从Redis中获取当前登录的token值。

3. 将从请求中提取的token与Redis中存储的token进行比较。

4. 如果两个token相同，说明是同一个用户且在同一设备上发起的请求，验证通过。

5. 如果不同，说明用户可能已在其他设备登录，或者该token已过期或被篡改，此时可以拦截请求，并提示用户重新登录或检查其登录状态。

2.7.5、注意事项

1. 安全性：确保token的生成、存储和验证过程安全，防止token被窃取或伪造。

2. Redis可靠性：考虑Redis的高可用性和数据持久化策略，以防止数据丢失或服务中断。

3. 会话管理：设置合理的会话超时时间，并在用户会话超时后自动从Redis中删除相应的token。

4. 错误处理：在Redis操作失败时（如Redis服务不可用），系统有适当的回退策略，如暂时允许用户登录但不更新Redis，或直接拒绝登录请求并提示用户稍后重试。

第 3 章

常见的权限管理框架

3.1、Shiro

3.1.1、Shiro框架介绍

Apache Shiro是一个高效易用的Java安全框架，精简处理认证、授权、会话管理及密码加密。其直观API助力快速集成于各类应用，无论是轻量级移动应用还是大型网络/企业系统，均能实现无缝安全保护。

3.1.2、Shiro的优点

1. 灵活验证：支持多样数据源，身份验证灵活。

2. 细粒度授权：权限控制到方法级，精细管理。

3. 内置缓存：提升性能，减少数据库访问。

4. 跨平台会话：Web与非Web环境无缝衔接。

5. 安全加密：简洁API，保障数据安全传输。

6. 框架独立：不绑定框架，轻松集成任何Java项目。

7. 高度可扩展：支持自定义，满足多样化需求。

3.1.3、Shiro的核心组件

1. Subject：代表与当前系统交互的实体，可以是人、爬虫和机器人等，这是一个抽象概念。所有Subject都绑定到SecurityManager，与Subject的所有交互都会委托给SecurityManager；可以把Subject认为是一个门面；SecurityManager才是实际的执行者。

2. SecurityManager：Shiro核心，管理所有Subject及安全操作，类似于Spring MVC的DispatcherServlet。

3. Realm：安全数据源，为SecurityManager提供用户、角色、权限等信息，用于身份验证和授权。

3.1.4、Shiro数据库表

1. sh_user用户表：

2. sh_role用户角色表：

3. sh_resource资源表：

4. sh_role_resource角色资源表：

5. sh_user_role用户角色表：

3.1.5、Shiro认证执行流程

1. 通过配置文件初始化SecurityManager。

2. Subject调用login方法提交认证请求，包含用户凭据（如用户名和密码）。

3. SecurityManager使用ModularRealmAuthenticator进行认证处理。

4. ModularRealmAuthenticator将认证请求委托给配置的Realm（如IniRealm）。

5. Realm根据用户凭据从数据源（如shiro.ini文件）中检索用户信息。

6. 若找到用户信息，Realm将用户信息与token中的凭据进行比对。

7. 认证成功则返回用户信息，失败则根据错误类型抛出相应异常（如账号未知或密码错误）。

3.1.6、Shiro授权执行流程

1. Subject调用isPermitted方法，传入需检查的权限字符串。

2. SecurityManager接收请求，通过ModularRealmAuthorizer进行授权处理。

3. ModularRealmAuthorizer调用配置的Realm（如自定义Realm）的doGetAuthorizationInfo方法，从数据源（如数据库）获取用户权限信息。

4. Realm返回权限数据给ModularRealmAuthorizer。

5. ModularRealmAuthorizer使用PermissionResolver对权限字符串进行解析，并与Realm返回的权限数据进行比对。

6. 若权限匹配，则授权成功；否则，授权失败，可能抛出异常或返回授权失败结果。

3.1.7、Shiro常见注解

1. @RequiresAuthentication : 表示当前Subject已经通过login进行了身份验证；即 Subject.isAuthenticated() 返回 true。

2. @RequiresUser : 表示当前Subject 已经通过身份验证或者通过记住我登录的。

3. @RequiresGuest : 表示当前Subject没有身份验证或通过记住我登陆过，即是游客身份。

4. @RequiresRoles(value = {"admin", "user"}, logical = Logical.AND)：要求当前用户同时拥有admin和user两个角色。

5. @RequiresPermissions(value = {"user:a", "user:b"}, logical = Logical.OR)：要求当前用户至少拥有user:a或user:b中的一个权限。

3.1.8、配置ShiroFilterFactoryBean

在Spring Boot的配置类中，通过配置ShiroFilterFactoryBean来定义哪些路径需要认证（即需要登录），哪些路径不需要认证。

3.2、SpringSecurity

3.2.1、SpringSecurity介绍

Spring Security在架构上将认证与授权分离，并提供了扩展点。它是一个轻量级的安全框架，它确保基于Spring的应用程序提供身份验证和授权支持。它与Spring MVC有很好地集成，并配备了流行的安全算法实现捆绑在一起。

3.2.2、SpringSecurity执行流程

1. 客户端发起一个请求，首先进入Spring Security的过滤器链。

2. 在过滤器链中，首先通过LogoutFilter检查请求是否为登出请求。若是，则处理登出逻辑（包括调用登出处理器和成功/失败处理），否则继续向下传递。

3. 接着，UsernamePasswordAuthenticationFilter检查请求是否为登录请求。对于登录请求，执行认证流程，并根据认证结果调用相应的成功或失败处理器。非登录请求则绕过此过滤器。

4. 请求继续通过过滤器链，直到到达FilterSecurityInterceptor。在此处，拦截器根据请求的URI匹配相应的安全配置，并调用鉴权管理器进行鉴权。鉴权成功后，请求被允许继续访问Controller层；鉴权失败则重定向到AccessDeniedHandler进行进一步处理。

3.2.3、Shiro和SpringSecurity区别

1. 易用性：Shiro实现更简单，适合快速开发。

2. 社区支持：Spring Security作为Spring框架的一部分，社区支持更强大。

3. 独立性：Shiro不依赖特定框架，独立性强；Spring Security与Spring框架集成紧密。

3.2.4、跨域问题的解决方案

Spring Security通过配置CORS（跨源资源共享）支持来解决预检请求（如OPTIONS请求）和跨域问题。这主要通过cors()方法来配置CorsConfigurer实现。配置完成后，Spring Security会构建一个CorsFilter并将其添加到过滤器链中，确保在认证过滤器之前执行。

这个CorsFilter根据提供的CORS配置（如允许的源、头部、方法等）来处理跨域请求，使得前端应用能够安全地与后端服务进行交互。

简而言之，Spring Security通过内置的CORS支持，在认证前处理跨域请求，从而解决跨域问题。

3.2.5、如何对密码进行加密

Spring Security通过PasswordEncoder接口对密码进行加密，该接口包含了实现密码加密所需的核心方法。

开发者可以直接使用Spring Security提供的多种PasswordEncoder实现类，这些实现类覆盖了多种加密算法，非常方便。如果需要自定义加密算法，只需继承PasswordEncoder接口并实现其规定的三个核心方法即可。

这样，Spring Security就能灵活地应用于各种密码加密需求中。

3.2.6、更换系统默认加密算法

在Spring Security中，推荐使用DelegatingPasswordEncoder来更换或管理加密算法，因为它能兼容多种加密方案，是默认的加密方式，简化密码管理。

3.2.7、控制请求访问权限的方法

Spring Security有哪些控制请求访问权限的方法：

1. permitAll()：无条件允许任何形式访问，不管你登录还是没有登录。

2. anonymous()：允许匿名访问，也就是没有登录才可以访问。

3. denyAll()：拒绝所有用户访问。

4. authenticated()：仅允许已认证（登录）的用户访问。

5. fullyAuthenticated()：要求用户必须完全认证（即不是通过“记住我”功能登录的）才能访问。

6. hasRole(String role)：要求用户具有指定角色才能访问。

7. hasAnyRole(String... roles)：要求用户具有列表中任一角色即可访问。

8. hasAuthority(String authority)：要求用户具有指定权限才能访问。

9. hasAnyAuthority(String... authorities)：要求用户具有列表中任一权限即可访问。

10. hasIpAddress(String ipAddress)：仅允许来自特定IP地址的用户访问。

第 4 章

单点登录

4.1.1、什么是单点登录

单点登录（Single Sign-On, SSO）是一种身份认证策略，它允许用户在使用多个相互信任的应用系统时，只需进行一次登录操作即可访问所有系统。这一解决方案极大地提升了用户体验，减少了重复登录的繁琐过程，同时也在一定程度上增强了系统的安全性。

4.1.2、cookie禁用了如何解决

1. 利用HTTP头部：通过HTTP请求的Authorization头部或其他自定义HTTP头部来安全地传递token。这种方法不仅避免了在URL中直接暴露敏感信息，减少了信息泄露的风险，而且符合现代Web API的安全实践。

2. Web Storage作为备选方案：在支持HTML5的浏览器中，可以利用Session Storage或Local Storage来存储token。Session Storage适合存储与单个会话相关的数据，会话结束时数据会被清除，而Local Storage则适合长期存储数据。然而，使用Web Storage时需要注意浏览器的存储限制，并且确保存储的数据不会因浏览器设置而被禁用。

3. 集成SSO框架：作为最推荐的做法，集成单点登录（SSO）框架（如CAS）能够从根本上解决Cookie禁用带来的问题。SSO框架通过集中管理用户认证，不仅减少了token在客户端的暴露，还提供了跨多个应用系统的无缝身份认证体验。

4.1.3、SSO原理（单点登录流程）

以登录yxclass.net网站为例进行说明:

1. 未登录访问：用户首次访问yxclass.net时，若未登录，会被重定向至认证中心。

2. 认证中心登录：在认证中心，用户输入登录信息，系统验证通过后生成JWT（JSON Web Token）作为认证凭据，并返回给用户。

3. 携带Token访问：用户登录之后访问yxclass.net网站时，会在请求中携带JWT token作为身份认证信息。

4. 验证Token：yxclass.net网站收到请求后，将JWT token转发至认证中心进行验证。

5. 访问授权：若token验证通过，用户无需再次登录即可访问yxclass.net网站，实现单点登录。

4.1.4、SSO是如何实现的

1. 代理登录（Agent）：适用于无法直接改造的旧系统。通过代理服务器在用户与旧系统之间中转，模拟登录过程，实现SSO。

2. 令牌环节（Token）：利用Cookie等技术跨系统共享令牌。此方法简单但存在跨域访问限制和安全风险，如Cookie可能被浏览器限制或泄露。

3. 身份票据（Ticket）：最常见且广泛应用的SSO实现方式。引入一个信任验证服务器（如OAuth服务器、SAML服务器等），负责颁发和验证身份票据（如JWT、SAML断言等）。用户登录后，验证服务器发放票据，用户携带票据访问各系统，系统再向验证服务器验证票据的有效性，从而实现SSO。这种方式解决了信任存储、验证、作用范围和安全性的问题。

4.1.5、什么是CAS

1. CAS（Central Authentication Service）是一种实现SSO（单点登录）的轻量级开源框架。它主要由两部分构成：CAS Server和CAS Client。

2. CAS Server：作为认证中心，负责处理用户的登录认证。用户首次登录时，CAS Server会验证其身份并存储一个认证标识（如Ticket）。之后，用户访问已接入CAS的其他系统（即CAS Client）时，无需再次登录，CAS Server将基于之前的认证标识进行验证。

3. CAS Client：是已接入CAS Server的应用程序或服务。当用户尝试访问CAS Client时，如果尚未通过CAS Server认证，则会被重定向到CAS Server进行登录。若用户已认证，则CAS Server会验证其身份并允许访问，无需重复登录流程。

4. 简而言之，CAS通过CAS Server集中管理用户认证，CAS Client则通过CAS Server验证用户身份，实现跨系统的单点登录，提升用户体验和安全性。

4.1.6、CAS中三个术语

1. Ticket Granting ticket (TGT) ：可以认为是CAS Server根据用户名密码生成的一张票，存在Server端。

2. Ticket-granting cookie (TGC) ：其实就是一个Cookie，存放用户身份信息，由Server发给Client端。

3. Service ticket (ST) ：由TGT生成的一次性票据，用于验证，只能用一次。相当于Server发给Client一张票，然后Client拿着这个票再来找Server验证，看看是不是Server签发的。

4.1.7、CAS处理流程

1. 初始访问：用户首次访问应用服务，若未认证，则重定向至CAS Server。由于无CAS Cookie（TGC），用户被进一步重定向至CAS登录页面，并附带目标服务URL以便后续跳转。

2. 认证与票据生成：用户在CAS登录页面输入凭证进行认证。认证成功后，CAS Server生成TGT（票据授权票据）存储在服务器，并使用TGT生成针对目标服务的ST（服务票据）。随后，CAS Server将ST和CAS Cookie（TGC）发送给用户浏览器，并重定向用户至原始服务请求地址。

3. 服务访问与验证：用户浏览器携带ST访问目标服务，服务将ST提交至CAS Server进行验证。验证通过后，服务展示内容给用户，完成首次登录流程。

4. 跨服务访问：用户访问其他CAS保护的服务时，若已存在CAS Cookie（TGC）但无当前服务的ST，服务将请求CAS Server基于TGC生成新的ST。CAS Server直接生成ST并重定向用户至服务，无需用户再次登录。服务验证ST后展示内容。

5. 票据验证与页面展示：无论是首次登录还是跨服务访问，服务在收到ST后都会向CAS Server进行验证。验证成功后，服务根据原始请求展示相应页面内容，实现无缝的单点登录体验。

4.1.8、什么是Token

1. Token的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。

2. 当用户第一次登录后，服务器生成一个token并将此token返回给客户端，以后客户端只需带上这个token前来请求数据即可，无需再次带上用户名和密码。

3. 简单Token的组成；uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token的前几位以哈希算法压缩成的一定长度的十六进制字符串。为防止token泄露）。

4.1.9、OAuth是什么

1. OAuth 是一个行业的标准授权协议，主要用来授权第三方应用获取有限的权限。实际上它就是一种授权机制，最终目的是为第三方应用颁发一个有时效性令牌 token，使得第三方应用能够通过该令牌获取相关的资源。

2. OAuth 2.0 比较常用的场景就是第三方登录，当你的网站接入了第三方登录时一般就是使用的 OAuth 2.0 协议。

3. 现在OAuth 2.0也常见于支付场景（微信支付、支付宝支付）和开发平台（微信开放平台、阿里开放平台等等）。

4.1.10、介绍一下Access Token

在OAuth 2.0协议中，Access Token是客户端访问受保护资源时必须携带的凭证。它是一个全局唯一的随机字符串，代表用户已授权给客户端访问特定资源的权限。Access Token本身不直接包含敏感信息（如用户身份、授权范围等），这些信息存储在授权服务器的数据库中。客户端使用Access Token作为密钥，通过授权服务器验证其访问资源的权限。简而言之，Access Token是访问资源的“通行证”。

4.1.11、介绍一下Refresh Token

Refresh Token是OAuth 2.0协议中用于延长或获取新的Access Token的一种特殊令牌。与Access Token不同，Refresh Token通常具有较长的有效期，允许客户端在Access Token过期后，无需用户重新登录，即可通过Refresh Token向授权服务器请求一个新的Access Token。

这样做既简化了用户体验（避免了频繁登录），又增强了安全性。客户端持有有效的Refresh Token，可以自主完成Access Token的更新过程，无需用户干预。

4.1.12、介绍一下JWT

1. Json Web Token (JWT)是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准。该token被设计为紧凑且安全，特别适用于分布式站点单点登录场景。

2. JWT由头部（header)、载荷（payload)、签证（signature) 三部分组成。

(1) 头部（Header）：包含令牌类型和加密算法的元数据，通过Base64编码。

(2) 载荷（Payload）：包含声明（Claims），如用户信息、过期时间等，同样通过Base64编码。

(3) 签证（Signature）：使用头部中指定的算法和密钥对头部和载荷的编码结果进行签名，以确保数据完整性和来源可靠性。

4.1.13、JWT的工作流程

用户认证后，服务器生成JWT并发送给客户端；客户端在后续请求中携带JWT；服务器验证JWT的有效性后处理请求。JWT因其无状态、安全、紧凑的特点，适用于分布式系统中的身份验证和信息交换。

第 5 章

作者介绍

吴灿锦，泰伯一百零一世孙，明朝开国名将安陆侯吴复的后代，吉林财经大学2019级本科生；