JWT （Json Web Token）简介

本文翻译自 JWT 官方网站对 JWT 是什么以及能做什么的简介。

原文：Introduction to JSON Web Tokens

JWT 是一种用于双方之间传递安全信息的简洁的、URL 安全的表述性声明规范。JWT 作为一个开放的标准（RFC 7519），定义了一种简洁的，自包含的方法用于通信双方之间以 Json 对象的形式安全的传递信息。因为数字签名的存在，这些信息是可靠的，JWT 可以使用 HMAC 算法或者是 RSA 的公私密钥对进行签名。

主要特点：

• 简洁（Compact）：可以使用 URL，POST 参数或者在 HTTP header 发送，因为数据量小，传输速度也很快。

• 自包含（Self-contained）：负载中包含了所有用户所需要的信息，避免了多次查询数据库。

1. 主要应用场景

1.1 身份认证

在这种场景下，一旦用户完成了登录，在接下来的每个请求中包含 JWT，可以用来验证用户身份以及对路由，服务和资源的访问权限进行验证。由于它的开销非常小，可以轻松的在不同域名的系统中传递，所以目前在单点登录（SSO）中比较广泛的使用了该技术。

1.2 信息交换

在通信的双方之间使用 JWT 对数据进行编码是一种非常安全的方式，由于它的信息是经过签名的，可以确保发送者的信息是没有经过伪造的。

2. 结构组成

JWT 包含了使用 . 分隔的三部分：

• Header 头部

• PayLoad 负载

• Signature 签名

其结构看起来是这样的：

xxxxx.yyyyy.zzzzz

2.1 Header

在 header 中通常包含了两部分：

• token 类型

• 采用的加密算法

{
    "typ": "JWT",
    "alg": "HS256"
}

接下来对这部分内容使用 Base64Url 编码组成了 JWT 结构的第一部分。

2.2 Payload

Token 的第二部分是负载，它包含了 claim，Claims 是一些实体（通常指的用户）的状态和额外的元数据，有三种类型的 claim。

2.2.1 Reserved claims

这些 claim 是 JWT 预先定义的，在 JWT 中并不会强制使用它们，而是推荐使用。

常用的有：

• iss [issuer] - JWT 的签发者。

• sub [subject] - JWT 的主题。

• aud [audience] - JWT 的接收者。

• exp [expire] - JWT 的截止期，可能会预留几分钟的缓冲期，unix 时间戳格式。

• nbf [not before] - JWT 的有效起始时间，可能会预留几分钟的缓冲期，unix 时间戳格式。

• iat [issued at] - JWT 的签发时间，unix 时间戳格式。

• jti [JWT ID] - JWT 的唯一标识。

2.2.2 Public claims

根据需要定义自己的字段，注意应该避免冲突。

2.2.3 Private claims

这些是自定义的字段，可以用来在双方之间交换信息。

负载使用的例子：

{
    "sub": "1234567890",
    "name": "John Doe",
    "admin": true
}

上述的负载需要经过 Base64Url 编码后作为 JWT 结构的第二部分。

2.3 Signature

创建签名需要使用编码后的 header 和 payload 以及一个密钥，使用 header 中指定签名算法进行签名。例如如果希望使用 HMAC SHA256 算法，那么签名应该使用下列方式创建：

HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    secret
)

签名用于验证消息的发送者以及消息是否被篡改。

3. 完整实例

JWT 格式的输出是以 . 分隔的三段 Base64 编码，与 SAML 等基于 XML 的标准相比，JWT 在 HTTP 和 HTML 环境中更容易传递。
下列的 JWT 展示了一个完整的 JWT 格式，它拼接了之前的 Header，Payload以及密钥签名：

4. 如何使用

在身份鉴定的实现中，传统方法是在服务端存储一个 session ，给客户端返回一个 cookie ，而使用 JWT 之后，当用户使用它的认证信息登陆系统之后，会返回给用户一个 JWT ，用户只需要本地保存该 token（通常使用 local storage ，也可以使用 cookie ）即可。

当用户希望访问一个受保护的路由或者资源的时候，通常应该在 Authorization 头部使用 Bearer 模式添加 JWT ，其内容看起来是下面这样：

Authorization: Bearer <token>

因为用户的状态在服务端的内存中是不存储的，所以这是一种无状态的认证机制。服务端的保护路由将会检查请求头 Authorization中 的 JWT 信息，如果合法，则允许用户的行为。由于 JWT 是自包含的，因此减少了需要查询数据库的需要。

JWT 的这些特性使得我们可以完全依赖其无状态的特性提供数据 API 服务，甚至是创建一个下载流服务。因为 JWT 并不使用 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）。

下面的序列图展示了该过程：

5. 为什么要使用

相比 XML 格式，JSON 更加简洁，编码之后更小，这使得 JWT 比 SAML 更加简洁，更加适合在 HTML 和 HTTP 环境中传递。

在安全性方面，SWT 只能够使用 HMAC 算法和共享的对称密钥进行签名，而 JWT 和 SAML token 则可以使用 X.509 认证的公私密钥对进行签名。与简单的 JSON 相比，XML 和 XML 数字签名会引入复杂的安全漏洞。

因为 JSON 可以直接映射为对象，在大多数编程语言中都提供了 JSON 解析器，而XML则没有这么自然的文档 - 对象映射关系，这就使得使用 JWT 比 SAML 更方便。