imported>Cewbot：清理跨語言連結服务提供者成為內部連結:編輯摘要的紅色連結經繁簡轉換後存在，非bot錯誤編輯 (本次機械人作業已完成24.3%)

2026-04-26T12:53:03Z

清理跨語言連結服务提供者成為內部連結:編輯摘要的紅色連結經繁簡轉換後存在，非bot錯誤編輯 (本次機械人作業已完成24.3%)

新页面

{{Infobox technology standard
| status = [[互联网标准#拟议标准|拟议标准]]
| first_published = 2010年12月28日
| version = {{IETF RFC|7519}}
| version_date = 2015年5月
| organization = [[互联网工程任务组]]
| abbreviation = JWT
| committee = [[互联网工程任务组|互联网工程指导组]]
| authors = Michael B. Jones<br />John Bradley<br />Nat Sakimura
| base_standards = [[JSON]]<br />{{link-en|JSON Web Signature|JSON Web Signature|JSON Web Signature}}（JWS）<br />{{link-en|JSON Web Encryption|JSON Web Encryption|JSON Web Encryption}}（JWE）
| domain = [[数据交换]]
| website = [https://datatracker.ietf.org/doc/html/rfc7519 RFC 7519]
}}

'''JSON Web Token'''（'''JWT'''，建议读音 {{IPAc-en|dʒ|ɒ|t}}，与英语单词“jot”同音）<ref name="rfc7519">
{{
Cite IETF
| title=JSON Web Token (JWT)
| rfc=7519
| last1=Jones
| first1=Michael B.
| last2=Bradley
| first2=John
| last3=Sakimura
| first3=Nat
| date=2015年5月
| publisher=[[互联网工程任务组|IETF]]
| language=en-us
| doi=10.17487/RFC7519
| issn=2070-1721
| ref=rfc7519
}}
</ref>是一项[[互联网标准#拟议标准|拟议中的互联网标准]]，用于建立带有可选[[数字签名|签名]]和／或可选[[加密]]的数据，其[[有效载荷]]中保存用于断言若干声明的 [[JSON]]。这些令牌可以使用共享秘密，或使用[[公钥密码学|公钥／私钥]]进行签名。

例如，服务器可以生成一个带有“已作为管理员登录”这一声明的令牌，并将其提供给客户端。客户端随后便可使用该令牌来证明自己已以管理员身份登录。令牌可以由某一方的私钥（通常是服务器的私钥）签名，以便任何一方随后都能验证令牌是否合法。若另一方通过适当且可信的方式持有对应的公钥，则其也能够验证该令牌的合法性。这些[[会话ID|会话令牌]]被设计为紧凑、<ref>{{cite book |last1=Nickel |first1=Jochen |title=Mastering Identity and Access Management with Microsoft Azure |date=2016 |isbn=9781785887888 |page=84 |publisher=Packt Publishing |url=https://books.google.com/books?id=Q4dcDgAAQBAJ&pg=PA84 |accessdate=2018-07-20}}</ref>[[URL]]安全、<ref name="jwtintro" />且易于使用，尤其适用于[[网页浏览器]]中的[[单点登录]]（SSO）场景。JWT 声明通常可用于在{{link-en|身份提供者|Identity provider|身份提供者}}与[[服务提供者]]之间传递已认证用户的身份信息，或按业务流程需要传递其他类型的声明。<ref>{{Cite web|title=The Anatomy of a JSON Web Token|url=https://scotch.io/tutorials/the-anatomy-of-a-json-web-token|accessdate=2015-05-08|first=Chris|last=Sevilleja|archive-date=2021-11-09|archive-url=https://web.archive.org/web/20211109051217/https://scotch.io/tutorials/the-anatomy-of-a-json-web-token|dead-url=yes}}</ref><ref>{{Cite web|title=Atlassian Connect Documentation|url=https://developer.atlassian.com/static/connect/docs/latest/concepts/understanding-jwt.html|website=developer.atlassian.com|accessdate=2015-05-08|archive-date=2015-05-18|archive-url=https://web.archive.org/web/20150518082002/https://developer.atlassian.com/static/connect/docs/latest/concepts/understanding-jwt.html|url-status=dead}}</ref>

JWT 依赖其他基于 JSON 的标准：{{link-en|JSON Web Signature|JSON Web Signature|JSON Web Signature}} 与 {{link-en|JSON Web Encryption|JSON Web Encryption|JSON Web Encryption}}。<ref name="rfc7519" /><ref name=":1">{{Cite journal|title=draft-ietf-jose-json-web-signature-41 - JSON Web Signature (JWS)|url=https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41|website=tools.ietf.org|date=2015年5月|accessdate=2015-05-08|last1=Jones|first1=Michael B.|last2=Bradley|first2=John|last3=Sakimura|first3=Nat}}</ref><ref name=":2">{{Cite journal|title=draft-ietf-jose-json-web-encryption-40 - JSON Web Encryption (JWE)|url=https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40|website=tools.ietf.org|date=2015年5月|accessdate=2015-05-08|last1=Jones|first1=Michael B.|last2=Hildebrand|first2=Joe}}</ref>

== 结构 ==

; 标头
: 用于标识生成签名时所使用的算法。在下面的例子中，<code>HS256</code> 表示此令牌使用 HMAC-SHA256 进行签名。

: 常见的密码学算法包括使用 [[SHA-256]] 的 [[HMAC]]（HS256），以及使用 SHA-256 的 [[RSA]] 数字签名（RS256）。JWA（JSON Web Algorithms）RFC 7518 还为认证与加密引入了更多算法。<ref>{{Cite journal|title=draft-ietf-jose-json-web-algorithms-40 - JSON Web Algorithms (JWA)|url=https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40|website=tools.ietf.org|date=2015年5月|accessdate=2015-05-08|last1=Jones|first1=Michael B.}}</ref>
:<syntaxhighlight lang="json">{
"alg": "HS256",
"typ": "JWT"
}
</syntaxhighlight>

; 有效载荷
: 包含一组声明。JWT 规范定义了七个已注册声明名称，它们是通常包含在令牌中的[[#标准字段|标准字段]]。<ref name="rfc7519" />此外，也常会根据令牌用途加入自定义声明。
: 以下示例包含标准的签发时间声明（<code>iat</code>）以及一个自定义声明（<code>loggedInAs</code>）。
:<syntaxhighlight lang="json">{
"loggedInAs": "admin",
"iat": 1422779638
}
</syntaxhighlight>

; 签名
: 用于安全地验证令牌。签名的计算方式是先将标头与有效载荷分别使用 [[Base64#URL applications|Base64url 编码]] {{IETF RFC|4648}}，再以句点将二者连接成字符串。随后，将该字符串输入标头中指定的密码学算法中。本例使用带有共享秘密的 HMAC-SHA256（也定义了公钥算法）。''Base64url 编码''与 [[Base64]] 类似，但使用不同的非字母数字字符，并省略填充字符。
:<syntaxhighlight lang="javascript">
HMAC_SHA256(
secret,
base64urlEncoding(header) + '.' +
base64urlEncoding(payload)
)
</syntaxhighlight>

以上三部分分别使用 [[Base64#URL applications|Base64url 编码]] {{IETF RFC|4648}} 编码，再以句点连接，构成 JWT：
<syntaxhighlight lang="typescript">
const token: string = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)
</syntaxhighlight>

以上数据配合秘密“secretkey”会生成如下令牌：

<syntaxhighlight lang="text">eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN
_oWnFSRgCzcmJmMjLiuyu5CSpyHI</syntaxhighlight>

''（上述 JSON 字符串会被格式化为不带换行与空格的 UTF-8 字节数组。这一点很重要，因为哪怕数据仅有细微变化，都会影响最终生成的令牌。）''

由此生成的令牌可以方便地嵌入到 [[HTML]] 与 [[HTTP]] 中。<ref name="jwtintro">{{cite web |title=JWT.IO - JSON Web Tokens Introduction |url=https://jwt.io/introduction/ |website=jwt.io |accessdate=2018-07-20 |archive-date=2019-01-20 |archive-url=https://web.archive.org/web/20190120020618/https://jwt.io/introduction/ |dead-url=no }}</ref>

== 用途 ==

在认证场景中，当用户成功登录后，通常会返回一个 JSON Web Token（JWT）。该令牌应通过安全机制发送给客户端，例如使用[[HTTP cookie#Secure 和 HttpOnly|HTTP-only Cookie]]。通常不建议将 JWT 存储于浏览器的本地存储机制中，例如 [[Web storage|localStorage 或 sessionStorage]]。这是因为运行在客户端的 JavaScript（包括浏览器扩展）可以访问这些存储机制，从而暴露 JWT 并危及安全性。若要在需要与跨来源 API 进行认证时使用 HTTP-only Cookie，较佳做法是使用 <code>credentials</code> 属性，告知浏览器在 Fetch 调用时自动将 Cookie 发送至外部 API，例如：

<syntaxhighlight lang="javascript">
fetch('https://api.example.com/data', {
method: 'GET',
credentials: 'include' // 告知浏览器一并发送 Cookie 等凭证
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));
</syntaxhighlight>

使用这种方式时，JWT 不会暴露给客户端侧 JavaScript；这是在遵循安全最佳实践的同时使用 JWT 的较佳方式。对于无人值守的进程，客户端也可以直接使用预共享密钥生成并签署自己的 JWT，然后将其传递给兼容 [[OAuth]] 的服务，如下所示：

<syntaxhighlight lang="mime">
POST /oauth2/token
Content-type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=eyJhb...
</syntaxhighlight>

若客户端传递了有效的 JWT 断言，服务器将生成一个可用于调用应用程序的 <code>access_token</code>，并将其返回给客户端：

<syntaxhighlight lang="json">
{
"access_token": "eyJhb...",
"token_type": "Bearer",
"expires_in": 3600
}
</syntaxhighlight>

当客户端希望访问受保护的路由或资源时，用户代理通常会发送 JWT，一般是在 <code>Authorization</code> [[HTTP标头]]中使用 <code>Bearer</code> 方案。该标头内容可能如下所示：
Authorization: Bearer eyJhbGci''...<snip>...''yu5CSpyHI

这是一种无状态认证机制，因为用户状态并不会保存在服务器内存中。服务器上的受保护路由会检查 <code>Authorization</code> 标头中的 JWT 是否有效；若存在且有效，用户便可访问受保护资源。由于 JWT 是自包含的，所需信息都已包含其中，因此可减少多次查询数据库的需要。

== 标准字段 ==

{| class="wikitable"
! 代码
! 名称
! 说明
|-
! colspan="2" {{rh}} | 标准声明字段
| 互联网草案定义了以下标准字段（“声明”），可用于 JWT 声明集合中。
|-
| <code>iss</code>
| 签发者
| 标识签发 JWT 的主体，例如组织名称或网站 URL。
|-
| <code>sub</code>
| 主题
| 标识 JWT 的主题，例如用户名或账号编号。
|-
| <code>aud</code>
| 受众
| 标识 JWT 的预期接收方。每个预期会处理该 JWT 的主体'''都必须'''在受众声明中以某个值标识自己。若处理该声明的主体在存在 <code>aud</code> 声明的情况下，无法以其中某个值标识自己，则该 JWT '''必须'''被拒绝。
|-
| <code>exp</code>
| 过期时间
| 标识 JWT 在该时间及之后'''不得'''再被接受处理。其值必须为 NumericDate：<ref name="rfc-7519-section-4.1.4">{{Cite IETF|title=JSON Web Token (JWT)|rfc=7519|sectionname="exp" (Expiration Time) Claim|section=4.1.4|last1=Jones|first1=Michael B.|last2=Bradley|first2=Bradley|last3=Sakimura|first3=Sakimura|date=2015年5月|publisher=[[互联网工程任务组|IETF]]|doi=10.17487/RFC7519|issn=2070-1721}}</ref> 即整数或小数，表示自 [[Unix时间|1970-01-01 00:00:00Z]] 起经过的秒数。
|-
| <code>nbf</code>
| 生效时间
| 标识 JWT 将从何时开始被接受处理。该值必须为 NumericDate。
|-
| <code>iat</code>
| 签发时间
| 标识 JWT 被签发的时间。该值必须为 NumericDate。
|-
| <code>jti</code>
| JWT ID
| 令牌的区分大小写唯一标识符，即使在不同签发者之间也应保持唯一。
|-
! colspan="2" {{rh}} | 常用标头字段
| 以下字段常用于 JWT 的标头中。
|-
| <code>typ</code>
| 令牌类型
| 若存在，则必须设为一个已注册的 [https://www.iana.org/assignments/media-types/media-types.xhtml IANA 媒体类型]。
|-
| <code>cty</code>
| 内容类型
| 若使用嵌套签名或嵌套加密，建议将其设为 <code>JWT</code>；否则应省略此字段。<ref name="rfc7519" />
|-
| <code>alg</code>
| 算法
| 签发者可以自由设置用于验证令牌签名的算法。然而，一些受支持算法并不安全。<ref name="auth0" />
|-
| <code>kid</code>
| 密钥 ID
| 提示客户端使用了哪把密钥来生成令牌签名。服务器会将此值与已存档密钥匹配，以验证签名有效且令牌真实。
|-
| <code>x5c</code>
| X.509 证书链
| 一个 RFC4945 格式的证书链，对应于生成令牌签名时所用的私钥。服务器将使用此信息验证签名有效且令牌真实。
|-
| <code>x5u</code>
| X.509 证书链 URL
| 一个 URL，服务器可从中获取与生成令牌签名所用私钥对应的证书链。服务器将取得并使用这些信息验证签名真实。
|-
| <code>crit</code>
| 关键
| 一组服务器必须理解的标头列表，只有在理解这些标头后，才可接受该令牌为有效。
|-
! 代码
! 名称
! 说明
|}

当前已注册声明名称的列表可由 [[IANA]] 的 JSON Web Token Claims Registry 获取。<ref name="IANAJWT">{{Cite web|date=2015-01-23|title=JSON Web Token (JWT)|url=https://www.iana.org/assignments/jwt/jwt.xhtml/|website=IANA|language=en-US|access-date=2024-12-05}}</ref>

== 实现 ==

JWT 已有许多语言与框架的实现，包括但不限于：
{{colbegin|colwidth=20em}}
* [[.NET Framework|.NET（C#、VB.Net 等）]]
* [[C语言|C]]
* [[C++]]<ref>{{link-en|POCO C++ Libraries|POCO C++ Libraries|POCO C++ Libraries}} 函式库中的 <code>Poco::JWT</code></ref>
* [[Clojure]]
* [[Common Lisp]]
* [[Dart]]
* [[Elixir]]
* [[Erlang]]
* [[Go]]
* [[Haskell]]<ref>{{Cite web|url=https://hackage.haskell.org/package/jose|title=jose: JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) library|website=Hackage|access-date=2022-12-25}}</ref>
* [[Java]]
* [[JavaScript]]
* [[Julia]]
* [[Lua]]
* [[Node.js]]<ref>{{Cite web|url=https://www.npmjs.com/package/jsonwebtoken|title=jsonwebtoken|website=npm|access-date=2018-05-07}}</ref>
* [[OCaml]]
* [[Perl]]<ref>[https://metacpan.org/pod/Crypt::JWT Crypt::JWT] 于 [[CPAN]]</ref>
* [[PHP]]
* [[PL/SQL]]
* [[PowerShell]]
* [[Python]]
* [[Racket]]<ref>[https://pkgs.racket-lang.org/package/net-jwt net-jwt] 于 [https://pkgs.racket-lang.org pkgs.racket-lang.org]</ref>
* [[Raku]]
* [[Ruby]]
* [[Rust]]
* [[Scala]]
* [[Swift]]
{{colend}}

== 漏洞 ==

JSON Web Token 可包含会话状态。但如果项目需求允许在 JWT 到期前使会话失效，那么服务就不能再仅凭令牌本身信任其中的断言。若要验证令牌中记录的会话未被撤销，则必须将令牌断言与{{link-en|数据存储|Data store|数据存储}}进行比对。这样一来，令牌就不再是无状态的，从而削弱了 JWT 的主要优势。<ref>{{cite web |last1=Slootweg |first1=Sven |title=Stop using JWT for sessions |url=http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ |website=joepie91 Ramblings |accessdate=2018-08-01}}</ref>

安全顾问 Tim McLean 曾报告，某些 JWT 函式库在使用 <code>alg</code> 字段验证令牌时存在漏洞，最常见的情况是接受了 <code>alg=none</code> 的令牌。尽管这些漏洞后来已被修补，McLean 仍建议彻底弃用 <code>alg</code> 字段，以防止类似的实现混淆。<ref name="auth0">{{Cite web|first=Tim|last=McLean|date=2015-03-31|title=Critical vulnerabilities in JSON Web Token libraries|url=https://www.chosenplaintext.ca/2015/03/31/jwt-algorithm-confusion.html|publisher=Auth0|accessdate=2016-03-29}}</ref>尽管如此，现实中仍不断发现新的 <code>alg=none</code> 漏洞；在 2018 至 2021 年间，已有四个[[公共漏洞和暴露|CVE]]与此原因有关。<ref>{{cite web |title=CVE - Search Results |url=https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jwt+none |website=cve.mitre.org}}</ref>

若设计得当，开发者可以通过采取以下预防措施来应对算法漏洞：<ref name="vuln">{{Cite web|url=https://connect2id.com/products/nimbus-jose-jwt/vulnerabilities|language=en|access-date=2018-05-14|title=Common JWT security vulnerabilities and how to avoid them}}</ref><ref>{{cite web |last1=Andreas |first1=Happe |title=JWT: Signature vs MAC attacks |url=https://snikt.net/blog/2019/05/16/jwt-signature-vs-mac-attacks/ |website=snikt.net |accessdate=2019-05-27}}</ref>

* 不要仅凭 JWT 标头驱动验证流程
* 了解相关算法（避免只依赖 {{code|alg}} 字段）
* 使用适当大小的密钥

2017 年，一些 JWT 函式库被发现容易受到[[椭圆曲线密码学#无效曲线攻击|无效椭圆曲线攻击]]。<ref>{{Cite web |title=Critical Vulnerability in JSON Web Encryption |url=https://auth0.com/blog/critical-vulnerability-in-json-web-encryption/ |access-date=2023-10-14 |website=Auth0 - Blog |language=en}}</ref>

也有人认为，由于标准中提供了大量不同的加密算法与选项，JSON Web Token 难以被安全地使用，因此网页前端<ref>{{Cite web |title=No Way, JOSE! Javascript Object Signing and Encryption is a Bad Standard That Everyone Should Avoid - Paragon Initiative Enterprises Blog |url=https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid |access-date=2023-10-13 |website=paragonie.com}}</ref>与后端<ref>{{Cite web |title=Pitfalls of JWT Authorization |url=https://authzed.com/blog/pitfalls-of-jwt-authorization |access-date=2023-11-16 |website=authzed.com}}</ref>都应改用其他替代标准。

== 参见 ==

* [[API密钥]]
* [[访问令牌_(Windows) | 访问令牌]]
* [[HTTP基本认证]]
* [[摘要访问认证]]
* [[HTTP头字段]]
* {{link-en|简洁二进制对象表示法|Concise Binary Object Representation|简洁二进制对象表示法（CBOR）}}

== 参考文献 ==
{{Reflist|30em}}

* {{IETF RFC|7519}}
* [https://jwt.io/ jwt.io] — 由 Auth0 维护的 JWT 专门网站，提供工具与文档

[[Category:计算机访问控制]]
[[Category:身份管理]]
[[Category:联邦身份]]
[[Category:身份管理系统]]
[[Category:元数据标准]]
[[Category:JSON]]

JSON Web Token - 版本历史

imported>Cewbot：​清理跨語言連結服务提供者成為內部連結:編輯摘要的紅色連結經繁簡轉換後存在，非bot錯誤編輯 (本次機械人作業已完成24.3%)

imported>Cewbot：清理跨語言連結服务提供者成為內部連結:編輯摘要的紅色連結經繁簡轉換後存在，非bot錯誤編輯 (本次機械人作業已完成24.3%)