本文翻译自 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以及密钥签名:

file

4. 如何使用

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

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

Authorization: Bearer <token>

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

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

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

file

5. 为什么要使用

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

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

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