1. 前言又是新的一周，博主继续来给大家更新 Spring Security 实战教程系列啦～ 通过前面的章节教程从认证到授权，相信大家已经基本了解 Spring Security 的工作原理。
但在前后端分离架构成为主流的今天，传统的 Session-Cookie 认证模式面临跨域限制、服务端状态维护等难题。JWT（JSON Web Token）作为无状态令牌方案，凭借其自包含、易扩展的特性，成为现代分布式系统的首选认证方案。
那么本章节，博主就带着大家一起来进行 Spring Security 前后端分离认证实战，手把手教构建安全的 JWT 认证体系！
2. JWT 基本原理JWT（JSON Web Token） 是一种开放标准（RFC 7519），用于在各方之间以 JSON 对象安全地传输信息。其主要特点包括：
无状态：服务端无需保存会话信息，降低了服务端压力（传统 Session 是保存服务端）
跨域支持：适用于前后端分离应用场景
JWT 通常由三部分组成：Header、Payload 和 Signature。在认证场景中，用户登录后服务器生成一个包含用户信息的 Toke ...
前言通过上一章节的讲解，相信大家已经认识了Spring Security安全框架。在我们创建的第一个演示项目中，相信大家也发现了默认表单登录的局限性。Spring Security默认提供的登录页虽然快速可用，但存在三大问题：
界面风格与业务系统不匹配
登录成功/失败处理逻辑固定
缺乏扩展能力（如验证码、多因子认证）
本章节我们将对Spring Security默认表单进行登录定制，并深度改造处理逻辑。
改造准备在之前的Maven项目中创建第二个子模块，命名为login-spring-security。由于需要自定义登录页，还需要引入thymeleaf模板框架：
1234<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId></dependency>
完整的Maven项目结构如下：
开始登录页改造创建自定义登录页首先 ...
1. 前言在我们日常开发的后台系统中，”Remember-Me“（记住我）功能是一种常见的安全增强机制，允许用户在关闭浏览器后仍然保持登录状态，而无需重新输入用户名和密码。Spring Security提供了多种Remember-Me方案，最常用的是基于哈希的Token方案和持久化令牌方案。
本章节博主将详细讲解这两种方案的实现，带大家快速入门！在实际开发中，小伙伴们可根据各自需求进行改造。
2. Remember-Me机制概述在Spring Security中，Remember-Me的核心作用是在会话失效后依然允许用户自动登录。其基本工作流程（以更常用的持久化令牌方案为例）如下：
用户登录成功后，如果勾选了”记住我”，服务器会创建一个Remember-Me Token，并存储在客户端的Cookie中。
当用户的会话失效后，系统会检查Cookie是否存在并有效：
如果有效，则自动完成登录；
如果无效或过期，则用户需要重新认证。
Spring Security主要提供两种Remember-Me方案：
方案
实现类
特点
基于Token（默认方案）
TokenBas ...
1. 前言在上一章节中，我们讲解了Spring Security基于内存的用户认证，也提到了实际开发生产中更多使用的还是基于数据库的动态用户认证，因为在企业应用中，用户、角色、权限管理通常都存储在数据库中。
本章节博主将带着大家以MySQL数据库为例，从用户（sys_user）、角色（sys_role）、用户角色（sys_user_role）、系统菜单资源（sys_menu）、角色菜单（sys_role_menu）表出发，演示如何使用Spring Security动态加载用户信息、角色，实现基于数据库的RBAC角色模型认证。
2. 数据库表结构说明本文示例基于整理的MySQL表结构，其中主要表结构如下（大家可以根据自己的业务需求进行扩展）：
sys_user：存储用户信息，字段包括user_id、login_name、password等
sys_role：存储角色信息，字段包括role_id、role_name（角色名称）、role_key（角色标识）等
sys_user_role：关联用户和角色的中间表
sys_menu：系统菜单资源表，字段包括menu_id、menu_name（ ...
1. 前言在微服务与分布式架构日益普及的今天，传统的单一凭证（用户名+密码） 已经难以满足企业对于身份验证的高安全性需求。多因素认证（Multi‑Factor Authentication，简称 MFA） 通过“用户知道的东西”（如密码）+“用户拥有的东西”（如动态验证码）或“用户自身的一部分”（如指纹）三种因素的组合，大幅提升了系统防护能力。
比如我们常见的 GitHub、腾讯云等就开启了 MFA。GitHub 开启 MFA 后可以使用 Authenticator 应用扫描，而腾讯云则需要短信验证码来进行校验。
本章节笔者将带领大家深入解析 MFA，并基于 Spring Security 6，结合 MySQL 与 MyBatis-Plus，从理论到实战，快速构建一套企业级的 MFA 认证方案。
2. 为什 ...
1. 前言在前面学习的章节中，相信大家一定看过一个配置.csrf()。回忆一下之前使用Spring Security默认页登录的时候，该配置Spring Security默认开启，主要用于CSRF防护。如果你现在还不了解什么是CSRF防护，没关系，通过本章节，博主带着大家一起深入学习这个知识点～
2. CSRF攻击原理跨站请求伪造（CSRF）是一种利用受信任用户的身份，诱使用户在已登录的应用中执行非预期操作的攻击手段。
当用户在某个站点（如银行）登录并持有有效Session Cookie后，攻击者可通过精心构造的请求（例如隐藏在图片或表单中的POST请求）在用户不知情的情况下向该站点发起请求，并携带用户的Cookie，从而完成诸如转账、修改邮箱等敏感操作。
2.1 攻击原理图解
用户访问了A站点，获得了Session或Cookie后，用户不经意间访问到了恶意网站，此刻恶意网站伪造对A站点的危险请求
2.2 攻击示例下面示例展示了一个最常见的CSRF攻击场景：用户登录了https://bank.com后，攻击者在自己的网站https://evil.com上放置如下HTML片段：
1 ...
1. 前言今天博主又抽空来给小伙伴们更新Spring Security教程啦！上个章节中我们讲解了如何通过数据库实现基于数据库的动态用户认证。大家可能发现了，项目中是基于RBAC角色模型的权限控制，虽然能满足大多数场景，但在面对复杂、细粒度的权限需求时可能会力不从心。基于属性的访问控制（ABAC）模型则通过评估用户、资源、环境等多种属性，实现更加灵活的权限控制。
例如，某个菜单的访问可能不仅取决于用户角色，还取决于用户的部门、时间或其他属性。因此，需要在权限验证时动态获取这些属性并进行评估。那么本章节我们就来讲解基于数据库的ABAC属性权限模型实战开发。
2. 权限决策依据既然谈到了RBAC和ABAC两个模型，就给大家介绍下两者间的区别：
RBAC
核心思想：以角色作为权限管理的核心，每个用户被赋予一个或多个角色，而角色与权限之间存在固定的映射关系。
决策依据：当用户请求访问资源时，系统根据用户所属角色所拥有的权限进行校验。
粒度：粒度相对较粗，因为权限是绑定在角色上的，无法针对单个请求条件进行动态决策。
ABAC
核心思想：以属性（Attribute）为基础，利用用户属性、资源属 ...
1. 前言在 Web 应用安全体系中，会话管理是认证授权后的重要防线。攻击者常通过会话劫持与会话固定突破系统边界，而业务系统则面临并发滥用带来的资源风险。
Spring Security 的会话管理模块由 SessionManagementFilter 与一系列 SessionAuthenticationStrategy 共同协作，负责在用户登录或访问受保护资源时执行统一的会话检查与策略。默认情况下，框架允许单个用户拥有无限多个并发会话，而在每次登录时会执行会话固定保护策略，将旧 Session ID 迁移到新 Session 中，以防止攻击者利用已有的 Session ID 进行劫持。
在本章节，笔者将基于 Spring Security 6，深入解析会话管理的安全实践。
2. 会话固定攻击防护原理2.1 攻击概述会话固定（Session Fixation）指攻击者诱导受害者在已知的 Session ID 下登录，随后持该 ID 进行未授权操作。Spring Security 通过会话固定保护策略，在每次用户登录后刷新 Session ID 来防御此类攻击。
攻击流程解析
2.2 ...
1. 前言在日常开发中，跨域资源共享（CORS）已成为前端与后端分离架构的必备能力。正确配置 CORS 是后端安全边界的重要一环。但安全与便利的天平往往难以把握——过于宽松的配置可能导致敏感数据泄露，过于严格的策略又会影响正常业务交互。本文我们继续《Spring Security 实战教程》，讲解 CORS 安全配置。
2. 背景与原理概述跨域请求是指浏览器在一个域（Origin A）加载的脚本访问另一个域（Origin B）的资源。为保护用户数据，浏览器默认禁止跨域访问，除非服务器在响应头中明确允许。CORS 机制通过 Access-Control-Allow-* 系列头部，告诉浏览器何种跨域请求被允许，从而实现安全的跨域通信。
2.1 预检请求全流程当发起“简单请求”时（如 GET/POST 且只有简单头部），浏览器会直接带上 Cookie 等凭证；对复杂请求（如 PUT/DELETE、携带自定义头部）则先发起一次预检（OPTIONS）请求，确认服务器同意后才发送实际请求。
2.2 关键响应头说明Access-Control-Allow-* 响应头主要包括以下几个：
响应头 ...
1. 前言在微服务与前后端分离架构中，第三方社交登录已成为提升用户体验的重要功能。社交登录可以有效降低用户注册成本，同时利用第三方平台的账号体系，实现快速认证与信息获取。Spring Security 6 作为 Java 生态中的安全框架，通过 OAuth2 协议简化了第三方认证的集成流程。
本章节笔者将通过完整代码案例，讲解如何基于 Spring Security 6 实现 GitHub 和 Gitee 的社交登录功能。
2. 原理分析回顾上一章节介绍的 OAuth 2.0 授权码流程（最新 Spring Security 实战教程（十四）OAuth2.0 精讲 - 四种授权模式与资源服务器搭建）：
其主要流程包括：
跳转授权：客户端（我们的网站）将用户重定向至第三方授权服务器的授权端点，携带 client_id、redirect_uri、scope 等参数。
用户登录并同意：用户在第三方平台完成登录后，同意授权给客户端指定权限。
回调获取授权码：授权服务器重定向回客户端注册的 redirect_uri，并在查询参数中附带 code。
交换令牌：客户端后端使用 code、clie ...
