跨多个微服务使用 JWT 身份验证答案

【问题标题】：Using JWT authentication across multiple microservices跨多个微服务使用 JWT 身份验证
【发布时间】：2020-02-05 18:53:47
【问题描述】：

我已经在网上搜索了有关此问题的答案，但没有什么与我的设置非常相似。

所以我有一个单页应用程序和 3 个服务：

后端服务 - 服务 A
为 SPA 的静态文件提供服务的服务 - 服务 B
身份验证服务 - 服务 C

流程如下：

用户通过访问服务 B 的 / 访问该站点会被重定向到服务 B 的 /login。
用户输入凭据并将其发送到服务 C 以执行身份验证过程并为用户获取权限，此数据在 JWT 中发送。
然后服务 B 将其放入 cookie 中并将其返回给用户的浏览器。
然后用户执行了一个需要 JWT 的任务，所以我必须将该 cookie 发送到服务 A，但是有一个问题，我不能这样做，cookie 仅适用于服务 A。

https://auth0.com/docs/security/store-tokens - 这个链接是我发现的一个来源的例子，它讨论了在哪里存储 SPA 令牌的问题。它在那里说我应该使用 cookie 来存储 JWT，如果：

如果有我自己的后端
如果后端与网站本身在同一个域中。

问题是我的后端有一个不同的 URL，它是一个完全不同的服务，所以使用 cookie 不是解决方案，或者至少在我看来是这样。

然后它说：

如果您的单页应用完全有后端服务器，则应使用授权代码流、带有代码交换证明密钥的授权代码流 (PKCE) 或混合流在服务器端处理令牌。

这里的问题是他们甚至没有提到如何以及在哪里存储 JWT，以便我可以从多个域访问它。

我还没有找到一种干净的方法来将该 JWT 保存在用户的浏览器上，并在我向后端执行的每个请求中发送它。

我需要的解决方案是以安全的方式将 JWT 保存在用户的浏览器中，以便我将其发送到我需要的任何后端服务。

感谢您迄今为止的阅读和帮助！

【问题讨论】：

标签： authentication architecture jwt authorization distributed-system

【解决方案1】：

一种解决方案是在查询参数中使用 JWT 将请求发送到后端服务。

然后，您可以在后端服务中使用中间件，将其转换为 Authorization 标头，以便查看它的库继续工作。

【讨论】：

当我从服务B接收到用户浏览器时，它仍然无法解决保存JWT的问题。
如果所有服务都在同一个域中，您应该将其存储在 cookie 中或服务 B 的本地存储中。这里同样适用。
但问题是我不希望它们在同一个来源，我希望它们独立扩展。
我想说的是，让服务 B 将 JWT 放在本地存储中，当它想向服务 A 发送请求时，将其从本地存储中提取并添加为查询服务 A 请求的参数。查询参数不受 cookie 或本地存储方式的限制。另外，我说的是“域”，而不是“起源”。如果你扩展，这意味着你已经有一个 http 代理，如果你有，你不需要单独的域，你可以在代理上进行重定向。

【解决方案2】：

所以这就是我选择实施解决方案的方式，但首先，需要澄清一点。

当浏览器尝试访问该站点时，如问题中所述，将被重定向到 /login 路由以验证用户。但是如果用户不存在，那么我会让用户看到该站点，但具有最低权限。因此，如果用户通过身份验证，则 cookie 将包含带有所需数据的 jwt。如果用户是访客，服务 B 仍然会返回一个 cookie，但会表明用户是访客。

我选择的实现方式是：

由于上面的解释，我们总是从服务 B 获取 cookie，这意味着我们总是可以告诉我们的站点将其保存在浏览器的 LocalStorage 中，因此我决定将 JWT 保存在其中。
对于我向服务 A 发出的每个 fetch 请求，我将设置一个名为 Authorization 的标头，它的值将是 Bearer <the jwt token>（在 <the jwt token> 中插入 jwt），如本文所述 MDN 文章关于授权。

关于安全性：

因此，因为无法将 JWT 保存在与服务 A 相关的 cookie 中（服务 B 和 A 来自不同的域），所以我们留下了 LocalStorage 选项。 LocalStorage 不是最安全的方式，默认情况下容易受到 XSS 攻击，但是，正如this 回答中所述，mikejones1477，现代浏览器对 XSS 有很强的防御能力，并且 LocalStorage 不易受到 CSRF 的攻击。因此，从本质上讲，应该特别注意 XSS 攻击，但这是在不同域的服务之间传递令牌的方式。

【讨论】：