什么是 JWT【译】

来自jwt.io的一篇文章对JWT进行介绍，通过这篇文章了解下什么是 JWT，为什么要使用 JWT，相信你可以从这里找到答案。原文点击这里

什么是JWT(JSON Web Token)

JSON Web Token(JWT) 是由开放标准（RFC 7519）定义的一种JSON对象，它被定义成紧凑且自包含的方式以用于在各方之间安全地传输信息。由于JWT是经过数字签名的，因此可以被验证和信任。可以使用密钥（使用HMAC算法）或者使用非对称加密（公钥/私钥）RSA或ECDSA对JWT进行签名。
尽管JWT可以被加密，也在传输的各方之间提供了保密性，但我们会将重点放在已签名的令牌。已签名的令牌可以验证其中包含的声明(Claim)的完整性，而加密的令牌当中声明则对其他人不可见。当使用公钥/私钥对对令牌进行签名时，签名还证明只有持有私钥的一方才是对其进行签名的一方。

什么时候应该使用JWT

这些场景下，JWT很有用：

授权：这是使用JWT的最常见方案。用户登录后，每个后续请求都将包含JWT，从而允许用户访问该令牌允许的路由，服务和资源。单点登录功能就广泛使用了JWT，因为它的开销很小并且可以轻松地在不同的域中使用。
信息交换：JSON Web令牌是在各方之间安全地传输信息的一种好方法。因为可以对JWT进行签名（例如，使用公钥/私钥对），所以您可以确保发件人是他们所说的人。此外，由于签名是使用标头和有效负载计算的，因此您还可以验证内容是否未被篡改。

JWT的结构

在紧凑的模式下，JWT是由三部分组成并且，这三部分之间由 . 隔开，他们分别是：

头部
负载
签名

因此，一个JWT通常看起来像下面这个样子：

1	xxxxx.yyyyy.zzzzz

让我们分别对这三部分进行讲解：

JWT头部通常包括两部分：令牌的类型是JWT，被使用的签名算法(比如说： HMAC SHA256 或者 RSA)
示例：

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

然后，将上面的 JSON 用 Base64Url 进行编码，形成 JWT 的第一部分

负载

令牌的第二部分是负载，包含了声明，声明是有关实体（通常是用户）和其他数据的描述。共有三种类型的声明：registered, public, private 。

Registered claims：它预定义了一些推荐使用(非强制)的声明字段，这些字段通常都很有用。其中的一些是：iss (issuer)：由谁签发, exp (expiration time)：过期时间, sub (subject)：面向的用户, aud (audience)：接收方，还有其他字段，详见这里
Public claims：这些可以由使用JWT的人员随意定义。但是为避免冲突，应在IANA JSON Web令牌注册表中定义它们，或将其定义为包含抗冲突名称空间的URI。
Private claims: 这些是为在同意使用它们的各方之间共享信息而创建的自定义声明，既不是注册声明也不是公共声明。
示例如下：

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

将上面的JSON用Base64Url进行编码，形成JWT的第二部分。

1	请注意，对于已签名的令牌，此信息尽管可以防止篡改，但任何人都可以读取。除非将其加密，否则请勿将机密信息放入JWT的有效负载或报头元素中。

签名

要创建签名部分，您必须获取编码的标头，编码的有效载荷，机密，标头中指定的算法，并对其进行签名。
例如，如果要使用HMAC SHA256算法，则将通过以下方式创建签名：

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

签名用于验证消息在此过程中没有更改，并且对于使用私钥进行签名的令牌，它还可以验证JWT的发送者是它所说的真实身份。

将三部分结合在一起

输出是由点分隔的三个Base64-URL字符串，可以在HTML和HTTP环境中轻松传递这些字符串，与基于XML的标准（例如SAML）相比，它更紧凑。
下图显示了一个JWT，它已对先前的标头和有效负载进行了编码，并用一个密钥进行了签名。

1	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.cThIIoDvwdueQB468K5xDc5633seEFoqwxjF_xSJyQQ

JWT是如何工作的

在身份验证中，当用户使用其凭据成功登录时，将返回JSON Web令牌。由于令牌是凭据，因此必须格外小心，以防止出现安全问题。通常，令牌的保留时间不应超过要求的时间。由于缺乏安全性，您也不应该将敏感的会话数据存储在浏览器存储中。每当用户想要访问受保护的路由或资源时，用户代理都应发送JWT，通常使用承载模式在Authorization标头中发送JWT。标头的内容应如下所示：

1	Authorization: Bearer <token>

在某些情况下，这可以是无状态授权机制。服务器的受保护路由将在Authorization标头中检查有效的JWT，如果存在，则将允许用户访问受保护的资源。如果JWT包含必要的数据，则可以减少查询数据库以进行某些操作的需求，尽管这种情况并非总是如此。如果令牌在授权标头中发送，则跨域资源共享（CORS）不会成为问题，因为它不使用cookie。下图显示了如何获取JWT并将其用于访问API或资源：

1、应用程序或客户端向授权服务器请求授权。这是通过不同的授权流程之一执行的。例如，典型的符合OpenID Connect的Web应用程序将使用授权代码流通过 /oauth/authorize 端点。
2、授予授权后，授权服务器会将访问令牌返回给应用程序。
3、应用程序使用访问令牌来访问受保护的资源（例如API）。
请注意，使用签名的令牌，令牌中包含的所有信息都会向用户或其他方公开，即使他们无法更改它。这意味着您不应将机密信息放入令牌中。

为什么需要使用JWT

让我们谈谈与简单Web令牌（SWT）和安全性声明标记语言令牌（SAML）相比，JSON Web令牌（JWT）的好处。
由于JSON不如XML冗长，因此在编码时JSON的大小也较小，从而使JWT比SAML更为紧凑。这使得JWT是在HTML和HTTP环境中传递的不错的选择。在安全方面，只能使用HMAC算法由共享机密对SWT进行对称签名。但是，JWT和SAML令牌可以使用X.509证书形式的公用/专用密钥对进行签名。与签名JSON的简单性相比，使用XML Digital Signature对XML进行签名而不引入模糊的安全漏洞是非常困难的。JSON解析器在大多数编程语言中都很常见，因为它们直接映射到对象。相反，XML没有自然的文档到对象的映射。与SAML断言相比，这使使用JWT更加容易。关于用法，JWT是在Internet规模上使用的。这突显了在多个平台（尤其是移动平台）上对JSON Web令牌进行客户端处理的简便性。

QIN BLOG