JSON Web 令牌（JWT）是如何保护 API 的？

Posted 2021-04-30 源自开发者

你可以已经听说过 JSON Web Token (JWT) 是目前用于保护 API 的最新技术。

与大多数安全主题一样，如果你打算使用它，那很有必要去了解它的工作原理（一定程度上）。问题在于，对 JWT 的大多数解释都是技术性的，这一点让人很头疼。

让我们看下，我能否解释清楚 JWT 是如何在不引起你的注意下保护您的 API ！

API 验证

某些 API 资源需要限制访问 。例如，我们不希望一个用户能够更改另一个用户的密码。

这就是为什么我们保护某些资源，使用户在允许访问之前提供他的 ID 和密码——换句话说，我们对它们进行身份验证。

保护HTTP API的困难在于请求是 无状态的 —— API 无法知道是否有两个请求来自同一用户。

那么，为什么不要求用户在每次调用 API 时提供其 ID 和密码呢？仅因为那将是可怕的用户体验。

JSON Web Token

我们需要的是一种允许用户仅提供一次其凭证，随后在后续请求中由服务器以另一种方式标识的方式。

为此设计了几种系统，当前的最新标准是 JSON Web Token。

这是一篇 关于该主题的精彩文章 ，它很好地比喻了 JSON Web Token 的工作方式：

想象一下你要入住酒店，而不是一个 API 。「Token」是塑料酒店安全卡，可用于进入你的房间和使用酒店设施，但不能进入任何其他人的房间。

当你退房的时候，你交回卡片。这类似于注销。

Token 的结构

通常， JSON Web Token 是通过 HTTP 请求头发送的。类似如下：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

实际上， Token 部分是「Authorization: Bearer」之后的部分，仅是 HTTP 头信息。

在你断定这是难以理解的胡言乱语前，有几件事你很容易注意到。

首先，Token是由三个不同的字符串组成，以句点分隔。这三个部分是 Base64 编码 后的内容，并且分别对应 Header ， Payload 以及 Signature。

// Header eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

// Payload eyJzdWIiOiIxMjM0NTY3ODkwIn0

// Signature dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

注意：Base64 是一种转换字符串的方法，以确保在跨网络传输期间不会被弄乱。这不是一种加密方式，任何人都可以 轻松解码 以查看原始数据。

我们可以对这些字符串进行解码，以更好地了解JWT的结构。

Header

以下是 Token 中的已解码 Header 部分。Header 是 Token 的元信息。它并没有告诉我们很多帮助你建立基本理解的知识，因此我们不会对此进行任何详细介绍。

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

Payload

Payload 能引起更多的关注。如果你想， Payload 可以包含任何数据，但是如果 Token 的目的是 API 访问身份验证，则可以仅包含用户 ID 。

{
  "userId": "1234567890"
}

请注意， Payload 不安全 。任何人都可以解码 Token ，并确切了解 Payload 中的内容。因此，我们通常会包含一个 ID ，而不是诸如用户电子邮件之类的敏感识别信息。

即使 Payload 是在 API 上识别用户所需要的全部，它也不能提供身份验证的方法。如果其中包含所有内容，则有人可以轻松找到你的用户 ID 并伪造 Token 。

因此，这使我们进入了 Signature 部分，这是认证 Token 的关键部分。

哈希算法

在解释签名如何工作之前，我们需要定义什么是哈希算法。

首先，它是一个将字符串转换为称为 Hash 的新字符串的函数。例如，假设我们要对字符串「Hello, world」进行哈希处理。这是我们使用 SHA256 哈希算法得到的输出：

4ae7c3b6ac0beff671efa8cf57386151c06e58ca53a78d83f36107316cec125f

哈希的最重要属性是 你无法通过哈希算法来查看 Hash 的原始文本 。

有许多不同类型的哈希算法，但 SHA256 通常与 JWT 一起使用。

换句话说，我们不能根据上面的散列值算出原始字符串是 Hello，world。哈希非常复杂，以至于无法猜测原始字符串。

JWT 签名

回到 JWT 结构，来看一下令牌的第三部分，签名。实际上需要计算：

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

下面是对这里发生的情况做解释:

首先， HMACSHA256 是哈希函数的名称， 并带有两个参数：要散列的字符串，以及「secret」。

其次，我们哈希的字符串是 base 64 的编码报头，加上 base 64 的编码有效载荷。

第三, secret 是任意一段字符串，只有服务器知道。

问. 为什么在签名散列中包含标头和有效负载？

这确保了签名对于此特定令牌是唯一的。*

问. secret 是什么?

为了回答这个问题，让我们考虑一下如何伪造令牌。

我们之前说过，您无法通过查看输出来确定哈希的输入。但是，由于我们知道签名包括标头和有效负载，因为它们是公共信息，所以如果您知道哈希算法(提示：通常在标头中指定)，则可以生成相同的哈希。

但是只有服务器知道的秘密 不是 公共信息。将其包含在哈希中可防止某人生成自己的哈希来伪造令牌。而且由于散列会掩盖用于创建散列的信息，因此任何人都无法从散列中找出秘密。

将私有数据添加到哈希中的过程称为 salting ，几乎不可能破解令牌。

认证过程

因此，现在您对令牌的创建方式有了一个很好的了解。您如何使用它来验证您的API？

登录

用户登录时会生成令牌，令牌会与用户模型一起存储在数据库中。

• loginController.js *

if (passwordCorrect) {
  user.token = generateToken(user.id);
  user.save();
}

然后令牌作为authorization头附加到登录请求的响应中。

loginController.js

if (passwordCorrect) {
  user.token = generateToken(user.id);
  user.save();
  res.headers("authorization", `Bearer ${token}`).send();
}

验证请求

现在，客户端有了令牌，他们可以将其附加到任何将来的请求以身份验证用户。

当服务器收到带有授权令牌的请求时，将发生以下情况：

1.它解码令牌并从有效载荷中提取ID。

2.它使用此ID在数据库中查找用户。

3.它将请求令牌与用户模型中存储的令牌进行比较。如果它们匹配，则对用户进行身份验证。

authMiddleware.js

const token = req.header.token;
const payload = decodeToken(token);
const user = User.findById(payload.id);
if (user.token = token) {
  // 通过身份认证
} else {
 // 未通过身份认证
}

退出登录

如果用户注销，只需删除附加到用户模型的令牌，现在令牌将不再起作用。用户将需要再次登录以生成新令牌。

logoutController.js

user.token = null;
user.save();

总结

因此，这是关于如何使用 JSON Web 令牌保护 API 的最基本的说明。希望你不会很头疼。

不过，相关的话题还有很多，所以这里有一些额外的读物：

• [JWT.io]https://jwt.io/
• [什么是 JSON Web 令牌？]https://robmclarty.com/blog/what-is-a-json-web-token
• [了解如何使用 JSON Web 令牌 ( JWT ) 进行身份验证]https://github.com/dwyl/learn-json-web-tokens