JWT

带签名的 JWT 携带一组声明，接收方可以检查它们的完整性，而不必先从会话表读取整枚令牌。便利并不等于保密，也不会自动完成授权或阻止重放。审阅时应先明确令牌格式和应用的验证契约，再分别测试边界。密码学验证成功，只是访问决策的一项输入，不能代替资源本身的权限判断。 签名保护完整性，并不提供保密性。紧凑 JWS 模型将密码学检查、应用策略与最终访问决策分开；时间窗不包含恰好到期的时刻。签名正确本身不能证明令牌适用。 带签名令牌只是 JWT 的一种形式 本文讨论以 JWS 表示的紧凑、带签名或消息认证码的 JWT：受保护头部、载荷、签名或认证码构成三个点分段。Base64url 可以逆向解码，并不提供保密性。但 JWT 也支持加密的 JWE 表示，因此“所有 JWT 都可读而且只有三段”并不准确。即使使用加密，也应减少个人信息，避免嵌入与当前用途无关的凭据。 HS256 用共享秘密计算 HMAC。每个持有秘密的验证方也能签发令牌，因此它不能证明究竟是哪一个持有者发出了令牌。非对称签名把签发与验证能力分开。无论采用哪种设计，都不能因为令牌附带了一把陌生密钥，就把它当作信任依据。可信签发者、密钥来源、允许算法和令牌种类需要一起配置。 验证是一份应用契约 实现可以先解析少量不可信数据，以定位已经配置的密钥，但在密码学验证及策略检查全部完成前，不能根据声明执行操作。把 kid 当作可信密钥集合内的标识，不允许它任意指定文件路径或网络下载地址。每把密钥必须绑定预期算法，不能让声称使用 HS256 的令牌把 RSA 公钥变成 HMAC 秘密。 ...