SpringSecurity认证授权流程

一、Spring Security 完整核心执行流程

1. 整体核心思想

Spring Security 底层是纯过滤器链架构，所有请求全部经过一串固定顺序的 Filter，层层校验，最终完成 认证（登录）→ 授权（权限校验）。

全程基于 Servlet 原生 Filter，不依赖 SpringMVC 拦截器，优先级更高。

2. 完整执行链路 🔴

1. 客户端发起接口请求，进入 Servlet 容器

2. 进入 Spring Security 核心入口 FilterChainProxy

3. 经过多层内置过滤器：预处理、跨域、会话、csrf、登录校验

4. 认证环节：校验用户名密码 / Token 是否合法，生成 Authentication 认证对象，存入安全上下文

5. 授权环节：读取当前用户角色、权限标识，判断是否允许访问当前接口

6. 校验全部通过，请求进入 Controller；失败直接返回 401未登录 / 403无权限

二、常用核心过滤器 🔴

过滤器执行从上到下有序执行

1. WebAsyncManagerIntegrationFilter：异步请求上下文管理，保证异步线程也能获取登录信息

2. CorsFilter：统一处理跨域

3. CsrfFilter：CSRF 跨站伪造防护（前后端分离项目一般关闭）

4. UsernamePasswordAuthenticationFilter：登录认证核心过滤器，拦截登录接口，校验账号密码，生成认证信息

5. RememberMeAuthenticationFilter：记住我自动登录

6. ExceptionTranslationFilter：异常统一捕获，处理401、403权限异常

7. FilterSecurityInterceptor：最后一道过滤器，负责接口资源授权、权限匹配，决定是否放行接口

极简总结：前面过滤器做预处理和登录认证，最后一个 Filter 专门做授权。

三、认证和授权的区别 🔴

1. 认证 Authentication

你是谁？

校验用户身份是否合法，也就是登录校验。

校验内容：账号密码、Token有效性、是否过期、是否黑名单。

结果：认证成功后，生成用户身份、角色、权限信息存入上下文。

2. 授权 Authorization

你能干什么？

用户登录成功后，校验当前用户是否拥有访问该接口/资源的权限。

基于角色、权限标识、菜单资源、数据权限做拦截判断。

3. 一句话区分

认证是验身份（是否登录），授权是验权限（能不能访问）；先认证，后授权。

四、Spring Security 如何实现认证与授权？

1. 认证实现核心组件

• Authentication：当前用户认证信息对象

• AuthenticationManager：认证管理器，统一入口

• UserDetailsService：最核心扩展点，开发者自定义实现，查询数据库用户、角色、权限

• PasswordEncoder：密码加密校验

2. 授权实现核心组件

• GrantedAuthority：权限标识

• FilterSecurityInterceptor：拦截所有资源做授权判断

• @PreAuthorize("hasPermission()")：注解式接口权限控制

3. 自定义流程（企业常用）

如果项目用 JWT 登录，会废弃原生账号密码登录流程：

1. 自定义 JWT 过滤器，解析请求头 Token

2. 校验 Token 合法后手动封装 Authentication

3. 存入 SecurityContext 上下文

4. 后续框架自动走授权逻辑

五、Spring Security vs Shiro 优缺点对比 🔴

1. Spring Security

优点

• Spring 官方框架，适配 SpringBoot、微服务生态最好，无缝集成

• 底层安全防护极强：自带防csrf、xss、会话固定、暴力破解

• 原生支持 OAuth2.0、单点登录、网关鉴权、多租户

• 支持细粒度接口权限、数据权限、字段权限

缺点

• 框架较重、过滤器链复杂、学习成本高

• 默认配置多、侵入性强，容易和自定义登录冲突

• 前后端分离项目需要大量改配置

2. Shiro

优点

• 轻量、简洁、上手简单

• 架构独立，不依赖 Spring

• API 简单，自定义登录、权限非常方便

缺点

• 停止更新，生态老旧

• 微服务、OAuth2、网关适配差

• 底层安全防护薄弱，需要自己补全

3. 选型结论 🔴

传统单体后台、简单权限系统选 Shiro；微服务、网关统一鉴权、OAuth2 授权、金融高安全场景统一使用 Spring Security。

六、微服务：Spring Security + OAuth2 + 网关 统一鉴权方案 🔴

微服务架构下，不会每个服务单独登录鉴权，标准落地架构如下：

1. 整体架构角色

• 授权中心（Auth Server）：基于 Spring Security + OAuth2.0，专门负责登录、签发 JWT、刷新令牌

• 网关（Gateway）：统一入口，做全局 Token 校验、黑名单拦截（只校验 Token 合法性、是否过期）

• 资源服务：各个业务微服务，只负责校验权限，不处理登录

2. 完整流程

1. 用户登录，请求统一授权中心

2. 授权中心基于 OAuth2 授权码/密码模式校验账号，签发 JWT 令牌

3. 前端持有 Token，后续所有请求统一经过网关

4. 网关层统一拦截：校验 Token 合法性、是否过期、是否在黑名单，只做认证，不做权限授权

5. 网关校验通过，解析用户ID、角色、权限，写入请求头转发到下游微服务

6. 下游微服务完成接口级权限授权

3. 核心答疑（重点）

问题：下游服务权限校验是否可以完全自定义？是否需要依赖/配置 Spring Security？

终极答案：完全可以自定义，下游服务可以彻底不引入 Spring Security 依赖、零配置。

行业分为两种落地方案，中小厂90%用方案一：

方案一：网关认证 + 下游自研授权（主流、推荐）

下游服务无需引入 Spring Security、无需任何框架配置。

实现方式：基于 SpringMVC 拦截器 + 自定义权限注解 + AOP

原理：网关已经解析好用户角色、权限并放入请求头，下游拦截器读取请求头信息，对比接口所需权限标识，完成授权校验。

优点：下游服务轻量化、无框架侵入、适配所有业务，和你自研RBAC项目完全一致。

方案二：网关认证 + 下游 Spring Security 授权（大厂标准）

大型微服务、金融、多租户SaaS项目，下游统一引入 Spring Security 资源服务依赖，仅做少量配置。

原理：接收网关透传的用户信息，依托框架自带的 @PreAuthorize 注解完成接口授权，统一技术规范，安全性、规范性更强。

缺点：引入额外依赖、增加学习和维护成本。

4. 核心优势

• 登录鉴权统一收口，不用每个服务写登录逻辑

• 网关拦截非法请求，保护下游服务安全

• 两种授权方案灵活可选，适配大小项目

七、总结

普通C端系统和简单后台管理系统，只需要基础的登录、角色、接口权限，使用拦截器+AOP自研RBAC更加轻量、灵活，避免框架过度设计。

但在微服务架构、需要OAuth2第三方授权、多租户SaaS、金融合规、网关统一鉴权的场景下，Spring Security 生态成熟、安全底座完善，是行业标准方案，能够降低自研安全漏洞风险，统一整体架构规范。

同时微服务架构中并非所有服务都需要依赖Security，中小项目可由网关统一认证，下游业务服务通过自定义拦截器完成权限校验，减少框架侵入和冗余。