1. JWT令牌安全与生命周期治理导论
JSON Web Token（JWT）已经成为现代分布式系统中承载身份与授权信息的主流令牌格式。它把用户身份、权限声明、签发者、有效期等数据编码进一个可自包含、可校验的字符串中，使资源服务器无需每次请求都回源查询会话存储，就能独立完成身份判断。这种“自包含”特性带来了横向扩展的便利，也同时把安全责任从集中式会话服务器分散到了每一个校验方。理解 JWT 的安全与生命周期治理，本质上是在理解一个令牌从签发到失效的完整信任链条。
JWT 在身份认证与授权中的定位
在典型的 OAuth 2.0 / OpenID Connect 体系中，JWT 通常以两种角色出现：作为 ID Token 向客户端证明“用户是谁”，以及作为 Access Token 向资源服务器证明“该请求被授权访问什么”。前者关注身份断言，后者关注授权范围。二者虽然都是 JWT，但受众（aud）、有效期、校验规则和泄露后的影响面并不相同。
一个 JWT 由三部分组成，以点号分隔：
header.payload.signature
eyJhbGciOiJSUzI1NiIsImtpZCI6ImtfMjAyNCJ9
.
eyJzdWIiOiJ1c2VyXzEwMjQiLCJzY29wZSI6Im9yZGVyOnJlYWQiLCJleHAiOjE3MTk4MDAwMDAsImlzcyI6Imh0dHBzOi8vYXV0aC5leGFtcGxlLmNvbSIsImF1ZCI6ImFwaS5leGFtcGxlLmNvbSJ9
.
RS256签名值其中 header 声明算法与密钥标识（kid），payload 承载声明（claims），signature 用于完整性校验。需要特别强调的是：payload 只是 Base64URL 编码，并非加密。任何拿到令牌的人都能解码并读取其中的 sub、scope、角色等信息。因此 JWT 中不应放置密码、身份证号、密钥等敏感数据，只应放置必要的身份与授权声明。
安全治理与生命周期管理的核心问题域
JWT 的风险并不集中在“签名算法是否够强”这一个点上，而是分布在令牌的整个生命周期中。可以把核心问题域归纳为四个相互关联的维度：
- 签发阶段：算法选择（禁用 none、避免 HS256 与 RS256 混用导致的算法混淆）、密钥管理（kid 轮换、私钥保护）、声明最小化（只放必要 scope）、有效期设定（exp、nbf、iat）。
- 传输与存储阶段：必须走 HTTPS；浏览器端存储位置（HttpOnly Cookie 优于 localStorage）、防止 XSS 窃取、防止 CSRF。
- 校验阶段：资源服务器必须校验签名、iss、aud、exp、nbf，并明确拒绝 alg=none；不能只解码 payload 就信任其内容。
- 失效与撤销阶段：JWT 天生无状态，签发后在过期前默认一直有效。如何实现“提前失效”（登出、改密、权限回收）是治理难点，常见手段包括短有效期 + Refresh Token、黑名单/白名单、令牌版本号（token version）等。
这四个维度构成了本课程的主线。下图展示了 JWT 从签发到校验、再到失效的完整生命周期，以及每个阶段的关键控制点与典型风险。
从图中可以看到，签发、传输、校验、撤销并不是四个孤立环节，而是一条连续的信任链。任何一个环节的疏忽都会让整条链失效。例如，即使签名算法足够强，如果资源服务器在校验时没有核对 aud，攻击者就可能把面向 A 服务的令牌拿去访问 B 服务；如果令牌有效期长达数小时且没有撤销机制，用户登出后令牌仍然可用，权限回收就形同虚设。
本课程的学习目标
本课程围绕上述生命周期展开，目标是让读者能够：
- 准确区分 JWT 在认证与授权中的不同角色，理解 ID Token 与 Access Token 的校验差异。
- 掌握 JWT 签发时的算法选择、密钥管理与声明设计原则，能够识别 alg=none、算法混淆等典型漏洞。
- 掌握资源服务器端的完整校验流程，包括签名、iss、aud、exp、nbf 的核对顺序与失败处理。
- 理解 JWT 无状态特性带来的撤销难题，并能根据业务场景选择合适的失效策略（短有效期、Refresh Token、黑名单、版本号）。
- 能够为一条真实的认证链路设计可落地的令牌生命周期治理方案，并给出可验证的检查点。
JWT 本身只是一种令牌格式，它不自动带来安全，也不自动带来治理。真正决定系统安全水平的，是围绕令牌生命周期建立的校验规则、密钥管理流程和失效机制。接下来的章节将沿着“签发—传输—校验—撤销”这条主线，逐层展开每个环节的具体实现与常见陷阱。