# 1. JWT 与 Session 的取舍 A JWT 一旦签发，服务端可以随时吊销而无需额外机制 B JWT 是会话状态必须存储在服务端与 Session 完全相同 C Session 无法在分布式系统中使用 D JWT 无状态、便于微服务独立验签，但难以主动撤销；Session 有状态、可撤销，但需共享存储 ✓ 正确答案
# 2. JWT 在 OAuth2 客户端凭证模式的应用 A 该模式需要用户授权页面确认 B 该模式用于服务间通信，客户端用 client_id/client_secret 换取 JWT 访问令牌，无需用户参与 ✓ 正确答案 C 客户端凭证模式下 JWT 不需要设置 aud 与 scope D client_secret 可以安全地放在前端代码中使用
# 3. JWT 在 Refresh Token 轮换中的边界 A 轮换机制在每次刷新时签发新 Refresh Token 并废弃旧的，可缓解令牌重放风险 ✓ 正确答案 B 访问令牌 TTL 越长越安全，无需 Refresh Token C Refresh Token 生命周期短，且无需服务端跟踪 D Refresh Token 可以安全地存放在浏览器 LocalStorage 中
# 4. JWT 在 Spring Cloud Gateway 的转发 A 网关统一校验 JWT 后向服务注入用户信息，且须剥离客户端伪造的同名头以维护信任边界 ✓ 正确答案 B 网关只能转发原始 JWT，不能解析任何声明 C 网关校验 JWT 后无需考虑白名单路径 D 下游服务无需信任网关，可自行校验网关注入的头
# 5. JWT 在 spring-security-oauth2-jose 的边界 A 它不支持从 JWKS 端点加载公钥，只能硬编码密钥 B 它内置完整的授权服务器，可直接签发访问令牌 C 它提供 JwtDecoder/JwtEncoder 负责 JWT 的编解码与验签，支持从 JWKS 端点加载公钥 ✓ 正确答案 D 它负责业务授权，把声明直接映射为权限
# 6. JWT 在前后端的存储（HttpOnly Cookie vs LocalStorage） A LocalStorage 中的令牌无法被任何脚本读取 B 把 JWT 放 URL 参数中是安全且推荐的存储方式 C HttpOnly Cookie 存储在客户端，JS 无法读取也无需考虑 CSRF D HttpOnly Cookie 抗 XSS 窃取但需处理 CSRF，LocalStorage 易被 XSS 读取但无 CSRF 问题 ✓ 正确答案
# 7. JWT 的结构（Header/Payload/Signature） A JWT 的 Payload 是加密的，无法被他人解码 B Signature 包含用户明文密码 C JWT 的 Header 一定包含用户信息 D JWT 由 Header/Payload/Signature 三段组成，Payload 仅 Base64URL 编码可被解码，Signature 用于防篡改 ✓ 正确答案
# 8. JWT 的 Payload 编码（Base64URL） A Base64URL 与标准 Base64 完全相同 B Base64URL 用 - 和 _ 替换 + 和 / 并去掉 = 填充，保证可在 URL 中安全传输，但编码不加密 ✓ 正确答案 C JWT 的 Payload 用标准 Base64 编码，包含 + 和 / 字符 D Base64URL 编码即加密，Payload 内容不可见
# 9. JWT 的 aud/iss/sub/exp/nbf/iat 的语义 A iat 用于标识 token 的受众 B aud 标识签发者，校验时无需关注 C exp 表示 token 的生效时间，之前的 token 无效 D iss 标识签发者、aud 标识受众、sub 标识主体，exp/nbf/iat 定义时间窗口，验证时需校验一致性 ✓ 正确答案
# 10. JWT 的 kid/jku/x5u 与密钥轮换 A kid 是 JWT 的载荷，用于存储用户信息 B kid 标识密钥使验证方在轮换时选择正确密钥，jwks 端点应可信，jku/x5u 在线拉取密钥需严格限制 ✓ 正确答案 C jku/x5u 可以安全地指向任意 URL 拉取密钥 D 密钥轮换时新旧密钥不能同时存在于 JWKS
# 11. JWT 的压缩（zip）与 alg 头部 A 服务端应直接信任 Header 中的 alg 选择验签算法 B zip 用于 JWT 的签名，与加密无关 C alg:none 是推荐的安全签名算法 D alg 指定算法，服务端必须用算法白名单而非信任 Header，防止算法混淆攻击与 none 算法 ✓ 正确答案
# 12. JWT 的安全漏洞（alg:none/密钥混淆） A alg:none 是安全的，服务端可放心接受 B 把 RSA 公钥当作 HMAC 密钥验签是安全的 C alg:none 与密钥混淆攻击都源于服务端信任 Header 中的 alg，防御核心是固定算法白名单且不信任 Header ✓ 正确答案 D JWT 只要用了签名算法就绝对安全
# 13. JWT 的撤销机制（黑名单/短 TTL/Refresh Token） A 黑名单方案完全无状态，无需任何存储 B 黑名单可精确即时撤销但有状态开销，短 TTL 无状态但存在泄露窗口，Refresh Token 提供间接控制 ✓ 正确答案 C 短 TTL 可以立即撤销已泄露的 JWT D JWT 无法通过任何机制实现撤销
# 14. JWT 的时钟漂移（Clock Skew）容忍 A 验证方时钟偏差可能误判 exp/nbf，应设置合理时钟偏斜容忍度（如 30-60 秒）并配合 NTP 校时 ✓ 正确答案 B 时钟漂移只影响签名，不影响 exp 校验 C clockSkew 设置越大越好，完全不限制过期 D 验证方无需考虑签发方时钟偏差
# 15. JWT 的签名算法（HS256/RS256/ES256）的差异 A RS256 与 HS256 一样是对称算法 B ES256 使用共享密钥签发与验证 C HS256 对称需共享密钥，RS256/ES256 非对称用私钥签发公钥验证，适合多验证方并可通过 JWKS 分发公钥 ✓ 正确答案 D 三种算法都通过公钥分发实现签发与验证分离
# 16. JWT 的签名验证（MAC verify） A HMAC 验证使用公钥，无需共享密钥 B 比较 HMAC 结果时使用普通字符串比较即可，无安全风险 C 可以把 RSA 公钥直接作为 HMAC 密钥使用 D 验证方用共享密钥对 Header.Payload 重算 HMAC 并与 Signature 比较，比较应使用常量时间算法 ✓ 正确答案
# 17. jwt.io 如何用于 JWT 解析与调试，其安全局限（密钥泄露/算法混淆）如何注意？ A jwt.io 适合开发调试解析 JWT，但绝不能把真实生产密钥或私钥粘贴进去，否则会泄露 ✓ 正确答案 B jwt.io 是官方权威的 JWT 验证库，可放心在生产环境使用 C 在 jwt.io 上验证通过就代表服务端验证逻辑正确 D jwt.io 只支持解密，不支持签名验证
# 18. nimbus-jose-jwt 库的使用 A 它只支持 JWS 不支持 JWK B 它支持 JWT 签名/验签、JWE 加密与 JWK/JWKS 加载，是 Spring Security OAuth2 jose 的底层实现 ✓ 正确答案 C nimbus-jose-jwt 不支持从 JWKS 端点加载公钥 D 它只能签发 token，不能验签
# 19. JWS/JWE/JWK 与 JWKS 的工程应用 A JWS 与 JWE 都是加密令牌，无法解码 B JWKS 端点只用于签发，不用于验证 C JWE 只签名不加密，JWK 只包含私钥 D JWS 保证签名防篡改，JWE 保证内容加密，JWKS 是公钥集合用于分发与密钥轮换 ✓ 正确答案
