JWT 令牌解析器
纯浏览器本地完成 JSON Web Token (RFC 7519) 结构剖析与安全审查。支持 Base64URL 头部参数、载荷声明（Claims）、Unix 过期时间戳深度识别，并通过原生 Web Crypto API 本地验证 HMAC 与 RSA/ECDSA 签名，物理级保障密钥与令牌绝对私密。
HEADER 头部 (算法与类型元数据)
{
"alg": "HS256",
"typ": "JWT"
}PAYLOAD 载荷 (声明与业务数据)
Tue, 01 Jan 2030 00:00:00 GMT
本地时间: 2030/1/1 00:00:00
Wed, 01 Jan 2025 00:00:00 GMT
本地时间: 2025/1/1 00:00:00
VERIFY SIGNATURE 签名验证 (浏览器本地 Web Crypto API)
算法: HS256JWT 审查与排查标准工作流
- 在输入框中粘贴待分析的 JWT 字符串，或点击快捷载入预置示例（HS256 有效、过期令牌、RS256 OIDC）。
- 在 Header 头部区块核对签名算法（alg）、令牌类型（typ）以及密钥标识符（kid）等基础元数据。
- 在 Payload 载荷区块审查身份声明（如 sub、iss、aud）与自定义业务元数据。
- 在时间戳与声明审查器中核对 exp（过期时间）、iat（签发时间）与 nbf（生效时间）的 UTC 与本地时区时间转换及倒计时状态。
- 按需输入 HMAC 密钥或 PEM 格式的 RSA/ECDSA 公钥，通过浏览器内置 Web Crypto API 在本地即时验证签名的防篡改性。
JWT 紧凑序列化结构剖析 (RFC 7519 与 RFC 7515 规范)
紧凑序列化格式的 JSON Web Token 由三个独立的 Base64URL 编码段组成，各段之间使用英文半角句点（.）作为定界符进行串联：
描述令牌的元数据与算法配置：包括所采用的密码学签名算法（alg，如 HS256 或 RS256）、令牌类型（typ: "JWT"）以及可选的公钥标识符（kid）。
承载已认证主体的身份声明与上下文会话元数据。包含标准注册时间戳（exp、iat、nbf）、签发主体（iss）、受众范围（aud）及业务自定义扩展字段。
通过预设的哈希或非对称签名函数，将密钥对 ProtectedHeader.Payload 计算生成的数字签名。接收端用于校验数据是否在网络传输途中遭受篡改。
编码规范对比：标准 Base64 与 Base64URL
RFC 7519 强制规范要求采用 Base64URL 编码（RFC 4648 §5）而非传统标准 Base64（RFC 4648 §4），从而确保令牌能够无损穿透 HTTP Authorization 请求头、URL 查询参数及 Cookie，无需二次百分号转义：
| 编码参数 | 标准 Base64 (RFC 4648 §4) | Base64URL (RFC 4648 §5 / RFC 7519) | JWT 体系下的工程考量 |
|---|---|---|---|
| 第 62 个字符 | + (加号) | - (减号 / 连字符) | 消除 URL 传参时 + 符号被误解析为空格的语义冲突 |
| 第 63 个字符 | / (正斜杠) | _ (下划线) | 防止 Web 服务器或路由网关将 / 误判为 URL 路径分级界定符 |
| 末尾补位符号 | = (等号) | 显式省略 (无补位) | 避免与 Query 参数的键值连接符冲突；解码时通过 (4 - (len % 4)) % 4 动态补齐 |
| 网络传输友好度 | 需要额外的 URL 百分号转义 | 天然适配 Header、URL 与 Cookie | 确保在 Authorization: Bearer <token> 跨服务调用时零突变 |
标准注册声明生命周期与网关校验规则 (RFC 7519 §4.1)
RFC 7519 规范定义了 7 个标准注册声明（Registered Claims），用于实现统一身份认证中心（IdP）与下游资源网关之间的互操作性校验：
| 声明代码 | 标准定义 | 数据类型 | 校验判定逻辑 | 网关与校验组件行为 |
|---|---|---|---|---|
| exp | 过期时刻 (Expiration Time) | NumericDate | currentTime < exp + leeway | 若当前时间戳超出设定值，网关强制拒绝请求并返回 401 Unauthorized |
| nbf | 生效起始时刻 (Not Before) | NumericDate | currentTime >= nbf - leeway | 拒绝在预约激活时刻前抵达的早到请求；多用于定时调度或批量预签发令牌场景 |
| iat | 签发时刻 (Issued At) | NumericDate | iat <= currentTime + leeway | 用于约束令牌最大允许存活周期（Max Age），并拦截因服务器时钟超前异常而导致的超前令牌 |
| iss | 签发主体标识 (Issuer) | StringOrURI | iss === expectedIssuer | 严格字符串对齐校验，确认是否来自预期的认证中心（如 https://auth.example.com） |
| aud | 受众受限目标 (Audience) | String | Array | aud.includes(targetAudience) | 确认当前微服务或网关标识在受众范围内；有效防范跨系统令牌冒用与越权提权攻击 |
| sub | 认证主体标识 (Subject) | String | sub !== empty | 签发方作用域下全局唯一的主体标识符（如用户 UUID、工号、服务账号标识） |
| jti | 令牌唯一流水号 (JWT ID) | String | !redisCache.has(jti) | 一次性令牌或防重放标识；与分布式缓存（如 Redis）结合校验，实现即时消费与拦截 |
生产级时钟偏移与容差 (Clock Skew / Leeway) 实践
在真实的分布式微服务架构中，授权认证中心与下游 API 网关之间可能因 NTP 同步间隔产生微小的时钟漂移。成熟的生产环境验签中间件（例如 Envoy 的 clock_skew_seconds、Kong 网关或 Node.js 的 clockTolerance）均建议配置 30 至 60 秒的时钟容差。若缺少容差设定，刚在上游签发的令牌在传输至时钟略微落后的下游网关时，极易因边界时刻引发误报拒绝。
密码学数字签名算法全景对比 (RFC 7518 JWA 规范)
RFC 7518 规范将数字签名算法清晰地划分为基于对称共享密钥方案与基于非对称公私钥对方案：
| 签名算法 | 密码学分类 | 密钥体系与要求 | 签名体积 | 验签延迟估算 | 架构权衡考量 |
|---|---|---|---|---|---|
| HS256 | HMAC (SHA-256) | 对称共享密钥 (≥256 位) | 32 字节 | ~10 µs | 性能极高、CPU 开销极小；但需向下游全量校验节点同步分发相同密钥，存在单点泄露全局失效隐患 |
| RS256 | RSASSA-PKCS1-v1_5 + SHA-256 | 非对称 RSA 密钥对 (2048/4096 位) | 256 字节 | ~200 µs | OIDC 与 OAuth 2.0 工业级标准；公钥通过 JWKS 端点公开分发，私钥严防死守；CPU 验证耗时相对较高 |
| ES256 | ECDSA (NIST P-256 + SHA-256) | 非对称椭圆曲线密钥对 | 64 字节 | ~60 µs | 签名体积极为小巧；密码学强度等同于 3072 位 RSA，网络传输负载减少 75%，移动端与边缘节点首选 |
| EdDSA | Ed25519 爱德华曲线 | 非对称扭曲爱德华曲线 | 64 字节 | ~25 µs | 恒定时间算法，天生免疫侧信道计时攻击；现代高性能服务与边缘网关（如 Cloudflare Workers）推荐标准 |
生产网关鉴权异常与排查诊断手册
针对反向代理、API 网关及微服务鉴权拦截中高频出现的异常响应，提供系统级定位基线与修复对策：
| 网关错误响应 | 根本原因定位 | 线上技术核验手段 | 工程修复与优化方案 |
|---|---|---|---|
| 401 token_expired | 令牌 exp 时间戳早于当前网关系统时间，或网关时钟快于认证中心 | 使用服务器命令行 date +%s 比对令牌中声明的 Unix 时间戳 | 配置全量服务器 NTP 时间同步；客户端在令牌到期前 30 秒实施无感静默刷新机制（Silent Refresh） |
| 401 invalid_signature | 密钥不匹配、PEM 格式损坏、或将 Base64 编码的密钥作为普通字符串导入 | 确认认证服务器是以原始 UTF-8 文本还是 Base64 解码后的字节流形式加载密钥 | 统一各服务间密钥的序列化标准；剔除配置中心或环境变量中意外包含的换行符（\n） |
| 403 audience_mismatch | 网关所标识的微服务资源 URI 不在令牌载荷的 aud 数组或字符串中 | 解码审查载荷中的 aud 字段，比对目标服务标识字符串 | 在 OAuth 2.0 换取 Token 的授权请求中明确传入目标 API 资源的 Audience 标识参数 |
| 431 header_too_large | JWT 体积超载，突破反向代理对请求头的长度约束（Nginx/Envoy 默认约为 8KB，Cookie 约 4KB） | 测量 Token 字符串总字节数，排查载荷中是否塞入了庞大的角色权限清单或嵌套树状结构 | 实施轻量化瘦身：将庞大的用户权限下沉至后端 UserInfo 接口或 Redis 分布式会话缓存中按需获取 |
高危安全漏洞与工程防御实践
“alg: none”签名绕过漏洞
部分有缺陷的旧版解析库会动态信任 Header 中的 alg 字段。攻击者若将算法篡改为 {"alg": "none"} 并剥除末尾签名段，可能导致系统跳过验签而直接放行。防御策略：后端网关必须显式硬编码强制指定受信任的算法白名单（如 algorithms: ['RS256']），坚决拦截任何无签名令牌。
密钥混淆攻击 (Key Confusion, CVE-2015-9235)
当原本配置为 RS256 的后端收到被攻击者篡改为 HS256 的伪造令牌时，不严谨的验签代码可能错误地将公开的 RSA 公钥文本直接视作 HMAC 对称密钥进行校验。由于双方均持有公钥，攻击者即可伪造合法签名。防御策略：在调用验签函数前，必须严格断言密钥对象类型与预期算法家族严格匹配。
明文暴露风险 (JWS 签名 vs JWE 加密)
标准紧凑型 JWT 仅具备数字签名（JWS），并不提供数据加密（JWE）。其 Base64URL 编码是公开且极易逆向还原的。切勿在未加密的 JWT 载荷中放置用户密码明文、敏感个人身份信息（PII）、支付银行卡号或内部数据库连接字符串等核心机密数据。
无状态凭证的主动吊销挑战
由于 JWT 属于无状态自包含凭证，令牌一旦签发，在其 exp 过期前无法单方面被服务端注销。工程落地解决方案：将 Access Token 的有效期压短（5~15 分钟），配合保存在安全 HTTP-only Cookie 中的长效 Refresh Token 进行受控轮转，或在 Redis 中维护注销注销黑名单（基于 jti）。
Frequently Asked Questions
未经密钥签名，任何人都能直接解码并查阅 JWT 的内容吗？
是的。标准的 JSON Web Token (RFC 7519) 是经过数字签名的凭证（JWS），而非加密凭证（JWE）。其头部（Header）与载荷（Payload）本质上只是经过 Base64URL 序列化的普通 JSON 文本。任何拦截或获取到该 Token 的第三方，无需任何密钥即可直接逆向解码并读取其中的声明信息。在密码学设计中，对称密钥（HMAC Secret）或非对称公私钥对仅用于生成数字签名及验证防篡改性，并不提供内容机密性保护。
将线上生产环境的 JWT 粘贴到此在线工具中是否安全？
绝对安全。本工具采用 100% 浏览器客户端纯本地沙箱执行架构。无论是 Token 字符串的分段反序列化、时间戳与声明解析，还是基于原生 Web Cryptography API (crypto.subtle) 的密码学验签计算，均全程在您本地设备的内存沙箱中运算。没有任何 Token 文本、身份凭证、HMAC 密钥或 PEM 公钥会通过网络回传至任何后端服务器，亦不包含任何持久化存储或日志记录。
JWT“解码 (Decode)”与“验签 (Verify)”在底层工程与安全上有何本质区别？
解码属于纯粹的反序列化过程，不具备鉴权与安全信任效力：它仅是对 Header 与 Payload 进行 Base64URL 逆向还原，便于开发者直观审查声明、算法与过期时间。验签则属于密码学安全操作：验证方需基于共享密钥或公开密钥，对 header.payload 重新计算 HMAC 哈希或验证 RSA/ECDSA 签名，从数学层面严格证明该令牌确由受信任的认证中心签发，且在网络传输过程中未被篡改。
网关与微服务如何依据载荷声明判定 JWT 是否已过期？
通过审查 Payload 中约定的 exp（Expiration Time）标准注册声明。该字段以 Unix 秒级时间戳（自 1970-01-01 00:00:00 UTC 起算）表示失效时刻。当当前系统时间戳超出 exp 预设值时，即判定令牌失效。本工具会自动将 exp 转换为 UTC 与本地时区时间，并结合客户端时钟进行毫秒级生命周期倒计时呈现。生产网关在校验时通常还会叠加 30~60 秒的容差（Clock Skew Leeway），以抵消分布式机器间的时钟漂移。
为什么使用标准 Base64 解码器处理 JWT 经常报错或出现乱码？
因为 JWT 规范强制采用 Base64URL 编码（RFC 4648 第 5 节），而非传统标准 Base64（RFC 4648 第 4 节）。Base64URL 将 "+" 替换为 "-"、将 "/" 替换为 "_"，并显式去除了末尾所有的 "=" 补位字符，使其能够安全嵌入 HTTP Header、URL Query 参数及 Cookie 中，避免发生 URI 百分号转义或路由分界冲突。若直接调用原生 window.atob() 等标准解码器，必须先将 "-" 和 "_" 替换回 "+" 和 "/"，并依据 (4 - (len % 4)) % 4 规则还原 "=" 补位，否则会导致解析中断或抛出异常。
粘贴 Token 时为什么会提示“令牌格式无效 (Invalid Format)”或“Malformed JWT”？
标准紧凑格式的 JWT 严格由三个由英文半角句点（.）分隔的数据段组成（即 Header.Payload.Signature）。常见的输入格式错误包括：(1) 误带了 HTTP Authorization 请求头中的 "Bearer " 前缀；(2) 复制过程中夹带了多余的空格、换行符或不可见控制字符；(3) 输入了 JWE 加密令牌（JWE 采用五段式结构由 4 个句点分隔）；(4) 载荷中包含非法的 Base64URL 字符或不合法的 JSON 语法。
如果身份认证中心仅提供了 JWKS 端点，如何本地验证 RS256 或 ES256 令牌？
各大主流认证服务（如 Auth0、Okta、Keycloak、Azure AD 或自建 OAuth 2.0 服务）均在 /.well-known/jwks.json 端点公开发布 JSON Web Key Set (JWKS)。在本地验证时：(1) 从 Token 头部提取 kid（Key ID），在 JWKS 中定位匹配的公钥对象；(2) 提取该公钥的模数 n 与指数 e（或椭圆曲线的 x 与 y 坐标）；(3) 利用标准工具或 OpenSSL 将其转换为标准 PEM 格式（以 -----BEGIN PUBLIC KEY----- 开头）；(4) 将转换后的 PEM 公钥粘贴到本工具的公钥输入框中，即可完成本地验签。