2. 编程语言-Java-Spring Security基础

文章目录前言一、spring-security-oauth2二、spring-security-jwt三、OAuth2 详解一、从门禁卡说起OAuth2 到底解决了什么问题1.1 一个你每天都遇到的场景1.2 传统方式的致命缺陷1.3 OAuth2 到底是什么二、四个人一台戏OAuth2 的核心角色三、令牌三兄弟Access Token、Refresh Token 和 JWT3.1 Access Token —— 门禁卡3.2 Refresh Token —— 换卡凭证3.3 JWT —— 自包含令牌四、四大授权模式选对武器才能打赢仗4.1 授权码模式Authorization Code—— 王者完整流程图 关键问题为什么叫授权码模式为什么要有 code 这一步4.2 简化模式Implicit—— 被时代抛弃的快枪手4.3 密码模式Resource Owner Password—— 已死4.4 客户端凭证模式Client Credentials—— 机器人的世界4.5 四种模式对比速查表五、PKCE给授权码模式加一层装甲5.1 授权码模式的隐患5.2 PKCE 做了什么5.3 OAuth 2.1 的规定六、Spring Security 实战10 分钟搭一个 OAuth2 授权服务器6.1 项目依赖6.2 授权服务器配置 6.3 资源服务器配置 6.4 资源接口 6.5 配置 application.yml 6.6 验证流程七、细说 Token 安全Access Token 过期了怎么办7.1 Token 生命周期的设计哲学 7.2 Refresh Token 轮转Rotation7.3 Token 存储前端到底该放哪八、OAuth2 JWT 深度融合从原理到代码8.1 JWT 的结构深入8.2 资源服务器如何验证 JWT 8.3 手动解析 JWT不用 Spring Security 8.4 自定义 JWT 中的 Claims九、生产环境的七大安全最佳实践9.1 始终使用 HTTPS9.2 Token 不存前端9.3 最小权限原则9.4 验证 redirect_uri9.5 使用 state 参数防 CSRF9.6 启用 PKCE即便是机密客户端9.7 监控异常 Token 使用十、面试八股速通高频问题一网打尽10.1 OAuth2 的四种角色是什么10.2 授权码模式为什么要先发 code 再换 token10.3 PKCE 解决了什么问题原理是什么10.4 JWT 和 OAuth2 是什么关系10.5 Access Token 过期了怎么办10.6 Refresh Token 轮转是什么10.7 如何在微服务之间传递 token10.8 OAuth2 和 SSO单点登录是什么关系10.9 Cookie 和 Token 两种认证方式的区别写在最后前言Spring Security‌spring-security-oauth2spring-security-jwt一、spring-security-oauth2各版本的名称及发布日期版本适用 Spring Boot适用 Spring Security状态备注‌‌2.5.x2.5.x - 2.7.x5.5.x - 5.7.x‌维护中推荐稳定版‌2.4.x2.4.x - 2.6.x5.4.x - 5.6.x已弃用建议升级‌2.3.x2.3.x - 2.5.x5.3.x - 5.5.x已弃用不推荐‌2.2.x2.2.x - 2.4.x5.2.x - 5.4.x已弃用仅旧项目‌2.1.x2.1.x - 2.3.x5.1.x - 5.3.x已弃用不推荐Spring Boot 2.7.x JDK 8‌的环境推荐版本‌dependencygroupIdorg.springframework.security.oauth/groupIdartifactIdspring-security-oauth2/artifactIdversion2.5.2.RELEASE/version!-- 最新稳定版 --/dependencySpring Security‌ 版本匹配dependencygroupIdorg.springframework.security/groupIdartifactIdspring-security-core/artifactIdversion5.7.6/version!-- 推荐版本 --/dependency注意事项‌Spring Security OAuth2 已弃用‌官方推荐迁移到 ‌Spring Authorization Server‌Spring Security 5.7 内置新项目建议直接使用 spring-security-oauth2-authorization-serverSpring Boot 3.x‌JDK 8 兼容性‌Spring Security OAuth2 2.5.x 仍支持 JDK 8如需升级到 Spring Boot 3.x需切换至 JDK 17‌常见问题‌如果遇到 NoSuchMethodError检查依赖冲突如旧版 spring-security-jwt推荐使用 spring-security-oauth2-autoconfigure 简化配置迁移建议‌如果计划升级可参考以下路径短期方案‌继续使用 OAuth2 2.5.x维护模式长期方案‌迁移到 ‌Spring Authorization Server‌需要 Spring Boot 3.xSpring Authorization Server‌二、spring-security-jwt版本选择‌‌spring-security-jwt‌ 最终稳定版dependencygroupIdorg.springframework.security/groupIdartifactIdspring-security-jwt/artifactIdversion1.1.1.RELEASE/version!-- 官方最后维护版本 --/dependency兼容性说明‌需搭配 spring-security-oauth2 2.5.x 使用如 2.5.2.RELEASE。不支持 Spring Boot 3.x 或 JDK 17。‌2. 基础配置示例‌‌JWT 密钥配置‌JwtConfig.javaConfigurationpublicclassJwtConfig{Value(${jwt.secret})privateStringsecret;BeanpublicJwtAccessTokenConverterjwtAccessTokenConverter(){JwtAccessTokenConverterconverternewJwtAccessTokenConverter();converter.setSigningKey(secret);// 设置签名密钥returnconverter;}BeanpublicTokenStoretokenStore(){returnnewJwtTokenStore(jwtAccessTokenConverter());}}需在 application.properties 中配置 jwt.secretyour-256-bit-secret。‌OAuth2 资源服务器配置‌ResourceServerConfig.javaConfigurationEnableResourceServerpublicclassResourceServerConfigextendsResourceServerConfigurerAdapter{Overridepublicvoidconfigure(HttpSecurityhttp)throwsException{http.authorizeRequests().antMatchers(/api/public/**).permitAll().anyRequest().authenticated();}}‌3. 生成和解析 JWT 令牌‌‌生成令牌授权服务器端‌JwtTokenEnhancer.javaclassJwtTokenEnhancerimplementsTokenEnhancer{OverridepublicOAuth2AccessTokenenhance(OAuth2AccessTokenaccessToken,OAuth2Authenticationauthentication){MapString,ObjectadditionalInfonewHashMap();additionalInfo.put(organization,example-org);((DefaultOAuth2AccessToken)accessToken).setAdditionalInformation(additionalInfo);returnaccessToken;}}‌解析令牌资源服务器端‌JwtUtils.javaclassJwtUtils{publicstaticClaimsextractClaims(Stringtoken,Stringsecret){returnJwts.parser().setSigningKey(secret.getBytes()).parseClaimsJws(token).getBody();}}‌4. 注意事项‌密钥安全‌替换 JwtAccessTokenConverter 的签名逻辑。依赖冲突‌避免引入 jjwt 旧版本如 0.9.x可能引发 NoSuchMethodError。迁移建议‌新项目推荐使用 spring-security-oauth2-authorization-server jjwt 0.12.x。jwt三、OAuth2 详解朋友老周被一个需求卡住了新系统要访问老系统的用户数据两边的鉴权怎么搞总不能把老系统密码直接发给新系统吧我说你这场景有现成的实现方案——OAuth2核心思路就三句话用户不暴露密码第三方拿一张有权限、有时效的令牌去访问资源令牌过期了还能静默续上不用重新登录。老周一拍大腿“懂了就是发张门禁卡”门禁卡的比喻很贴切但除了架构师恐怕大多数开发者对 OAuth2 的认知也只是停在了这个比喻上。下面的内容不仅停留在会用还能把核心原理和最佳实践讲得清清楚楚。一、从门禁卡说起OAuth2 到底解决了什么问题1.1 一个你每天都遇到的场景假设你入住一家酒店前台给了你一张门禁卡。这张卡有以下几个特点只对特定房门有效你只能进你的房间不能进别人的有时间限制过了退房时间就打不开了能干什么是确定的开门可以但不能用它去餐厅签单随时可以挂失前台可以把卡作废这张门禁卡就是一种授权机制。现在把这个场景搬到互联网世界你打开一个叫咕咚笔记的第三方应用它说可以用微信账号登录。你点了授权微信给你弹了个确认框“咕咚笔记申请获取你的昵称和头像”。你点了同意然后咕咚笔记就能拿到你的微信昵称和头像了。这个过程是怎么实现的答案是OAuth2。1.2 传统方式的致命缺陷在没有 OAuth2 的年代第三方应用想要访问你在另一个服务上的数据只能这样做你 → 告诉咕咚笔记你的微信账号密码 → 咕咚笔记拿着你的密码去微信服务器登录 → 拿到你的数据问题在哪你把微信的密码给了咕咚笔记。咕咚笔记是好人还好说但如果它把密码存了明文呢如果它不止读取了昵称头像还偷偷翻了你的聊天记录呢如果你在 10 个应用里都用了这种给密码的方式改一次密码 10 个应用全部失效OAuth2 的解决思路非常朴素让用户在不暴露自己密码的情况下授权第三方应用访问自己在某个服务上的受保护资源。你 → 在微信授权页点同意 → 微信发给咕咚笔记一张临时门禁卡 → 咕咚笔记拿卡访问你的昵称头像你的密码从头到尾只有你知道微信服务器知道。咕咚笔记拿到的只是一个有时效性、有权限范围的令牌。1.3 OAuth2 到底是什么OAuth2Open Authorization 2.0是一个授权框架它允许第三方应用在资源拥有者的授权下获取对受保护资源的有限访问权限。注意这两个关键词——授权而非认证有限而非无限。概念通俗解释认证Authentication“你是谁”——出示身份证授权Authorization“你能干什么”——刷门禁卡进房间OAuth2 主要解决的是授权问题虽然在实际使用中它经常被用来做认证也就是用微信登录这类场景但那其实是基于 OAuth2 之上的扩展OpenID Connect也就是我们常说的 OIDC。二、四个人一台戏OAuth2 的核心角色在深入流程之前你必须先把这四个角色刻在脑子里。整个 OAuth2 就是这四个角色之间的交互。┌──────────────┐ ┌──────────────────┐资源拥有者Resource Owner用户本人。拥有数据的所有权。客户端Client第三方应用。想要访问用户数据的那一方。授权服务器Authorization Server负责认证用户并颁发令牌的服务。资源服务器Resource Server存放用户资源的服务验证令牌后提供数据。在实际的工程实现中授权服务器和资源服务器经常是同一个系统的不同模块但它们在 OAuth2 协议中是逻辑上独立的角色。小贴士面试的时候面试官经常问OAuth2 有哪几个角色这是一道送分题四个角色一个都不能少。三、令牌三兄弟Access Token、Refresh Token 和 JWT在正式进入授权流程之前我们先认识 OAuth2 中最核心的三个令牌概念。3.1 Access Token —— 门禁卡Access Token是 OAuth2 最核心的令牌。客户端拿着它去资源服务器请求数据资源服务器验证它有效就返回数据。它的特点短期有效通常是几十分钟到几小时包含权限信息能访问什么、不能访问什么对客户端不透明客户端不需要也不应该试图解析它的内容3.2 Refresh Token —— 换卡凭证Refresh Token用于在 Access Token 过期后换取新的 Access Token而不需要让用户重新授权。为什么要这样设计因为 Access Token 是频繁在网络上传输的泄露风险大所以设置较短的有效期。Refresh Token 只在与授权服务器通信时才使用暴露面小得多所以可以设置较长的有效期几天到几个月。3.3 JWT —— 自包含令牌JWTJSON Web Token不是 OAuth2 协议要求的但在实际落地中极其常见。它是一种自包含的令牌格式eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMDAxIn0.xxxxxxxxxxxxxxxxxx为什么 JWT 和 OAuth2 常常一起出现因为传统的 Access Token 可能只是一个随机字符串“不透明令牌”资源服务器每次收到这种令牌都需要去授权服务器校验。而 JWT 本身携带了用户信息和签名资源服务器可以自己验证 JWT 的有效性不需要每次都远程调用授权服务器——这叫无状态验证性能更好。关键区分OAuth2 是授权协议定义的是怎么发令牌、怎么用令牌JWT 是令牌格式定义的是令牌里写什么、怎么签名。两者不是同一个层面的东西。四、四大授权模式选对武器才能打赢仗OAuth2 定义了四种授权模式Grant Type。这是整个 OAuth2 最核心的知识点也是面试中必考的。OAuth2 四种授权模式4.1 授权码模式Authorization Code—— 王者这是最经典、最安全、使用最广泛的模式。如果你只记住一种就记这一种。完整流程图资源拥有者 客户端 授权服务器 资源服务器关键问题为什么叫授权码模式为什么要有 code 这一步这是面试中的高频追问。答案是安全——确保令牌只发给真正的后端服务器而不是浏览器。具体来说code 是通过**浏览器重定向**传递的会暴露在 URL 中如果用code直接当令牌用任何一个看到 URL 的人都能拿它访问数据但code是一次性的而且换 token 时需要带上client_secret客户端密钥client_secret 只存在后端服务器上浏览器里没有所以即使别人截获了code没有client_secret也换不到真正的 Access Token**Authorization Code 流程的核心安全逻辑就是code 通过不安全的渠道浏览器传输但换 token 的操作只通过安全的渠道后端到后端完成。**浏览器不安全通道 后端服务器4.2 简化模式Implicit—— 被时代抛弃的快枪手简化模式省略了用 code 换 token这一步授权服务器直接把 Access Token 返回给了浏览器。为什么被抛弃因为 Access Token 直接暴露在浏览器端浏览器的 URL 片段#access_tokenxxx虽然不会发给服务器但可以被 JavaScript 读取浏览器的历史记录、第三方脚本、浏览器插件都可能泄露这个 token没有client_secret的保护任何一个拿到 token 的人都能用OAuth 2.1 已经明确不推荐使用 Implicit 模式改为推荐带 PKCE 的授权码模式。4.3 密码模式Resource Owner Password—— 已死用户直接把用户名和密码交给客户端客户端拿它们去授权服务器换 token。这又回到了我们最开始说的那个问题你把密码给了第三方。只有一个场景勉强可以用客户端和授权服务器是同一家公司的产品比如微信 App 和微信服务端。即便如此OAuth 2.1 也已经将其标记为废弃。4.4 客户端凭证模式Client Credentials—— 机器人的世界当客户端本身就是资源拥有者不涉及用户的时候使用。比如后端微服务 A 调用微服务 B 的 API定时任务访问自己的数据这种模式最简单客户端拿自己的client_idclient_secret直接去授权服务器换一个 Access Token。4.5 四种模式对比速查表模式适用场景安全性OAuth 2.1 状态是否涉及用户授权码模式Web 应用有后端⭐⭐⭐⭐⭐✅ 推荐是简化模式纯前端 SPA⭐⭐❌ 不推荐是密码模式高度可信应用⭐❌ 废弃是客户端凭证模式服务间调用⭐⭐⭐⭐✅ 推荐否五、PKCE给授权码模式加一层装甲如果你只了解了上面四种模式面试官很可能追问“那 PKCE 是什么”5.1 授权码模式的隐患即使是授权码模式也存在一个攻击场景攻击者在自己设备上发起授权流程拿到 code攻击者在受害者的应用回调 URL 中拦截到 code比如通过恶意 App 注册了相同的回调 scheme攻击者用自己的 code 替换掉受害者的 code受害者登录后攻击者能通过自己的 code 关联到受害者的 session这种攻击叫授权码拦截攻击Authorization Code Interception Attack。5.2 PKCE 做了什么PKCEProof Key for Code Exchange发音 “pixy”在授权码流程中增加了两个步骤客户端生成 code_verifier随机字符串关键安全点在于code_challenge 是 code_verifier 的哈希值无法反推只有最初生成code_verifier的客户端才能在最后一步提供正确的code_verifier任何中间人截获了 code 也没用因为它没有code_verifier一句话总结 PKCE我先把锁给你code_challenge等我拿到授权码后来换 token 时我再证明我有钥匙code_verifier。换不了钥匙的人拿到授权码也没用。5.3 OAuth 2.1 的规定在 OAuth 2.1 中所有使用授权码模式的客户端都必须使用 PKCE。这不是可选增强而是硬性要求。六、Spring Security 实战10 分钟搭一个 OAuth2 授权服务器理论讲得差不多了手该上键盘了。我们来搭一个可以跑的 OAuth2 授权服务器。6.1 项目依赖Spring Boot 3.x Spring Security 6.x!-- pom.xml --6.2 授权服务器配置Configuration6.3 资源服务器配置Configuration6.4 资源接口RestController6.5 配置 application.ymlserver:6.6 验证流程启动项目后在浏览器里访问http://localhost:8080/oauth2/authorize你会依次看到Spring Security 默认的登录页面输入 zhangsan / 123456授权确认页面“咕咚笔记申请获取你的 read 权限”点击同意后浏览器重定向到http://localhost:8081/...?codexxxx拿到了code后端就可以用codeclient_secretcode_verifier去换 Access Token 了curl -X POST http://localhost:8080/oauth2/token \响应{七、细说 Token 安全Access Token 过期了怎么办7.1 Token 生命周期的设计哲学Access Token 有效期短15分钟 ~ 2小时为什么要这样分层最小化暴露面。Access Token 在每次 API 请求中都会发送暴露在网络上所以让它短命Refresh Token 只在 token 过期时使用一次暴露次数极少即使 Access Token 泄露攻击者也只有十几分钟的窗口7.2 Refresh Token 轮转Rotation这是 OAuth 2.1 的最佳实践**每次用 Refresh Token 换新 Access Token 时同时发放一个新的 Refresh Token并把旧的 Refresh Token 作废。**请求refresh_token_123 → 换取新的 access_token好处是如果攻击者偷到了一个 Refresh Token但用户使用它会触发轮转那么当用户也用了一下这个 Refresh Token或攻击者用完之后用户再用服务端就会发现“这个 token 已经被用过了”——说明可能被泄露了可以立刻作废该用户的所有 token。7.3 Token 存储前端到底该放哪这也是面试和实际开发中都绕不过的问题。存储方式安全性XSS 风险CSRF 风险推荐度localStorage低❌ 可被 JS 读取无不推荐sessionStorage低❌ 可被 JS 读取无不推荐CookieHttpOnly高✅ JS 无法读取需防 CSRF⭐ 推荐内存变量高✅✅刷新即丢失BFFBackend For Frontend最高✅✅⭐⭐ 最推荐最佳实践Token 存在后端的 session 中前端只持有一个 session cookieHttpOnly Secure SameSiteStrict。这就是 BFF 模式——前端根本不碰 token。八、OAuth2 JWT 深度融合从原理到代码8.1 JWT 的结构深入一个 JWT 由三部分组成用.分隔Header.Payload.SignatureHeader算法信息{alg: RS256,kid: key-id-001,typ: JWT}Payload声明信息{Signature签名RSASHA256(8.2 资源服务器如何验证 JWT资源服务器收到请求Authorization: Bearer jwtSpring Security 的oauth2ResourceServer().jwt()配置自动完成了这一切。8.3 手动解析 JWT不用 Spring Securityimport io.jsonwebtoken.Claims;8.4 自定义 JWT 中的 Claims有时候你需要在 JWT 中加入业务相关的信息Bean资源服务器侧读取GetMapping(/admin/info)九、生产环境的七大安全最佳实践这一节不讲代码讲原则。每一条都是用血泪教训换来的。9.1 始终使用 HTTPS全文最重要的一条。如果授权请求走的是 HTTP中间人可以截获code如果 token 端点走的是 HTTP中间人可以截获client_secret。一旦泄漏全盘皆输。生产环境强制 HTTPS没有任何商量的余地。9.2 Token 不存前端我们在 7.3 节已经讨论过了。localStorage 存 token 等价于在大马路上贴银行卡密码。用 HttpOnly Cookie BFF 模式。9.3 最小权限原则申请 scope 时只申请你真正需要的。一个只展示用户昵称的应用不要申请读取好友列表发送私信的权限。9.4 验证 redirect_uri授权服务器必须严格校验redirect_uri只允许预先注册的地址。不校验的话攻击者可以诱导用户授权后把 code 发到自己的服务器。9.5 使用 state 参数防 CSRF在发起 OAuth2 授权请求时生成一个随机字符串作为state参数并在回调时验证。这可以防止攻击者诱导用户点击一个已预授权的链接。// 发起授权时9.6 启用 PKCE即便是机密客户端虽然 PKCE 最初是为公开客户端无法安全存储 client_secret 的应用设计的但 OAuth 2.1 要求所有客户端都使用。多一层防护总没错。9.7 监控异常 Token 使用同一个 Refresh Token 被使用了两次 → 可能是泄露同一个 Access Token 在短时间内从不同 IP 使用 → 可能被盗用大量 token 签发请求 → 可能是暴力攻击十、面试八股速通高频问题一网打尽10.1 OAuth2 的四种角色是什么资源拥有者、客户端、授权服务器、资源服务器。四个角色一个都别少。10.2 授权码模式为什么要先发 code 再换 token因为code通过浏览器传输不安全但换token需要client_secret只存在后端。这样确保了即使code泄露没有client_secret也拿不到真正的 Access Token。10.3 PKCE 解决了什么问题原理是什么解决了授权码拦截攻击。原理是客户端先生成code_verifier和它的哈希值code_challenge授权时传 challenge换 token 时传 verifier授权服务器验证两者匹配。只有最初发起授权请求的客户端才知道code_verifier。10.4 JWT 和 OAuth2 是什么关系OAuth2 是授权协议定义了怎么发、怎么用JWT 是令牌格式定义了长什么样。OAuth2 的 Access Token 可以用 JWT 格式也可以用随机字符串不透明令牌。10.5 Access Token 过期了怎么办用 Refresh Token 去换新的 Access Token不需要用户重新登录。如果 Refresh Token 也过期了才需要用户重新授权。10.6 Refresh Token 轮转是什么每次使用 Refresh Token 时授权服务器同时发放一个新的 Refresh Token旧 token 作废。用于检测 Refresh Token 是否被泄露。10.7 如何在微服务之间传递 token下游服务从请求头中获取 token透传或由网关统一处理用户 → Gateway → 服务A → 服务B或者服务 A 使用客户端凭证模式以自己的身份去调用服务 B。10.8 OAuth2 和 SSO单点登录是什么关系OAuth2 本身是授权协议不能直接用于认证。OpenID Connect (OIDC)是基于 OAuth2 的身份认证层可以实现 SSO。简单理解OAuth2给你一张门禁卡你可以进房间OIDC给你一张门禁卡卡上还印了你的名字和照片可以证明你是谁10.9 Cookie 和 Token 两种认证方式的区别维度Cookie SessionJWT Token状态服务端有状态存 session服务端无状态token 自包含扩展性需要共享 session如 Redis天然支持分布式注销简单删 session复杂token 未过期仍有效需黑名单移动端不友好友好HTTP Header安全性需防 CSRF需防 XSS若存前端写在最后OAuth2 不是一个能一眼看懂的协议。它的规范 RFC 6749 是一份篇幅不小的文档而 OAuth 2.1 还在持续演进中。但好消息是对于绝大多数 Java 开发者来说你不需要通读 RFC你只需要搞懂本文覆盖的这些核心概念和原则。回顾一下你的学习路径理解问题OAuth2 是为了让第三方在不拿密码的情况下访问用户数据记住角色四个角色、四种模式吃透流程授权码模式为什么分两步、PKCE 做了什么动手实践Spring Security 搭一套授权/资源服务器守住安全七大实践条条都是真金白银的经验本文的引用仅限自我学习如有侵权请联系作者删除。参考知识多系统认证授权利器OAuth2究竟该如何使用