OAuth2 与 JWT

• JWT 无状态与 Session 有状态的区别
• 分布式场景下的扩展性
• 撤销、安全性与存储的权衡

JWT 是无状态的，服务端把用户信息与签名封装在令牌中，验签即可信任，无需存储会话，天然适合分布式/微服务（每个服务都能独立验签，无需共享 Session 存储）；Session 是有状态的，会话数据存服务端（内存或 Redis），客户端只持有 Session ID，需要共享存储支持多实例。JWT 优点：无状态、可跨域/跨服务、便于移动端与第三方集成；缺点：无法主动撤销（除非引入黑名单/缩短 TTL）、令牌可能泄露（一旦签发即有效）、载荷占用存储空间、以及密钥管理复杂。Session 优点：可主动吊销、可撤销、服务端可控；缺点：需要共享存储、有状态、难以横向扩展。取舍建议：对需要精确控制会话生命周期、可撤销的场景（如后台管理、敏感操作）倾向 Session；对高并发、无状态、跨服务认证的场景（如开放 API、微服务网关）倾向 JWT，并配合短 TTL 与 Refresh Token 缓解撤销问题。

本题考察"状态放哪"的设计权衡。核心是 JWT 无状态（可验签、难撤销）与 Session 有状态（可撤销、需存储）的对比，以及各自在分布式场景下的适用性。回答应结合业务场景给出取舍。

• 客户端凭证模式的授权流程
• JWT 作为访问令牌的签发与使用
• 适用场景（服务间通信）

OAuth2 客户端凭证模式用于服务间/机器对机器（M2M）的认证，不需要用户参与。客户端（如微服务）用 client_id + client_secret 向授权服务器换取访问令牌，令牌通常是 JWT。流程：客户端用凭证请求 /token 端点 → 授权服务器验证 client 凭证 → 签发 JWT（含 sub、aud、scope、iss、exp 等声明）→ 客户端携带 JWT 调用受保护资源 → 资源服务器验签并校验 scope/aud。该模式的特点：无用户、无 Refresh Token 交互（也可按需刷新）、令牌有效期内客户端可复用；适用场景包括服务间 API 调用、后台任务、定时器、以及第三方系统集成。安全要点：client_secret 需安全存储（勿写进前端/代码库）、JWT 的 aud 需限定目标资源、scope 控制最小权限、令牌短 TTL。Spring Security 中可用 OAuth2ClientCredentialsGrant 或对接授权服务器（如 Keycloak）实现。

本题考察客户端凭证模式。核心是"机器对机器、无用户、用 client 凭证换 JWT"。回答应点出流程、JWT 声明与适用场景，并强调 client_secret 保护与最小权限。

• Refresh Token 的作用与轮换机制
• 单次刷新才有效（轮换）与重放检测
• 撤销与过期策略

JWT 访问令牌（Access Token）有效期短（如 15 分钟），过期后需用 Refresh Token 换取新令牌，避免用户频繁重新登录。Refresh Token 轮换（Rotation）指每次刷新都签发新的 Refresh Token 并废弃旧的，这样即使旧 Refresh Token 被窃取，重放也会被拒绝（每次刷新后旧 token 失效）。边界与安全考量：Refresh Token 生命周期长、是敏感凭证，应安全存储（服务端/HttpOnly）并设置有效期；轮换机制要求服务端跟踪已签发的 Refresh Token（可用 Redis 存储或撤销列表），检测重放（同一 refresh token 被多次使用）时踢出所有会话；刷新时校验 scope、aud 是否允许；访问令牌与 Refresh Token 的 TTL 要平衡——访问令牌太短则刷新频繁增加开销，太长则泄露窗口大；业务上可让中风险操作要求重新认证。工程上，Refresh Token 通常保存在服务端（白名单）或加密存储，配合检测到被盗用时的全量吊销。

本题考察 Refresh Token 轮换的边界。核心是"轮换使旧 token 失效、重放检测、TTL 平衡"。回答应点出轮换机制、重放风险与撤销策略。

• 网关统一认证与 JWT 校验
• JWT 的转发与声明传递
• 网关过滤器与下游信任边界

在微服务架构中，Spring Cloud Gateway 作为统一入口负责认证与鉴权。流程：客户端携带 JWT 访问网关 → 网关的 GlobalFilter/认证过滤器校验 JWT 签名、过期时间、issuer/audience → 校验通过后，网关把 JWT 或解析出的用户信息（如 X-User-Id、X-User-Name 头或原样转发 Authorization 头）传给下游服务。关键点：一是网关做"统一认证"，下游服务信任网关（可通过网关去除、再注入受信任的请求头，防止客户端伪造 X-User-Id 头）；二是转发方式——可直接转发原始 JWT，让下游服务各自验签，或网关验签后向下游注入签名好的用户头（此时下游不再验签，信任网关）；三是网关应配置合适的过滤器链顺序（先认证后限流/转发），并排除白名单路径（如登录、健康检查）。安全边界：如果下游服务不能验证网关注入头的真实性，网关必须"剥离客户端传入的相同头"再注入自己的，防止伪造。也可用 spring-cloud-gateway 的 TokenRelay 过滤器配合 OAuth2 转发。

本题考察网关的 JWT 认证与转发。核心是"网关统一认证 + 下游信任边界 + 防头伪造"。回答应点出转发方式与信任模型。

• spring-security-oauth2-jose 的职责
• JwtDecoder 与 JwtEncoder
• JWK/JWKS 支持与算法约束

spring-security-oauth2-jose 是 Spring Security 提供的 JOSE（JWT/JWS/JWE/JWK）实现模块，封装了基于 Nimbus JOSE 库的 JWT 编解码与密钥管理能力。其职责边界：提供 JwtDecoder（解码并验签 JWT）与 JwtEncoder（签发 JWT），支持通过 NimbusJwtDecoder 从 JWKS 端点（withJwkSetUri）加载公钥、或指定密钥（withSecretKey/withPublicKey）；JwtDecoder 会校验签名算法、偏差时间、iat/nbf/exp 等声明，并支持自定义 JwtValidator。它的边界在于：它负责"JWT 的编解码与验签"，不负责业务授权（由 JwtAuthenticationConverter 把声明映射为权限）也不负责发 token 的授权服务器——签发需自己实现 JwtEncoder 或对接授权服务器（如 Keycloak）。算法上它支持 HS256/RS256/ES256 等，但需显式配置；安全上应配对算法做白名单（防止算法混淆），并从可信 JWKS 端点加载公钥。在 Resource Server 中，oauth2ResourceServer().jwt() 即基于该模块。

本题考察 spring-security-oauth2-jose 的功能边界。核心是"负责 JWT 编解码验签，不负责授权与签发"。回答应点出 JwtDecoder/JwtEncoder、JWKS 支持与算法白名单。

• HttpOnly Cookie 存储（防 XSS 读取）
• LocalStorage 存储（易被 XSS 读取）
• CSRF 防护与存储方案的权衡

JWT 存储在前端有两种主流方案。其一：存 HttpOnly Cookie——浏览器自动携带，JS 无法通过 document.cookie 读取，天然抵抗 XSS 窃取令牌，但需要处理 CSRF（Cookie 会被自动携带，需 CSRF Token/SameSite 防护），且跨域场景需配置 CORS 与 withCredentials。其二：存 LocalStorage——JS 可读，方便前端手动在请求头携带 Authorization: Bearer，且不涉及 CSRF（令牌不在 Cookie 中），但一旦发生 XSS，攻击者可直接读取 LocalStorage 中的令牌，且令牌无法被 HttpOnly 保护。安全边界：LocalStorage 存储的令牌暴露面更大（XSS 即窃取），HttpOnly Cookie 更抗 XSS 但引入 CSRF 与跨域复杂度。业界更推荐把访问令牌放内存（前端变量）或尽量短生命周期，把 Refresh Token 放 HttpOnly Cookie 并配合 CSRF 防护；或采用"Authorization 头 + 内存存储"减少存储风险。核心原则是"令牌尽量少暴露、尽量短命、配合双重防护"。

本题考察 JWT 前端存储的安全权衡。核心是"HttpOnly Cookie 抗 XSS 但引入 CSRF，LocalStorage 易被 XSS 读取但无 CSRF"。回答应点出两种方案的权衡与推荐做法。

• JWT 结构与三段 Base64URL 编码
• Header 中的 alg/typ
• Payload 的 registered claims 与 Signature 的作用

JWT 由三段用 . 分隔的 Base64URL 编码字符串组成：Header.Payload.Signature。Header 包含算法与类型信息，如 {"alg":"HS256","typ":"JWT"}，alg 指定签名算法，typ 通常为 JWT。Payload（Claims）包含业务声明，有标准注册声明（registered claims）：iss（签发者）、sub（主题/用户）、aud（受众）、exp（过期时间）、nbf（生效时间）、iat（签发时间）、jti（唯一 ID），以及自定义声明。Signature 是对 Header.Payload 进行签名（HMAC 或 RSA/ECDSA）得到的校验值，用于确保内容未被篡改且验证签发者身份。注意：Payload 只是 Base64URL 编码，不是加密，任何人都能解码看到内容，因此 JWT 中不能放敏感明文（除非用 JWE 加密）。Signature 的作用是完整性校验与防伪造。三段式结构使 JWT 可自包含、可离线验签。

本题考察 JWT 的基本结构。核心是"三段式、Payload 可解码非加密、Signature 防篡改"。回答应点出各段内容与 Signature 的作用。

• Base64URL 与 Base64 的区别
• URL 安全字符集
• 编码非加密

JWT 的 Header 与 Payload 使用 Base64URL 编码（无填充），而非标准 Base64。区别在于：标准 Base64 使用 +、/、= 字符，这些字符在 URL 中不合法（+ 会被解释为空格、/ 会改变路径、= 在 query 中特殊），Base64URL 把 + 替换为 -、/ 替换为 _，并去掉 = 填充，从而保证编码结果可直接嵌入 URL、Header、Cookie 等场景而不需再转义。JWT 的三个部分都使用 Base64URL 编码并以 . 连接。需要强调的是，Base64URL 只是编码（encoding），不是加密或签名——任何人只要解码即可读取 Payload 的明文内容，因此敏感信息（密码、身份证号）不能直接放进 JWT 的 Payload，除非采用 JWE 对载荷加密。编码的安全性依赖于后续的签名（Signature）保证完整性。

本题考察 Base64URL 编码。核心是"URL 安全字符集（-/替换+/）与去填充"，以及"编码非加密"这一关键认知。回答应点出为何 URL 安全与为何不能放明文。

• 各注册声明的含义
• 校验策略（iss/aud/exp/nbf）
• 自定义声明的补充

JWT 的标准注册声明（registered claims）语义如下：iss（Issuer）签发者，标识 token 由谁签发，验证时需校验是否与期望的签发者一致，防止接受非法来源的 token；sub（Subject）主题，通常标识用户或资源所有者，是 token 的主体；aud（Audience）受众，标识 token 的接收方（资源服务器），验证时需校验 aud 是否包含当前服务，防止 token 被用于其他服务；exp（Expiration Time）过期时间，token 在此时间后无效，防止令牌长期有效；nbf（Not Before）生效时间，token 在此时间之前无效；iat（Issued At）签发时间。校验时：验证 iss、aud 匹配，验证 exp（当前时间 > exp 拒绝）、nbf（当前时间 < nbf 拒绝）、iat（防止异常未来时间），并通常容忍一定时钟漂移（Clock Skew）。sub 常用于把用户标识映射到授权主体。自定义声明（如 scope、roles）用于放业务数据，需在签发与校验两端约定一致。

本题考察 JWT 标准声明的语义。核心是"iss/aud/sub 标识三要素，exp/nbf/iat 时间三要素"。回答应点出各声明的校验作用。

• kid 标识密钥
• jku/x5u 的在线获取密钥与风险
• 密钥轮换流程

JWT Header 中 kid（Key ID）标识用于签名的密钥，服务端通过 kid 从本地密钥库或 JWKS 端点查找对应密钥，是实现密钥轮换的关键——签发方换密钥后，通过新的 kid 让验证方选择正确的密钥。jku（JWK Set URL）与 x5u（X.509 URL）分别指向 JWK 集合与证书的在线 URL，验证方据此下载公钥。安全性考量：jku/x5u 允许验证方去外部 URL 拉取密钥，若被攻击者控制（未校验 URL 白名单、未做 HTTPS 校验），可诱导验证方使用攻击者提供的公钥，从而伪造 token，因此应禁用或严格限制 jku/x5u，优先使用本地配置或可信 JWKS 端点。密钥轮换流程：签发方生成新密钥对，把新公钥加入 JWKS（保留旧公钥一段时间），用新私钥签发 token（带新 kid），验证方从 JWKS 拉取并缓存，根据 kid 匹配公钥；旧公钥的保留期需覆盖旧 token 的剩余有效期，期满后移除。轮换期间验证方应能容忍新旧 kid 并存。

本题考察 kid/jku/x5u 与密钥轮换。核心是"kid 标识密钥用于轮换，jku/x5u 在线获取有风险"。回答应点出轮换流程与 jku/x5u 的安全约束。

• alg 指定签名/加密算法
• zip 压缩的应用
• 算法混淆与压缩侧信道

JWT Header 中 alg 指定签名（HS256/RS256/ES256）或加密（JWE 的 alg）算法，验证方必须据此选择对应算法验签/解密。zip 用于 JWE（加密 JWT）中指定压缩算法（如 DEF），对 JWE 的加密载荷进行压缩以减少体积。安全考量：alg 是攻击者常攻击的目标——若服务端简单信任 Header 中的 alg，攻击者可能把 RS256 改为 HS256 并用已知公钥作为 HMAC 密钥签名（算法混淆攻击），故必须由服务端配置算法白名单，而非信任 Header 声明；none 算法（无签名）应在服务端禁用。zip 压缩与加密的组合存在压缩侧信道风险（CRIME/BREACH 变体），若攻击者能控制部分明文并观察压缩后密文长度，可能推测明文内容，因此对敏感数据需谨慎使用压缩，JWE 中压缩更多用于非敏感大载荷。核心原则：算法选择由服务端白名单决定，不信任 Header。

本题考察 alg 与 zip 头部。核心是"alg 算法混淆攻击须白名单，zip 用于 JWE 压缩有侧信道风险"。回答应点出 alg 的攻击面。

• alg:none 漏洞
• HS256/RS256 密钥混淆攻击
• 算法白名单与密钥管理

JWT 的常见漏洞：一是 alg:none——若服务端接受无签名算法，攻击者可把 alg 改为 none 并去掉签名，直接伪造任意 token；防御是服务端显式禁用 none 算法，只接受签名算法。二是密钥混淆（算法混淆）——攻击者把 RS256（非对称）改为 HS256（对称 HMAC），并把公开的 RSA 公钥当作 HMAC 密钥进行签名，若服务端误用公钥做 HMAC 验证，就会接受伪造 token；防御是服务端固定算法白名单，不能从 Header 读取 alg 决定验签方式，且密钥类型必须匹配（RSA 公钥不能用于 HMAC）。三是密钥泄露与弱密钥——HMAC 密钥应足够随机且保密。四是针对 jku/x5u 的篡改。防御整体策略：服务端硬编码允许的算法集合、不信任 Header 的 alg、使用规范库（如 nimbus-jose-jwt）并配置正确、密钥安全存储、定期轮换。这也是 OWASP 强调的 JWT 安全实践。

本题考察 JWT 算法类漏洞。核心是"alg:none 与 HS/RS 混淆都源于信任 Header 的 alg"。回答应点出防御为"算法白名单 + 不信任 Header"。

• 黑名单方案（有状态）
• 短 TTL 方案（无状态）
• Refresh Token 与撤销的配合

JWT 无状态导致无法主动吊销，撤销机制主要有三种：一是黑名单——把要撤销的 token 的 jti（或哈希）加入 Redis/DB 黑名单，验签时查询，若存在则拒绝。缺点是有状态、引入存储与查询开销，但能精确控制撤销；优点是即时生效。二是短 TTL——把访问令牌有效期设得很短（如 5-15 分钟），即使令牌泄露，过期前攻击窗口也小；配合 Refresh Token 续期，用户无感。缺点是泄露窗口仍存在（TTL 内有效），且无法立即撤销。三是 Refresh Token 配合——用户数据或权限变更、登出时，通过撤销对应的 Refresh Token（或清除服务端会话），使下一次刷新被拒绝，从而间接控制访问令牌继续使用。工程权衡：对敏感操作可用黑名单精确撤销；对普通请求用短 TTL + Refresh Token 降低窗口；登录/登出全局吊销时，可吊销 Refresh Token 并清除用户会话。也可结合"基于 jti 的撤销列表 + 定期清理"实现可控的状态与性能平衡。

本题考察 JWT 撤销机制。核心是"黑名单精确但有状态、短 TTL 无状态但有窗口、Refresh Token 配合延长控制"。回答应点出三者的权衡。

• 时钟漂移的来源
• 对 exp/nbf/iat 校验的影响
• clockSkew 的配置

时钟漂移指签发方与验证方服务器时钟存在偏差，可能导致"本应有效的 token 被误判过期"或"本应过期的 token 被视为有效"。JWT 校验 exp、nbf、iat 时依赖服务器时钟，若验证方时钟比签发方慢，exp 刚过但实际仍有效，会被误拒；若验证方时钟快，则 nbf 未到误差拒。因此验证方通常设置一个时钟偏差容忍度（clockSkew，如 30~60 秒），在校验时把当前时间 ± skew 作为比较基准：exp 校验时容忍 当前时间 <= exp + skew，nbf 校验容忍 当前时间 >= nbf - skew。Spring Security 的 NimbusJwtDecoder 通过 NimbusJwtDecoder.withJwkSetUri(...).clockSkew(Duration) 配置。工程上 clockSkew 不宜过大（过大等于放宽过期限制），一般 30-60 秒；同时应做 NTP 校时保证服务器时钟尽量一致。对高安全场景，可适当收紧但保留小容忍度。

本题考察时钟漂移。核心是"验签方时钟偏差导致 exp/nbf 误判，需容忍度"。回答应点出 clockSkew 的配置与合理范围。

• 对称（HS256）与非对称（RS256/ES256）
• 密钥分发与性能
• 适用场景

HS256（HMAC-SHA256）是对称算法，签发与验签使用同一个密钥，速度快、密钥小，但密钥必须由签发方与验证方共享，密钥分发困难且无法实现"只验证不签发"的分离，适合单一信任方（如内网或单一服务签发与验证）。RS256（RSA-SHA256）是非对称算法，用私钥签发、公钥验证，私钥只在签发方，公钥可公开分发（通过 JWKS），适合多验证方/第三方场景，但 RSA 密钥较大、签名性能较慢。ES256（ECDSA-SHA256）也是非对称算法，基于椭圆曲线 P-256，密钥更小、签名性能更好，适合资源受限或高并发场景，但实现更复杂，对随机数质量敏感。三者都支持 Token 验签，选择时：单信任方用 HS256；多服务/第三方用 RS256 或 ES256（配 JWKS 分发公钥）；追求性能与体积可用 ES256。安全上应固定算法白名单（防混淆），并确保密钥长度足够（RSA ≥2048、HS256 密钥 ≥256 bit）。

本题考察三种签名算法。核心是"HS256 对称、RS256/ES256 非对称"。回答应点出密钥分发、性能与适用场景。

• 签名验证流程
• HMAC 的密钥与计算
• 常量时间比较

JWT 签名验证的目的是确保 token 内容未被篡改且来自可信签发者。对 HMAC（HS256）类，验证流程：验证方用预先共享的密钥，对 Header.Payload 部分重新计算 HMAC 值，并与 token 携带的 Signature 比较，若一致则签名有效（MAC verify）。HMAC 计算是"密钥 + 消息"的哈希运算，密钥是核心秘密，任何能计算 HMAC 的人都能同时签发与验证，因此共享密钥必须保密。对非对称（RS256/ES256），验证方用公钥验证签名（私钥才可签发）。验证要点：一是比较 HMAC 结果时应使用常量时间比较（如 MessageDigest.isEqual），避免因比较提前返回导致的时序侧信道泄露；二是严禁把公钥当作 HMAC 密钥（算法混淆）；三是验证顺序通常先验签、再校验 exp/nbf/iss/aud 等声明。规范库（nimbus-jose-jwt）会自动完成这些步骤。

本题考察 JWT 签名验证。核心是"HMAC 用共享密钥重算比对，需常量时间比较防时序攻击"。回答应点出 MAC verify 流程与防混淆。

• jwt.io 的解析与调试功能
• 密钥泄露风险
• 算法混淆与误用风险

jwt.io 是一个在线的 JWT 解析与调试工具，可粘贴 JWT 自动解码三段结构，显示 Header/Payload 声明，并支持输入密钥验证签名（HS256 输入密钥、RS256 输入公钥/私钥）、调试签名。它的价值在于快速理解 JWT 结构、调试开发阶段的 token。安全局限需注意：一是密钥泄露——jwt.io 是第三方网站，把真实密钥（尤其生产环境的 HMAC 密钥或私钥）粘贴进去会泄露给第三方，绝不能在线上/生产环境使用，且输入过的 token 可能被记录；二是算法混淆——jwt.io 允许手动切换 alg 并选择密钥，若用错算法（如把 RSA 公钥当 HS256 密钥）会让人误以为验证通过，导致对漏洞的误判；三是它只做本地解码，不代表服务端验证逻辑。注意方式：只用于开发/测试环境、使用模拟密钥、不提交真实凭据；部署环境应使用本地工具（如 jjwt、nimbus）解析验证。

本题考察 jwt.io 的用法与局限。核心是"调试有用但绝不可上传真实密钥，注意算法混淆误导"。回答应点出安全使用边界。

• JWT 签发与验签
• JWK/JWKS 支持
• 与其他库的对比

nimbus-jose-jwt 是 Java 生态最成熟的 JOSE 库之一，Spring Security 的 spring-security-oauth2-jose 底层即基于它。基本用法：签发 JWT 时用 JWTClaimsSet 构造声明（iss/sub/aud/exp 等），用 JWSSigner（如 MACSigner 对应 HS256、RSASSASigner 对应 RS256）签名，JWSHeader 指定算法，JWSObject 序列化得到 token 字符串；验证时用 JWSVerifier（MACVerifier/RSASSAVerifier）验签，再用 JWTClaimsSet/JWTClaimsSetVerifier 校验声明。它支持 JWK/JWKSet，可从 JWKS 端点（JWKSet.load）加载公钥，也支持 JWE（加密）与 JWS（签名）两种封装。相比 JJWT，nimbus 更底层、功能更全（支持 JWE、JWK、复杂声明类型），但 API 相对繁琐；JJWT 更简洁、适合快速开发。选择时按功能需求与团队习惯，Spring Security 集成用 nimbus。

本题考察 nimbus-jose-jwt 用法。核心是"签名/验签/声明校验/JWK 支持"。回答应点出核心类与流程。

• JWS（签名）/JWE（加密）的区别
• JWK/JWKS 的密钥表示与分发
• 工程应用场景

JOSE 系列概念：JWS（JSON Web Signature）用于对 JWT 内容签名，保证完整性与防篡改（签名令牌，可被任何人解码但不可伪造）；JWE（JSON Web Encryption）对 JWT 内容加密，保证机密性（只有持密钥者能解密读取）；JWK（JSON Web Key）是 JSON 格式的密钥表示（含 kty、kid、算法、公钥参数等），JWKS（JWK Set）是 JWK 的集合，通常由授权服务器通过 /.well-known/jwks.json 端点公开。工程应用：授权服务器用私钥签发 JWS（访问令牌），并把公钥封装成 JWKS 发布；资源服务器通过配置的 JWKS 端点拉取并缓存公钥，校验 JWT 签名；JWE 用于需要加密载荷的场景（如 PE 令牌、敏感声明）；密钥轮换时在 JWKS 中同时保留新旧公钥，验证方按 kid 选择。典型场景：OIDC 的 ID Token 用 JWS 签名，可选 JWE 加密；OAuth2 访问令牌用 JWS；JWKS 端点支持多密钥与轮换。工程上需缓存 JWKS 并定期刷新、限制大小、使用 HTTPS。

本题考察 JOSE 概念。核心是"JWS 签名、JWE 加密、JWK/JWKS 密钥分发与轮换"。回答应点出各概念的工程用途。