jwt 简介（译）

tech
,

JSON Web Token（JWT）是一个开放的标准（RFC 7519），该标准定义了一个在两者之间安全的使用 JSON 对象传递信息的方式，这种方式紧凑并且自成一体。这个信息可以被验证和信任因为它是一种数字签名。JWTs 可以通过使用密匙（用哈希算法）或者用 RSA 加密算法的公私密匙签署。

让我们进一步解释一下这个定义的一些概念：

  • 紧凑：因为它的大小，它可以通过一个 URL、POST 参数、或者放在 HTTP 头部 进行发送。另外它的大小可以使其传播迅速。
  • 自成一体：这个载体（payload）包含所有的用户请求信息，避免频繁的查询数据库。

应该在什么时候使用 JSON Web Tokens？

这里有一些使用 JSON Web Tokens 的场景：

  • 登陆验证：这是使用 JWT 的典型场景，一旦用户登录之后，每个后续的请求将包含 JWT，通过这个令牌允许用户访问路由、服务和资源。单点登录现在被广泛使用，因为它的开销很小，并且它能够很容易地使用在不同领域的系统之间。
  • 信息交流：JSON Web Token 是在不同部分传递信息的好方法，因为它们可以被签署，例如使用 public/private key，可以确定的是发送者是谁。另外，签名是使用 Header（头部）和 Payload（载荷）计算得出的，可以验证内容没有发生改变。

JSON Web Token 的结构？

JSON Web Tokens 由三个部分组成并使用“.”作为间隔：

  • Header
  • Payload
  • Signature
    因此，一个 JWT 通常看起来像下面这样：
    xxxxx.yyyyy.zzzzz

让我们分解这几部分。

头部由两部分组成：token 的类型：JWT，加密算法：如 HMAC SHA256 或 RSA。
例子：

1
2
3
4
{
  "alg": "HS256",
  "typ": "JWT"
}

然后，这个 JSON 被使用 Base64Url 编码形成 JWT 的第一部分。

Payload

token 的第二部分是载体（payload），载体包含一些声明（claims）。这些声明包含一个实体（特点，用户）和附加的数据。声明（claims）有三种类型：reserved，public，private。

  • Reserved claims：这是一组预定义的声明，建议这个声明但不强制要求，这里提供了一组有用的、能共用的声明。例如：iss（issuer），exp（expiration time），sub（subject），aud （audience）等等。
    注意：这些声明的名字只有 3 个字，因为 JWT 是紧凑的

  • Public claims：这些可以通过 JWTs 随意定义。但为了避免冲突，他们应该使用 IANA JSON Web Token Registry 定义或使用 URL 定义。

  • Private claims：这是为了双方同意分享数据创建的自定义声明。（原文：These are the custom claims created to share information between parties that agree on using them.）
    例子：

    1
    2
    3
    4
    5
    {
      "sub": "1234567890",
      "name": "John Doe",
      "admin": true
    }

然后，这个 JSON 被使用 Base64Url 编码形成 JWT 的第二部分。

Signature

要创建签名部分，你必须提供 Header 编码、Payload 编码、密匙，在首部指定算法。
例如：如果你想使用 HMAC SHA256 算法， 签名将以下面的方式进行创建：

1
2
3
4
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

签名被用于验证 JWT 中的发送者是谁，并确保信息在传输途中没有发生改变。

把三部分组合起来

输出三个用点分割开的 Base64 编码的字符串，可以很容易在 HTML 和 HTTP 环境中使用，与像 SAML 这种基于 XML-based 的标准更加紧凑。
下面展示了一个 JWT。
a jwt
如果你想使用 JWT 并实践这些概念，你可以使用 jwt.io Debugger 进行解码、验证并生成 JWTs。
jwt debugger

JSON Web Tokens 是怎么工作的？

在身份验证中，当用户成功的使用他的凭证登录后，服务器将返回一个 JSON Web Token，保存到本地（通常存储在 local storage，但也可以使用 cookies）。而不是像传统方法那样，在服务器上创建一个 session，返回cookie。

当用户想访问一个受保护的路由或资源时，应该使用 JWT，通常在 Authorization header 使用 Bearer schema。因此头部的内容应该像下面这样。

1
Authorization: Bearer <token>

这是一个无状态的验证机制，因为用户的状态不保存在服务器中。服务器中受保护的路由，会检查在 Authorization header 是否有一个有效的 JWT，如果有的话，用户会被允许通过。JWTs 是自成一体的，包含了所有的必要的信息，减少了返回信息和转发到数据库的必要。

这允许完全依赖数据 API，它是无状态的并且甚至可以发送请求到下游服务。（原文：This allows to fully rely on data APIs that are stateless and even make requests to downstream services. ）它不关心是那个域在使用你的 APIs，跨域资源共享（CORS）将不再是一个问题，因为它不使用 cookies。

下图显示了这个过程：
jwt 过程

为什么要使用 JSON Web Tokens？

我们谈谈 JSON Web Tokens（JWT）的好处，并与 Simple Web Tokens （SWT）和Security Assertion Markup Language Tokens （SAML）进行对比。

由于 JSON 比 XML 更简洁，当它被编码之后它的体积更小，使得 JWT 与 SAML 相比更紧凑。这使得 JWT 是一个好的选择，当在 HTML 和 HTTP 环境中进行传递时。

JSON 解析器在大多数编程语言常见的，因为它们直接映射为对象，反之 XML 不能直接进行的文件到对象的映射。这使得 JWT 比 SAML 更容易声明。

至于作用范围，JWT 适用于大规模的互联网范围。突出展现了其跨平台的易用性，尤其是在移动设备上的应用。
jwt vs saml
JWT 和 SAML 编码后的长度的比较

如果你想了解更多 JSON Web Tokens 并开始在你的应用中使用它们进行认证，打开在 Auth0 的 JSON Web Token landing page。

相关文章：

1、关于 Tokens，你应该知道的 10 件事（待补充）
2、待补充

原文地址：https://jwt.io/introduction