《JAVA面经实录》- 权限管理框面试题

《JAVA面经实录》- 权限管理框面试题

Java权限管理框架面试题（23道高频题）

本文严格按照指定题目顺序，整理每道题的面试标准回答+补充要点，贴合后端面试实战场景，语言简洁、重点突出，可直接用于备考，适配初级到中级后端开发岗位。

一、Shiro框架用过吗？

面试标准回答

用过。Apache Shiro是一款轻量级的Java安全框架，我在项目中主要用它实现身份认证（登录验证）、授权（权限控制）、密码加密、会话管理这几个核心功能。

实际开发中，我曾基于SpringBoot整合Shiro，自定义Realm从数据库查询用户信息和权限，配置密码匹配器实现MD5加盐加密，通过注解式（如@RequiresRoles、@RequiresPermissions）和编程式两种方式实现权限控制，同时整合Redis解决分布式项目的会话共享问题，确保用户登录后多台服务器可正常访问。

面试补充

核心亮点：Shiro不依赖Spring，可独立使用，配置简单、API简洁，学习成本低，适合中小型项目；若项目是Spring生态，也可无缝整合，灵活性很高。

二、Shiro的优点？

面试标准回答

Shiro的核心优点的是轻量、简洁、易用、灵活，具体可分为4点：

1. 轻量级，学习成本低：API简洁直观，配置简单，无需深入了解底层原理，上手速度快，开发效率高；

2. 不依赖Spring生态：可独立使用，也可与Spring、SpringBoot、MyBatis等框架无缝整合，适配各类Java项目（从小型项目到分布式项目）；

3. 功能完善且实用：核心功能（认证、授权、会话管理、密码加密）齐全，满足大多数项目的权限管理需求，无需额外引入其他组件；

4. 灵活性高：支持自定义Realm、密码匹配器、会话管理器，可根据业务需求灵活扩展，适配复杂的权限场景。

三、Shiro的核心组件?

面试标准回答

Shiro的核心组件围绕“认证+授权”展开，四大核心组件（自上而下执行流程：Subject → SecurityManager → Realm）+ 辅助组件，具体如下：

1. Subject（主体）：代表当前登录的用户（或程序），是Shiro对外提供的核心入口，所有操作（登录、授权、登出）都通过Subject发起，比如subject.login(token)实现登录。

2. SecurityManager（安全管理器）：Shiro的核心中枢，负责管理所有Subject，协调其他组件（Realm、SessionManager等）的工作，是Shiro的“大脑”，项目中通常配置一个全局唯一的SecurityManager。

3. Realm（领域）：Shiro的“数据源”，负责从数据库（或其他存储介质）中获取用户信息、权限信息，供Shiro进行身份认证和授权验证。实战中必须自定义Realm，重写认证（doGetAuthenticationInfo）和授权（doGetAuthorizationInfo）方法。

4. SessionManager（会话管理器）：负责管理Subject的会话，支持JavaSE（本地会话）和JavaEE（Web会话），可自定义会话存储（如Redis），解决分布式会话共享问题。

5. 辅助组件（常用）：

   1. CredentialsMatcher：密码匹配器，校验用户输入的密码与数据库中加密密码是否一致；

   2. CacheManager：缓存管理器，缓存用户权限信息，减少数据库查询，提升性能；

   3. Cryptography：加密模块，提供MD5、SHA等常用加密算法，避免明文存储密码。

四、Shiro认证执行流程？

面试标准回答

Shiro认证（登录）的核心是“校验用户输入的账号密码，与数据库中存储的信息是否一致”，完整流程分为5步，结合实战逻辑：

1. 1. 获取Subject对象：通过SecurityUtils.getSubject()获取当前登录主体（未登录时为匿名主体）；

2. 2. 封装登录信息：创建UsernamePasswordToken对象，存储用户输入的账号和密码；

3. 3. 发起登录请求：调用subject.login(token)方法，触发Shiro的认证流程；

4. 4. SecurityManager调用Realm进行认证：

   1. SecurityManager接收请求后，将请求转发给自定义Realm；

   2. Realm的doGetAuthenticationInfo方法被调用，从数据库查询该用户名对应的用户信息（用户名、加密密码、盐值等）；

   3. CredentialsMatcher（密码匹配器）校验用户输入的明文密码，与数据库中的加密密码（加盐加密）是否一致。

5. 5. 处理认证结果：

   1. 认证成功：Subject被标记为“已认证”，后续可进行授权操作；

   2. 认证失败：抛出对应异常（如UnknownAccountException：账号不存在、IncorrectCredentialsException：密码错误），程序捕获异常并返回提示。

五、Shiro授权执行流程？

面试标准回答

Shiro授权的核心是“校验已认证用户是否拥有某个角色或权限”，必须在认证成功后执行，完整流程分为3步：

1. 1. 用户认证成功后，发起资源访问请求（如访问/admin/list接口、调用删除用户方法）；

2. 2. Shiro拦截请求，通过Subject获取当前用户的身份信息，调用SecurityManager触发授权流程；

3. 3. SecurityManager调用Realm的doGetAuthorizationInfo方法，获取该用户的角色和权限信息，与请求所需的角色/权限进行比对：

   1. 比对通过：允许用户访问资源；

   2. 比对失败：抛出UnauthorizedException（未授权异常），程序捕获并返回403禁止访问。

面试补充

授权的前提是“用户已认证”，实战中授权通常结合注解式（@RequiresRoles）、编程式（subject.hasRole()）两种方式实现。

六、Shiro注解有哪些？

面试标准回答

Shiro提供了多个注解，用于实现注解式授权，核心常用的有5个，需在SpringBoot配置中开启@EnableShiroAnnotation才能生效：

1. @RequiresAuthentication：要求用户必须认证成功后，才能访问该方法/接口，未认证则抛出异常；

2. @RequiresRoles：要求用户必须拥有指定的角色，才能访问，支持多角色（如@RequiresRoles("ADMIN")、@RequiresRoles({"ADMIN", "USER"})，默认多角色需全部拥有）；

3. @RequiresRolesOr：多角色任选其一即可访问（如@RequiresRolesOr({"ADMIN", "USER"})，拥有其中一个角色就可访问）；

4. @RequiresPermissions：要求用户必须拥有指定的权限，才能访问（如@RequiresPermissions("user:delete")，拥有删除用户权限才可访问）；

5. @RequiresUser：要求用户是“已认证”或“记住我”状态，才能访问（区别于@RequiresAuthentication，记住我状态也可访问）。

七、SpringSecurity了解吗？

面试标准回答

了解，SpringSecurity是Spring生态下的一款企业级安全框架，基于Spring IoC/DI和AOP实现，核心功能与Shiro类似，但功能更全面、安全性更高。

实际开发中，我曾用SpringSecurity整合SpringBoot，实现用户认证、基于角色/权限的授权、JWT无状态认证，同时利用其原生支持的CSRF防护、会话并发控制等功能，解决项目中的安全问题。它与Spring生态深度整合，自动配置能力强，适合大型企业级项目，比如电商、金融类项目，对安全要求较高的场景。

面试补充

核心亮点：原生支持OAuth2.0、JWT、LDAP，无需额外整合；内置多种安全防护机制，开箱即用；可灵活扩展，适配复杂的权限和认证场景。

八、SpringSecurity执行流程？

面试标准回答

SpringSecurity的核心是“安全过滤器链（SecurityFilterChain）”，所有请求都会经过过滤器链中的一系列过滤器，完成认证和授权，完整流程分为6步：

1. 1. 用户发起请求（如登录请求、资源访问请求）；

2. 2. 请求被过滤器链拦截，首先经过SecurityContextPersistenceFilter，初始化SecurityContext（存储用户认证信息的上下文）；

3. 3. 若为登录请求，会被UsernamePasswordAuthenticationFilter拦截，封装请求中的用户名、密码为UsernamePasswordAuthenticationToken（认证对象）；

4. 4. 该过滤器调用AuthenticationManager（认证管理器）的authenticate()方法，发起认证：

   1. AuthenticationManager调用UserDetailsService的loadUserByUsername()方法，从数据库查询用户详情（UserDetails对象）；

   2. PasswordEncoder（密码编码器）校验用户输入的明文密码与数据库中的加密密码是否一致。

5. 5. 认证结果处理：

   1. 认证成功：将认证后的Authentication对象存入SecurityContext，后续过滤器会根据该对象进行授权校验；

   2. 认证失败：抛出对应异常，由失败处理器（FailureHandler）处理，返回登录失败提示。

6. 6. 授权校验：请求经过授权过滤器（如FilterSecurityInterceptor），根据SecurityContext中的用户权限，与请求所需权限比对，通过则允许访问资源，否则返回403。

九、Shiro和SpringSecurity区别？

面试标准回答

Shiro和SpringSecurity都是Java主流的权限管理框架，核心区别体现在“轻量级vs企业级”，具体对比（重点记核心维度）：

面试补充

选择建议：SpringBoot/SpringCloud项目优先选SpringSecurity；小型项目、非Spring项目选Shiro，开发效率更高。

十、SpringSecurity如何解决跨域问题？

面试标准回答

SpringSecurity解决跨域问题，核心是结合Spring的CORS配置 + 关闭SpringSecurity的CSRF防护（开发环境，生产环境需谨慎），因为SpringSecurity的默认过滤器会拦截跨域请求，需手动配置允许跨域，具体实现有2种方式：

1. 方式一：通过SpringSecurity配置类直接配置CORS（推荐，简洁）：

   @Configuration @EnableWebSecurity public class SecurityConfig { @Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http // 1. 配置CORS，允许跨域 .cors(cors -> cors.configurationSource(corsConfigurationSource())) // 2. 开发环境关闭CSRF（跨域请求会触发CSRF校验，导致请求失败） .csrf(csrf -> csrf.disable()) // 其他配置（授权、认证） .authorizeHttpRequests(auth -> auth.anyRequest().authenticated()); return http.build(); } // 配置CORS规则 @Bean public CorsConfigurationSource corsConfigurationSource() { CorsConfiguration config = new CorsConfiguration(); // 允许跨域的来源（开发环境可设为*，生产环境需指定具体域名） config.addAllowedOrigin("*"); // 允许跨域的请求方法（GET、POST、PUT等） config.addAllowedMethod("*"); // 允许跨域的请求头 config.addAllowedHeader("*"); // 允许携带Cookie（跨域请求默认不携带Cookie） config.setAllowCredentials(true); // 配置生效的路径（所有路径） UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return source; } }

2. 方式二：通过@CrossOrigin注解（局部跨域，适用于单个接口/Controller）：

   // 单个接口跨域 @RestController public class UserController { @CrossOrigin(origins = "*", allowCredentials = "true") @GetMapping("/user/list") public Result userList() { // 接口逻辑 return Result.success(); } } // 整个Controller跨域 @RestController @CrossOrigin(origins = "*", allowCredentials = "true") public class UserController { // 所有接口均允许跨域 }

面试补充

生产环境注意：

1. 不要将allowedOrigin设为*，需指定具体的前端域名（如http://localhost:8080），提升安全性；

2. 若开启CSRF防护，需在前端请求中携带CSRF令牌，否则跨域请求会失败。

十一、SpringSecurity如何对密码进行加密？

面试标准回答

SpringSecurity 5.x后，强制要求对密码进行加密，核心通过PasswordEncoder接口实现，该接口提供加密和密码匹配功能，无需手动编写加密逻辑，具体实现步骤：

1. 1. 配置PasswordEncoder（推荐使用BCrypt加密，自适应加密，安全性最高）：

   @Configuration @EnableWebSecurity public class SecurityConfig { // 配置密码编码器（BCrypt） @Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } }

2. 2. 用户注册时，对密码进行加密存储：

   @Autowired private PasswordEncoder passwordEncoder; // 注册接口 @RequestMapping("/register") public Result register(User user) { // 对明文密码进行BCrypt加密（自动生成盐值，无需手动处理） String encodedPassword = passwordEncoder.encode(user.getPassword()); // 存储加密后的密码到数据库 user.setPassword(encodedPassword); userService.save(user); return Result.success("注册成功"); }

3. 3. 认证时自动匹配密码：SpringSecurity会自动调用PasswordEncoder的matches()方法，将用户登录时输入的明文密码，与数据库中存储的加密密码进行匹配，无需手动校验：

   // 自定义UserDetailsService（查询用户信息） @Service public class CustomUserDetailsService implements UserDetailsService { @Autowired private UserService userService; @Autowired private PasswordEncoder passwordEncoder; @Override public UserDetails loadUserByUsername(String username) { User user = userService.getByUsername(username); // 无需手动匹配密码，SpringSecurity自动校验 return User.withUsername(user.getUsername()) .password(user.getPassword()) // 数据库中的加密密码 .authorities("user:list") .build(); } }

面试补充

1. 常用加密算法：BCrypt（推荐）、MD5、SHA-256，其中BCrypt会自动生成随机盐值，避免相同密码加密后结果一致，安全性最高；

2. 核心优势：PasswordEncoder接口可灵活切换加密算法，无需修改业务逻辑。

十二、什么是单点登录？

面试标准回答

单点登录（Single Sign-On，简称SSO）是一种多系统统一认证机制，核心是：用户在多个相互信任的系统（同一信任域）中，只需登录一次，即可访问所有已授权的系统，无需重复输入账号密码。

比如：企业的OA系统、CRM系统、财务系统，都属于同一企业的系统，用户登录OA系统后，再访问CRM系统时，无需再次登录，直接可访问，这就是单点登录的核心场景。

核心作用：提升用户体验（无需记忆多个账号密码）、简化系统管理（统一管理认证信息，便于权限控制和审计）。

十三、单点登录系统，如果cookie禁用，你们怎么解决?

面试标准回答

SSO默认通常用Cookie存储全局令牌（如JWT、Ticket），若用户禁用Cookie，核心解决方案是将令牌通过URL参数、请求头传递，确保令牌能在多系统间传递，具体有2种常用方式：

1. 方式一：URL参数传递令牌（简单易用，适合小型场景）：

   1. 用户登录认证中心成功后，认证中心生成全局令牌，将令牌拼接在跳转URL后面（如http://systemA.com?token=xxx），跳回目标系统；

   2. 目标系统从URL参数中获取令牌，调用认证中心接口验证令牌合法性，验证通过则允许访问；

   3. 后续用户访问其他系统时，前端手动将令牌拼接在URL参数中，实现令牌传递。

   4. 缺点：URL参数会暴露令牌，安全性较低，需配合HTTPS使用，且令牌不能包含敏感信息。

2. 方式二：请求头传递令牌（推荐，安全性高）：

   1. 用户登录认证中心成功后，认证中心将令牌返回给前端，前端将令牌存储在LocalStorage/SessionStorage中；

   2. 前端发起请求时，通过请求头（如Authorization: Bearer xxx）将令牌传递给后端系统；

   3. 后端系统从请求头中获取令牌，调用认证中心接口验证合法性，验证通过则允许访问。

   4. 优势：令牌不暴露在URL中，安全性高；缺点：需前端配合，每次请求都要携带请求头。

面试补充

补充优化：可结合两种方式，开发环境用URL参数（便捷），生产环境用请求头+HTTPS（安全）；同时设置令牌短期过期，配合刷新令牌机制，进一步提升安全性。

十四、SSO原理（单点登录的过程）

面试标准回答

SSO的核心原理是“统一认证中心 + 全局令牌机制”，所有系统的认证都由认证中心统一处理，多系统之间相互信任，共享令牌信息，具体过程（以系统A、系统B和认证中心为例）：

1. 1. 用户访问系统A，系统A检测到用户未登录，自动跳转到统一认证中心；

2. 2. 用户在认证中心输入账号密码，认证中心校验账号密码合法性（查询数据库）；

3. 3. 认证成功后，认证中心生成一个全局唯一的令牌（如JWT、Ticket），并将令牌返回给前端（禁用Cookie则通过URL/请求头传递）；

4. 4. 前端携带令牌跳回系统A，系统A获取令牌，调用认证中心的“令牌验证接口”，验证令牌合法性；

5. 5. 令牌验证通过，系统A允许用户访问资源，用户无需再次登录；

6. 6. 用户访问系统B时，系统B检测到用户未登录，跳转到认证中心；

7. 7. 认证中心检测到用户已持有合法令牌，无需再次输入账号密码，直接生成系统B的授权信息，跳回系统B；

8. 8. 系统B验证令牌合法性后，允许用户访问资源，实现“一次登录，多系统访问”。

面试补充

核心关键点：认证中心是唯一的登录入口，负责令牌的生成和验证；多系统之间相互信任，无需单独认证，只需验证令牌即可。

十五、SSO如何实现？

面试标准回答

SSO的实现核心是“搭建统一认证中心 + 各子系统集成认证中心”，常用实现方式有3种，其中JWT+认证中心是目前最主流的无状态实现方式：

1. 方式一：JWT + 统一认证中心（推荐，无状态，适合分布式）

   1. 搭建统一认证中心：负责用户认证、JWT令牌生成、令牌验证接口开发；

   2. 子系统集成：各子系统拦截未登录请求，跳转到认证中心；登录成功后，子系统从URL/请求头获取JWT令牌，调用认证中心接口验证令牌，验证通过则允许访问；

   3. 优势：无状态，无需存储会话，减轻服务器压力，适配分布式项目；缺点：令牌无法主动吊销，需配合刷新令牌机制。

2. 方式二：CAS框架实现（有状态，企业级常用）

   1. CAS（Central Authentication Service）是一款开源的SSO框架，自带认证中心，支持Ticket令牌机制；

   2. 实现步骤：部署CAS Server（认证中心），各子系统（CAS Client）集成CAS，配置信任关系；用户登录CAS Server后，获取Ticket，子系统通过Ticket向CAS Server验证，验证通过则允许访问；

   3. 优势：功能完善，支持令牌吊销、单点登出，安全性高；缺点：有状态，需存储会话，部署和配置较复杂。

3. 方式三：基于Session共享（传统方式，不推荐）

   1. 搭建统一认证中心，用户登录后，将用户信息存储在分布式缓存（如Redis）中，生成会话ID；

   2. 各子系统通过会话ID从Redis中获取用户信息，实现会话共享；

   3. 缺点：有状态，依赖分布式缓存，扩展性差，不如JWT方式灵活。

十六、什么是CAS？

面试标准回答

CAS（Central Authentication Service，中央认证服务）是一款开源的企业级单点登录框架，由耶鲁大学开发，核心作用是实现多系统的统一认证，遵循SSO协议，是目前企业级SSO项目中常用的框架之一。

CAS的核心特点：基于“票据（Ticket）”机制，分为CAS Server（认证中心）和CAS Client（子系统客户端）两部分，各子系统无需单独实现认证逻辑，只需集成CAS Client，通过CAS Server完成统一认证，支持单点登录、单点登出、令牌吊销、多用户角色管理等功能，安全性高、功能完善。

面试补充

CAS的核心优势：成熟稳定，适配复杂的企业级场景（如多系统、多角色、高并发）；缺点：部署和配置较复杂，学习成本高于JWT方式。

十七、CAS中3个术语?

面试标准回答

CAS的核心术语有3个，分别对应CAS的核心组件和流程，是理解CAS工作原理的关键：

1. CAS Server（认证服务器）：CAS的核心，即统一认证中心，负责用户身份认证、生成票据（Ticket）、验证票据合法性，是唯一的登录入口，管理所有用户的认证信息。

2. CAS Client（客户端）：集成在各个子系统中的客户端组件，负责拦截子系统的未登录请求，跳转到CAS Server，同时接收CAS Server返回的票据，向CAS Server验证票据，获取用户信息，完成子系统的登录。

3. Ticket（票据）：CAS中的“全局令牌”，由CAS Server生成，用于证明用户已认证成功。分为两种核心票据：

   1. TGT（Ticket Granting Ticket）：长期票据，用户登录CAS Server成功后生成，存储在CAS Server的会话中，用于生成ST；

   2. ST（Service Ticket）：短期票据，用户访问子系统时，CAS Server根据TGT生成ST，子系统用ST向CAS Server验证，验证通过后ST失效。

十八、CAS处理流程?

面试标准回答

CAS的处理流程核心是“TGT+ST票据机制”，分为“登录流程”和“验证流程”，具体步骤（以用户访问子系统A为例）：

一、登录流程（获取TGT）

1. 1. 用户访问子系统A，CAS Client拦截请求，检测到用户未登录，自动跳转到CAS Server的登录页面；

2. 2. 用户在CAS Server输入账号密码，CAS Server校验账号密码合法性（查询数据库）；

3. 3. 认证成功后，CAS Server生成TGT（长期票据），存储在自身会话中（通常存在Redis中），同时生成一个临时的登录成功页面；

4. 4. CAS Server通过登录成功页面，自动向子系统A发起请求，携带ST（短期票据，由TGT生成）。

二、验证流程（验证ST）

1. 1. 子系统A的CAS Client获取ST，向CAS Server发起“票据验证请求”，携带ST和子系统自身的地址；

2. 2. CAS Server验证ST的合法性（检查ST是否由自身生成、是否过期、是否对应正确的子系统）；

3. 3. 验证通过后，CAS Server返回用户的身份信息（如用户名、角色）给子系统A的CAS Client；

4. 4. 子系统A根据用户信息，创建本地会话，允许用户访问资源，登录完成；

5. 5. 当用户访问子系统B时，重复步骤1-4，但CAS Server检测到用户已持有TGT，无需再次输入账号密码，直接生成ST，完成验证。

面试补充

单点登出流程：用户在任意一个子系统登出，子系统通知CAS Server，CAS Server销毁TGT，同时通知所有已登录的子系统，销毁本地会话，实现“一次登出，所有系统都登出”。

十九、什么是Token?

面试标准回答

Token（令牌）是一种身份验证凭证，由服务器生成，返回给客户端，客户端后续发起请求时，携带Token，服务器通过验证Token的合法性，确认用户身份，无需存储会话信息（无状态）。

Token的核心特点：

1. 无状态：服务器无需存储Token相关信息，只需验证Token的签名和有效性，减轻服务器压力，适合分布式项目；

2. 唯一性：每个Token都是全局唯一的，避免伪造；

3. 时效性：Token会设置过期时间，过期后需重新获取，提升安全性；

4. 携带信息：Token中可携带少量用户信息（如用户名、角色），减少数据库查询。

常用场景：接口认证、单点登录（SSO）、移动端APP登录，常用的Token类型有JWT、OAuth2.0中的Access Token。

二十、OAuth是什么？

面试标准回答

OAuth（Open Authorization，开放授权）是一种开放的授权协议，核心作用是“允许第三方应用在不获取用户账号密码的情况下，访问用户在某一系统中的授权资源”，解决第三方应用的授权问题，避免用户密码泄露。

简单来说：比如用微信登录某款小游戏，小游戏无需获取你的微信账号密码，只需通过微信的OAuth授权，获取你的微信昵称、头像等基础信息，即可完成登录，这就是OAuth的核心场景。

目前最常用的是OAuth 2.0版本（OAuth 1.0已淘汰），核心角色有4个：资源所有者（用户）、客户端（第三方应用）、授权服务器（如微信授权服务器）、资源服务器（如微信的用户信息服务器）。

面试补充

OAuth 2.0的核心流程：第三方应用（客户端）向授权服务器请求授权，用户同意授权后，授权服务器返回Token，客户端用Token向资源服务器请求用户资源，实现授权访问。

二十一、介绍下Access Token ?

面试标准回答

Access Token（访问令牌）是OAuth 2.0协议中的核心令牌，由授权服务器生成，用于第三方应用（客户端）访问资源服务器的授权资源，是客户端访问资源的“通行证”。

核心特点和作用：

1. 作用：客户端携带Access Token，向资源服务器请求资源，资源服务器验证Token合法性后，返回对应的资源（如用户信息、接口数据）；

2. 时效性：短期有效（通常1-2小时），过期后无法使用，需重新获取，目的是提升安全性，即使Token泄露，危害范围也有限；

3. 无状态：资源服务器无需存储Token信息，只需验证Token的签名和有效期，即可确认授权合法性；

4. 权限范围：Access Token会绑定具体的权限范围（如只能获取用户昵称、头像，不能获取用户手机号），客户端只能访问授权范围内的资源。

面试补充

Access Token的获取方式：OAuth 2.0提供4种授权模式（授权码模式、密码模式、客户端凭证模式、简化模式），其中授权码模式最常用，通过授权码获取Access Token。

二十二、介绍下Refresh Token?

面试标准回答

Refresh Token（刷新令牌）是OAuth 2.0协议中，配合Access Token使用的长期令牌，核心作用是“在Access Token过期后，无需用户重新授权，即可获取新的Access Token”，提升用户体验。

核心特点和使用流程：

1. 特点：长期有效（通常7天、30天），安全性高，存储在客户端（如后端服务），不暴露在前端，避免泄露；

2. 使用流程：

   1. 1. 客户端通过授权模式，同时获取Access Token（短期）和Refresh Token（长期）；

   2. 2. 当Access Token过期后，客户端携带Refresh Token，向授权服务器发起“刷新Token请求”；

   3. 3. 授权服务器验证Refresh Token的合法性，验证通过后，生成新的Access Token（同时可生成新的Refresh Token），返回给客户端；

   4. 4. 客户端用新的Access Token，继续访问资源服务器，无需用户重新登录授权。

3. 核心优势：避免用户因Access Token过期，频繁重新授权，提升用户体验；同时Refresh Token长期有效，可减少授权流程的重复执行。

面试补充

安全注意：Refresh Token需存储在客户端的后端服务中，不能存储在前端（如LocalStorage），避免泄露；若Refresh Token泄露，攻击者可无限获取Access Token，需及时吊销Refresh Token。

二十三、介绍下JWT？

面试标准回答

JWT（JSON Web Token）是一种基于JSON的无状态令牌，用于在客户端和服务器之间传递身份信息和权限信息，核心特点是“自包含”（Token中包含所有必要的用户信息），无需服务器存储会话，适合分布式项目和无状态认证。

1. JWT的结构（3部分，用“.”分隔，均为Base64编码）：

1. Header（头部）：指定JWT的签名算法（如HS256、RS256）和令牌类型（默认JWT），示例：{"alg":"HS256","typ":"JWT"}；

2. Payload（载荷）：存储用户的核心信息（如用户名、角色、过期时间），分为标准声明和自定义声明，标准声明（如exp：过期时间、iss：签发者），自定义声明（如userId：用户ID）；

3. Signature（签名）：用Header中指定的算法，对Header和Payload进行签名，防止Token被篡改，签名需要密钥（对称加密用密钥，非对称加密用私钥）。

2. 核心特点：

1. 无状态：服务器无需存储Token信息，只需验证签名和过期时间，即可确认合法性；

2. 自包含：Token中携带用户信息，减少数据库查询，提升接口响应速度；

3. 跨语言：基于JSON，支持所有语言（Java、Python、JavaScript等），适配多端（Web、APP）；

4. 不可篡改：签名机制确保Token被篡改后，验证会失败。

3. 常用场景：接口认证、单点登录（SSO）、分布式项目的无状态认证。

面试补充

缺点：Token一旦签发，无法主动吊销，需通过设置短期过期时间+刷新Token机制弥补；Payload部分是Base64编码（可逆），不能存储敏感信息（如密码）。