一个应用两种安全spring-addons如何在同一工程中优雅配置UI会话与REST API双过滤链【免费下载链接】spring-addonsAdditional Spring Boot auto-configuration for OAuth2 / OpenID REST项目地址: https://gitcode.com/gh_mirrors/sp/spring-addons在真实的 Spring Boot 业务系统中我们经常面临一个两难选择既要为用户提供带登录页面的 Web UI又要为前后端分离的前端提供纯 REST API。传统做法往往只能二选一或者用大量 Java 代码手工堆砌两条安全配置。spring-addons 项目Additional Spring Boot auto-configuration for OAuth2 / OpenID REST通过双过滤链Security Filter Chain自动配置让同一个应用同时具备 UI 会话认证与 REST API JWT 认证而且几乎不需要编写任何安全代码。本文面向新手带你理解双过滤链的原理、配置方法与最佳实践。为什么一个应用需要两条安全过滤链首先理解 Spring Security 的核心概念安全过滤链是一组按顺序执行的过滤器决定请求是否需要认证、使用哪种认证方式。传统方案有两种极端纯 session 方案所有请求都走会话 CookieREST API 被302重定向到登录页前端无法解析 JSON体验极差。纯 JWT 方案所有请求都要带 Bearer Token浏览器直接访问 UI 页面却拿不到令牌页面无法打开。而真实应用往往是页面给人看接口给程序调UI 需要 session CSRF 保护 登录登出REST API 需要无状态 JWT 校验 返回 401。两条过滤链各管一摊正是 spring-addons 的优雅之处。spring-addons 双过滤链是如何自动配置的在 spring-addons-starter-oidc 启动器中spring-addons 基于配置文件自动注册两条SecurityFilterChainBean你无需手写配置类。第一条UI 客户端过滤链session 会话认证由 SpringAddonsOidcClientWithLoginBeans.java 注册Order(Ordered.LOWEST_PRECEDENCE - 1)优先级较高启用 OAuth2 登录oauth2Login与登出启用 session 会话与 CSRF 防护未认证请求返回 302 重定向到登录页通过security-matchers属性只匹配 UI 相关路径如/login/**、/ui/**、/swagger-ui/**第二条REST API 资源服务器过滤链JWT 无状态认证由 SpringAddonsOidcResourceServerBeans.java 注册Order(Ordered.LOWEST_PRECEDENCE)优先级最低使用JwtDecoder校验 Bearer Token不依赖 session禁用 CSRF无登录登出逻辑未认证请求返回 401不设置 matcher兜底处理所有未被客户端链匹配的请求两条链一高一低、一窄一宽组合起来正好覆盖全部请求实现一个应用两种安全。零 Java 代码双过滤链的最快配置方法这是 spring-addons 最大的亮点配置双过滤链不需要写任何 Java 安全配置类。示例工程 resource-server_with_ui 中的 WebSecurityConfig.java 几乎是空的只有EnableMethodSecurity注解。全部配置都在 application.yml 中完成com: c4-soft: springaddons: oidc: ops: - iss: ${issuer-uri} authorities: - path: $.realm_access.roles client: security-matchers: # 客户端过滤链只匹配这些路径 - /login/** - /oauth2/** - / - /ui/** - /swagger-ui.html - /swagger-ui/** - /logout/** permit-all: - /login/** - /oauth2/** - /logout/** - /ui/** - /swagger-ui/**配置要点就两个client.security-matchers告诉客户端过滤链你只管这些 UI 路径其余路径自动落入资源服务器链。ops[].iss与authorities声明信任的认证服务器Issuer与角色提取路径支持 Keycloak、Auth0、Cognito 等多个异构身份源。UI 与 API 如何协同工作在双过滤链架构下浏览器本身不是OAuth2 客户端它通过 session Cookie 访问 UIUI 后端Thymeleaf Controller内部再用RestClient携带 session 中的 Token 去调用 REST API。示例工程 resource-server_with_ui 完整演示了这一模式用户访问/ui/greet→ 走客户端过滤链 → session 认证 → 页面加载页面通过RestClient调/api/greet→ 走资源服务器链 → JWT 校验 → 返回数据页面中展示的用户身份、权限列表、登出与Invalidate Session按钮正是 session 会话认证的直观体现而页面背后的数据则来自 JWT 保护下的 REST API。双过滤链的进阶技巧BFF 场景如果你是前后端分离架构可参考 oauth2-bff-servlet 示例将后端同时作为 OAuth2 客户端BFF与资源服务器前端 JS 通过/login-options获取登录入口见 BffController.java。登出双会话用户同时拥有应用 session 与身份服务器 session完整登出需要同时终止两者。spring-addons 支持 RP-Initiated Logout并通过属性配置登出重定向路径post-logout-redirect-path。CSRF 差异化UI 链必须开启 CSRF可配置csrf: cookie-accessible-from-js方便 JS 读取REST 链自动关闭无需干预。结语spring-addons 用两条自动配置的过滤链把UI 会话安全与REST API JWT 安全优雅地整合进同一个工程让开发者摆脱重复的安全配置代码把精力聚焦在业务上。无论你是要搭建带管理后台的业务系统还是构建前后端分离的 BFF 网关这套一个应用两种安全的配置方案都值得一试——只需一份application.yml两条过滤链即刻生效。【免费下载链接】spring-addonsAdditional Spring Boot auto-configuration for OAuth2 / OpenID REST项目地址: https://gitcode.com/gh_mirrors/sp/spring-addons创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考