01
先确认时间单位
exp、nbf、iat 的 NumericDate 使用 Unix 秒，别把常见的毫秒时间戳直接填入 JWT。
开发者参考资料
JWT 声明与 OAuth 错误
输入声明名或 OAuth 错误码，按端点查看虚构示例、字段含义和 RFC 来源。
JWT 声明
匹配条目
exp
响应位置: JWT 声明 · RFC 7519
含义: 到期时间，NumericDate 使用 Unix 秒。
比较 Unix 秒，而非毫秒。
虚构响应示例
{ "exp": 1893456000 }仅为虚构数据，不可当作真实凭据。
查询只在本浏览器执行；点来源链接时才离开本页。
类别
显示 1 / 共 23 条
RFC 7519 / 6749 / 6750核对日期：2026 年 9 月 23 日
JWT 声明中的 iss、aud、exp 经常出现在日志或解码结果里。先查它们的标准含义和数值单位，避免把字段值误当令牌已通过验证。
OAuth 错误码还要结合端点看：授权回调、令牌响应和 Bearer 资源响应的位置不同。本页只查询内置资料，不需要粘贴真实凭据。访问令牌声明可能还有平台扩展，需以提供方资料为准。
为什么使用这份 JWT 声明参考
为什么使用这份 JWT 声明参考
先看字段语义
JWT 声明卡片把 exp 的 Unix 秒示例和 RFC 定义放在一起；读取载荷不等于检查签名、受众或当前登录状态。
同名错误分开看
invalid_request 在授权回调、令牌 JSON 和 Bearer 响应头里有不同位置。按端点分组，才能找到实际要排查的环节。
从字段走到正确诊断
02
再确认错误来源
遇到 OAuth 错误码，先分清是授权端点、令牌端点还是资源服务器，再看响应示例。
03
最后核对规范
打开条目的 RFC 锚点，结合服务商文档；需要检查真实令牌时再进入独立调试工具。
把字段、错误和出处连起来
七个注册声明
RFC 7519 的七个注册 JWT 声明各有虚构字段示例和对应的小节链接。
按端点列错误
RFC 6749 的授权错误与令牌错误分开，即使 error 字符串相同也不会合并语境。
Bearer 响应示例
RFC 6750 的错误展示 WWW-Authenticate 头及建议的 HTTP 状态。
资料范围和实际限制
- 不验证身份
- 这份 JWT 声明参考不接收令牌、不验签，也不能判断会话或认证是否有效。
- 不是全部扩展
- 只覆盖 RFC 7519、RFC 6749 和 RFC 6750 的选定条目，不自动同步 OIDC 或厂商扩展。
- 错误说明不是机器码
- OAuth 的 error_description 是可选的人类可读说明；程序应先按 error 和端点判断。
- 不接收凭据
- 不要在这里粘贴真实 JWT、签名密钥或授权码，也不要把它们放进 URL 参数；本页只查固定资料。
- 不探测服务器
- 搜索不会联系身份提供方，也不会向关联工具自动传值。真实请求需要用户自己进入调试器。
- 错误必须结合端点
- 同一个 invalid_request 在不同端点的返回位置不同；Bearer 的 invalid_token 与 insufficient_scope 对应不同状态建议。
- 不显示实时过期
- NumericDate 示例使用 Unix 秒。固定示例无法判断当前会话或未输入令牌是否已过期。
JWT 声明常见问题
JWT 的 iss 和 aud 声明分别是什么意思？
iss 表示签发者，aud 表示预期接收方；实际服务还必须按自己的上下文验证两者。
JWT 必须包含 exp 声明吗？
不一定。RFC 7519 注册了 exp，但是否必需由具体协议配置和应用策略决定。
OAuth 的 invalid_grant 和 invalid_client 有什么区别？
invalid_client 表示客户端认证失败；invalid_grant 针对授权凭据或刷新令牌。
error_description 字段可以作为程序判断依据吗？
不建议。error_description 可选且供开发者阅读，服务商的措辞可能变化。
解码 JWT 后能确认令牌有效吗？
不能。解码只显示内容，仍需验证签名、签发者、受众、时间及应用策略。
发现条目缺失或内容有误？