线上JWT解码

JWT SEO KNOWLEDGE BASE

线上JWT解码完整指南：JSON Web Token 是什么、如何验证与如何安全使用

如果你正在搜寻「JWT Decoder」、「JWT 解码器」、「JSON Web Token 解析」、「JWT Verify」或「JWT Encoder」，通常代表你手上已经有一段 token，需要快速看懂它的 Header、Payload、过期时间、签章演算法与 claims。这个页面不只提供线上 JWT 解码工具，也整理开发者最常查询的 JWT 基础知识。

JWT 是什么？

JWT 是 JSON Web Token 的缩写，是一种用 JSON 表示资讯、再转成精简字串的 token 格式。它常被用在前后端分离网站、App API、会员登入、单一登入 SSO、微服务授权与服务间资料交换。

JWT 解码不需要密码，因为 Header 和 Payload 只是 Base64URL 编码，不是加密。任何拿到 token 的人都可以用 JWT Decoder 看见 Payload 内容，因此 claims 不能放密码、API key 或敏感个资。

JWT 什么时候使用？

最常见的使用情境是授权。使用者登入成功后，授权伺服器签发 JWT，前端或 App 在之后呼叫 API 时，把 token 放在 HTTP Authorization header，例如 Authorization: Bearer 。

JWT 也常用于资讯交换。当两个系统需要交换可验证的资料时，签章可以让接收端确认资料没有在传输过程中被更改。大型系统常用 JWKS 端点公开公钥，让不同服务能验证 token 来源。

JWT 三段结构：Header、Payload、Signature

标准 JWT 通常由三段以句点分隔的 Base64URL 字串组成：Header.Payload.Signature。第一段 Header 描述 token 类型与签章演算法，第二段 Payload 放 claims，第三段 Signature 用来验证完整性。

常见 registered claims 包含 iss、sub、aud、exp、nbf、iat 与 jti。良好的 API 验证通常会至少检查 exp、iss 与 aud。

JWT 如何在登入与 API 中运作？

典型流程是：使用者登入，授权伺服器验证帐密或第三方登入结果，接着签发 access token；前端把 access token 附在 API 请求中；后端 API 验证 token 后回传受保护的资料。

JWT 不是万能的 session 替代品。 token 一旦签发，在过期前通常不需要查资料库就能被验证，但撤销 token、权限即时变更与登出处理仍需要设计。

JWT Validation 与 JWT Verification 有什么不同？

JWT validation 通常指检查 token 是否符合预期规则，例如是否有三段、是否能解码、JSON 是否合法、是否过期、issuer 是否正确、audience 是否符合目前 API。

JWT verification 则会用指定演算法与金钥重新计算签章，再和 token 第三段 Signature 比对。看得懂 Payload 不代表 token 可信；正式 API 必须做验章与 claims 验证。

JWT Decode 与 JWT Encode 差在哪里？

JWT Decode 是把 token 第一段和第二段转回 JSON，让你阅读 Header 与 Payload。 JWT Encode 则是反向流程：准备 Header JSON 和 Payload JSON，产生 Signature，最后组合成完整 token。

如果你只是想看 Payload 内容，不需要 secret；如果你要确认 token 是否真的由你的系统签发，就必须使用正确 secret 或公钥验证 Signature。目前本页支援 HS256。

JWT Claims 对照：解码后应该看哪些栏位？

使用线上JWT解码时，你应该同时检查 token 是谁签发、发给哪个系统、何时生效、何时过期，以及权限范围是否符合 API 需求。下表整理常见 JWT claims。

HS256、RS256、ES256 怎么选？

JWT Header 里的 alg 会告诉验证端应该使用哪种演算法。 HS256 是 HMAC SHA-256，签发和验证都使用同一组 secret；RS256 使用 RSA 私钥签章、公钥验章；ES256 使用椭圆曲线演算法。

后端应该明确指定允许的演算法清单，不要让攻击者透过修改 Header 影响验证流程。若 JWT 来自 identity provider，通常要取得 JWKS 或公钥，并检查 kid、iss、aud、exp。

JWT 常见错误与排查方式

使用 JWT Decoder 时最常遇到的问题，是 token 不是标准三段格式、Base64URL 字串被复制不完整、前后多了空白、payload 不是合法 JSON，或签章 secret 使用错误。若 API 回传 401 或 403，建议先解码 JWT，确认 exp、aud、scope。

JWT、Session、SAML 有什么差异？

Session 通常把状态保存在伺服器或集中式储存，浏览器只保存 session id；JWT 则把部分状态放在 token 里，让 API 可用签章验证完整性。 SAML 以 XML 为主，常见于企业 SSO。

JWT 安全建议：白帽 SEO 也要写清楚风险

• 不要把密码、私钥、API key、付款资料或敏感个资放在 JWT Header 或 Payload。
• 设定合理的 exp，不要让 access token 长期有效。
• 后端验证时要固定允许的演算法，不要盲目信任 Header 的 alg。
• 使用足够长且随机的 HS256 secret；生产环境不要使用范例 secret。
• 检查 iss、aud、nbf、iat 与必要权限 claims。
• 避免把过大的权限清单塞入 JWT，以免 header 太大或造成资料外泄。
• 前端储存 token 要评估 XSS、CSRF、Cookie 属性与浏览器储存风险。

这个线上JWT解码工具采用浏览器本机处理：你贴上的 token、secret、Header JSON 和 Payload JSON 不会被上传到 ToolBoy 伺服器。即使如此，处理真实 production token 时仍应遵守最小揭露原则。

JWT 除错常搭配哪些工具？

JWT 经常和 JSON、Base64URL、URL query、timestamp、SHA-256、UUID、regex 等资料格式一起出现在 API 除错流程中。你可以搭配 ToolBoy 的 JSON 格式化工具、Base64 编码解码、Unix 时间戳转换或 UUID 产生器。

延伸阅读可参考 jwt.io 的 JSON Web Token Introduction 与 RFC 7519。本页内容以中文重新整理与改写，重点放在实务除错、白帽 SEO 与本机隐私。