【Express】JWT(JSON Web Token)的使用

在其紧凑的形式中，JSON Web Tokens的三个部分组成，这三个部分用点（.）连接在一起就组成了JWT字符串，它们分别是：

• 头部（Header）

• 有效载荷（Playload）

• 签名（Signature）

因此，JWT看起来像如下形式的字符串：

xxxx.yyyy.zzzz

头部（Header）

头部通常由两部分组成：令牌的类型，即JWT，以及所使用的签名算法，例如HMAC SHA256或RSA。如：

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

然后，对这个JSON进行Base64Url编码，形成JWT的第一部分。

有效载荷（Playload）

令牌的第二部分是有效载荷，其中包含声明。声明是关于实体（通常是用户）和其他数据的声明。声明有三种类型：注册声明、公开声明和私人声明。

• 注册声明

这些是一组预定义的声明，不是强制性的，而是推荐的，以提供一组有用的、可互操作的声明。其中一些是：iss（发行者）、exp（到期时间）、sub（主题）、aud（受众）和其他。

注意：声明名称只有三个字符，因为JWT是紧凑的。

• 公开声明

这些可以由使用JWT的人员随意定义。但为了避免冲突，它们应该已经被定义在IANA JSON Web Token Registry中，或者已经被定义为包含抗冲突命名空间的URI。

• 私人声明

这些自定义声明是为了在同意使用它们的各方之间共享信息而创建的，既不是注册声明也不是公开声明。

一个有效载荷的例子：

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

然后对有效负载进行Base64Url编码，以形成JSON Web令牌的第二部分。

注意：对于已签名的令牌，此信息虽然受到保护，防止篡改，但任何人都可以读取。除非加密，否则不要将机密信息放入JWT的有效载荷或标头元素中。

签名（Signature）

要创建签名部分，我们必须要获取编码的头部（Header）、编码的有效负载（Playload）、密钥（Secret）和标头中指定的算法（Algorithm），并对其进行签名（Signature）。

例如，如果要使用HMAC SHA256算法，则将按以下方式创建签名：

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

签名用于验证消息在发送过程中没有被更改，并且，在使用私钥签名的令牌的情况下，它还可以验证JWT的发送者是它所说的人。

头部+有效载荷+签名=JWT

将头部、有效载荷以及签名整合在一起后，所输出的部分是三个由点分隔的Base64 URL字符串，可以在HTML和HTTP环境中轻松传递，同时与基于XML的标准（如SAML）相比更紧凑。

下面显示了一个JWT，它编码了前一个报头（即头部）和有效载荷，并用密钥签名。

eyJhbGciOiJSUzI1NiIsImtpZCI6ImI0OWM1MDYyZDg5MGY1Y2U0NDllODkwYzg4ZThkZDk4YzRmZWUwYWIiLCJ0eXAiOiJKV1QifQ.
eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJuYmYiOjE2NzU5NDQ5NjgsImF1ZCI6IjUxMTE4NzcxMzI1MC1sYXUwNXVodHFscnEyaHFmaW1jdDRtNTh1bXZyZG1kci5hcHBzLmdvb2dsZXVzZXJjb250ZW50LmNvbSIsInN1YiI6IjExMTk3MDUyMjk5MzA4MTAwMjg4NCIsImVtYWlsIjoiZ2VuaHVhbHUyMkBnbWFpbC5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiYXpwIjoiNTExMTg3NzEzMjUwLWxhdTA1dWh0cWxycTJocWZpbWN0NG01OHVtdnJkbWRyLmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwibmFtZSI6Imdlbmh1YSBsdSIsInBpY3R1cmUiOiJodHRwczovL2xoMy5nb29nbGV1c2VyY29udGVudC5jb20vYS9BRWRGVHA1R3J3YXZ5NkFoSHFSSjlJczQ5SldPNEx0OUNtcG9VMVNXdnFvRj1zOTYtYyIsImdpdmVuX25hbWUiOiJnZW5odWEiLCJmYW1pbHlfbmFtZSI6Imx1IiwiaWF0IjoxNjc1OTQ1MjY4LCJleHAiOjE2NzU5NDg4NjgsImp0aSI6IjM1MTg4OWFhYTUyZjMxYzFmZDVhYzRkNTg0YjdjYjdkOTZlYzg2NWEifQ.
XCrdE7SvyhHlDCkwXKuZn2YkFk7lOpTGwY-kVqXghaqZOJtdURHYwrwMJXKeWe0gtsDd--qfNWosEGPfstHVeha_bHsWZi8HKyPSWo35OngYcEKedTx36m9T06mRcCSS53I5B0n_9wPYKgFOsj5PaM1jg-9gq6FOAlQCNQdY9ZckVqRx73z40L04bvQWdXtsZw3-jvaKfWQZQL5EEBohnMZQ9E6_CTKJWSbkfCb8Fu4_uYggmAtftYTdgVnL0SQIOGGEA2x6nnm6Ssjk0gF7LtFH4IbQl4dOKkNagYGTJspaKkdEPtnbxohpIsjvxiKHWz3IjBVGfrJ2wexhunUEEg

如果我们想用实际的数据来更好的理解JWT，可以使用JWT.io（https://jwt.io/#debugger-io）调试器来解码、验证和生成JWT。

如输入上面的JWT，解码后如下图所示：

JWT的工作方式

在身份验证中，当用户使用其凭据成功登录时，将返回一个JSON Web令牌。由于令牌是凭证，因此必须非常小心地防止安全问题。通常，我们不应将令牌保存的时间超过所需的时间。

由于缺乏安全性，我们也不应将敏感会话数据存储在浏览器存储中。

每当用户想要访问受保护的路由或资源时，用户代理都应该发送JWT，通常在使用承载模式的授权标头中。标题的内容应如下所示：

Authorization: Bearer <token>

在某些情况下，这可能是无状态授权机制。服务器的受保护路线将在授权标头中检查有效的JWT，如果存在，将允许用户访问受保护的资源。如果JWT包含必要的数据，则需要减少数据库以查询数据库以减少某些操作，尽管情况并非总是如此。

注意，如果我们通过HTTP头发送JWT令牌，则应尽量防止它们变得太大。某些服务器不接受超过8 KB的标头。如果我们试图在JWT令牌中嵌入太多信息，例如通过包含所有用户的权限，则可能需要另一种解决方案，例如Auth0细粒度授权（https://auth0.com/developers/lab/fine-grained-authorization）。

如果令牌是在Authorization标头中发送的，则跨源资源共享（CORS）不会成为问题，因为它不使用cookie。

获得JWT并用于访问API或资源的流程：

1. 应用程序或客户端向授权服务器请求授权。这是通过一个不同的授权流程执行的。例如，典型的OpenID Connect兼容web应用程序将使用授权代码流通过/oauth/authorize端点。

2. 当授权被授予时，授权服务器向应用程序返回访问令牌。

3. 应用程序使用访问令牌访问受保护的资源（如API）。

注意：对于已签名的令牌，令牌中包含的所有信息都会暴露给用户或其他方，即使他们无法更改。这说明我们不应将机密信息放在令牌中。

使用JWT的理由

JSON Web令牌（JWT）与简单Web令牌（SWT）和安全断言标记语言令牌（SAML）相比的优势。

由于JSON不像XML那么冗长，所以在编码时，它的大小也更小，使得JWT比SAML更紧凑。这使得JWT成为在HTML和HTTP环境中传递的好选择。

安全性方面，SWT只能使用HMAC算法由共享密钥对称签名。然而，JWT和SAML令牌可以使用X.509证书形式的公钥/私钥对进行签名。与签名JSON的简单性相比，使用XML数字签名对XML签名很容易出现安全漏洞。

JSON解析器在大多数编程语言中都很常见，因为它们直接映射到对象。相反，XML没有自然的文档到对象映射。这使得使用JWT比使用SAML断言更容易。

在使用方面，JWT在互联网规模上使用。这突出了在多个平台（尤其是移动平台）上客户端处理JSON Web令牌的方便性。