[!info] related notes

• 所属 MOC：Web · 服务工程 · 学习路线
• 通用认证模型：Stateful、Stateless 与 Hybrid 认证架构
• 凭证概念：Access Token · Refresh Token · JWT · Server-side Session 鉴权
• 后续概念：Spring Security 方向

Java 认证与 JWT 概览

一句话理解

在 Java Web 服务中，JWT 常被用作短期 Access Token，但 JWT 只是凭证格式。是否维护 Server-side Session、是否每请求查询状态、如何 Refresh 与 Revoke，是独立的认证架构决策。

四层不要混淆

Authentication
→ 当前请求代表谁

Authorization
→ 这个身份能做什么

Session / Grant
→ 长期登录生命周期是否仍有效

JWT
→ 某个 Token 采用什么可签名验证格式

常见两种实现

Pure Stateful Session

Browser Cookie
→ opaque Session Token
→ Server-side Session lookup

不需要 JWT，也能完成完整登录、注销和设备撤销。

Hybrid

normal API
→ short-lived Access JWT
→ Resource Server local verification

refresh/logout/revoke
→ Refresh Token
→ Auth Server checks Session / Grant

这允许普通请求不访问 Session Store，同时长期生命周期仍可被服务器控制。

Bearer 只是传输方式

Authorization: Bearer <token>

Bearer 表示“持有者凭证”语义；里面可以是 JWT，也可以是 opaque token。解析 Header 不等于认证成功，后端仍需要验证对应凭证。

JWT 验证

真实实现应使用成熟库，并至少根据场景验证：

• signature；
• allowed algorithm；
• exp / nbf；
• iss；
• aud。

普通签名 JWT 的 Payload 可以被读取，不能把密码、密钥等秘密放进去。

Authorization 不能只看“有 Token”

即使 Access Token 中有：

sub = user-42
role = admin

资源级权限仍可能依赖当前数据库状态。例如用户是否属于某个 Tenant、是否拥有某个 Order、资源是否已经锁定。

Spring Security 等框架可以帮助建立 Authentication / Authority Context，但不会自动替代领域级 Policy。

Refresh 与撤销

Refresh Token 不要求是 JWT。它可以是 opaque random credential，并绑定服务端 Session / Grant。

短期 Access JWT 在本地验证模式下，Session 被撤销后可能继续有效到 exp。如果业务要求即时撤销，需要每请求实时状态检查、denylist/introspection，或对敏感操作单独增加实时验证。

常见误区

• “JWT = 无状态登录方案” → JWT 只是格式，系统仍可有 Session/Grant。
• “JWT = Bearer Token” → Bearer 是携带语义，JWT 是格式。
• “有 Token 就完成授权” → 仍需 Authorization。
• “Session 是旧技术” → 不是；它仍是非常自然的可撤销登录状态模型。

最短记忆

Java/Spring 中先设计 Authentication、Session 生命周期和 Authorization，再决定 Access Token 是否使用 JWT；不要从 JWT 反推整套认证架构。