JSON Web Token Auth Service - 检查单独服务器上的状态以保护路由。节点JS

Posted 2023-03-10

【中文标题】JSON Web Token Auth Service - 检查单独服务器上的状态以保护路由。节点JS

【英文标题】：JSON Web Token Auth Service - checking status on separate server to protect routes. NodeJS

【发布时间】：2015-04-06 22:38:04

【问题描述】：

对于我目前正在进行的一个项目，我正在使用 Node/Express/Mongo 开发一个 API，并使用相同的工具单独开发一个网站。理想情况下，我希望将它们托管在单独的服务器上，以便可以根据需要进行扩展。

对于身份验证，我使用的是我设置的jsonwebtoken，我对它的工作方式总体上很满意。

但是…

在网站上，我希望能够限制（使用 Express）某些路由到经过身份验证的用户，但我正在努力寻找实现此功能的最佳方法。令牌当前保存在 LocalStorage 中。

我想我可以通过一个 get 参数将令牌传递给我想要保护的任何路由，然后在网站服务器上检查这个令牌（显然这意味着在这里也包括 jwt 机密，但我看不出有什么大问题那个）。

所以我的问题是

这行得通吗？ 这是否意味着（不是双关语）我最终会得到丑陋的 URL 我是否最好将两者托管在同一台服务器上，然后将生成的令牌保存在服务器端？ 有更好的解决方案吗？

我应该说我不想使用 Angular - 我知道这会解决我的一些问题，但它会为我创造更多！

【参考方案1】：

首先，我会直接回答你的问题：

这行得通吗？是的，它会起作用。但也有许多缺点（更多讨论见下文）。 不一定。我真的不认为丑陋的网址包含查询字符串。但无论如何，所有身份验证信息（令牌等）都应包含在 HTTP 授权标头本身中，而不应包含在 URL（或查询字符串）中。 在您的情况下这并不重要，因为只要您的 JWT 生成代码与您的网络服务器具有相同的密钥，您就可以验证令牌的真实性。 是的！请阅读下文。

所以，既然我们已经解决了这些问题，那么让我解释一下为什么您所采用的方法不是目前最好的主意（不过，您离一个好的解决方案并不太远！ ):

首先，由于 XSS（跨站点脚本攻击），目前将任何身份验证令牌存储在本地存储中是一个坏主意。本地存储不提供任何形式的域限制，因此您的用户很容易被诱骗放弃他们的令牌。

这是一篇很好的文章，它以易于理解的形式详细解释了为什么这是一个坏主意：http://michael-coates.blogspot.com/2010/07/html5-local-storage-and-xss.html

您应该做的是：将您的 JWT 存储在经过签名和加密的客户端 cookie 中。在 Node 世界中，有一个出色的 Mozilla 会话库可以自动为您处理这个问题：https://github.com/mozilla/node-client-sessions

接下来，您永远不想通过查询字符串传递身份验证令牌 (JWT)。有几个原因：

大多数 Web 服务器都会记录所有 URL 请求（包括查询字符串），这意味着如果有人掌握了这些日志，他们就可以作为您的用户进行身份验证。 用户在查询字符串中看到此信息，而且看起来很难看。

相反，您应该使用 HTTP 授权标头（它是一个标准）来向服务器提供您的凭据。这有很多好处：

Web 服务器通常不会记录此信息（没有杂乱的审计跟踪）。 很多标准库都可以解析这些信息。 这些信息不会被随意浏览网站的最终用户看到，也不会影响您的 URL 模式。

假设您使用的是 OAuth 2 不记名令牌，您可以按如下方式制作 HTTP 授权标头（假设您将其表示为 JSON blob）：

"Authorization": "Bearer myaccesstokenhere"

现在，最后，如果您正在寻找上述实践的良好实现，我实际上在 Node 中编写并维护了一个更流行的身份验证库：stormpath-express。

它以干净、经过良好审核的方式处理上述所有用例，还提供了一些方便的中间件来自动处理身份验证。

这里是中间件实现的链接（您可能会发现这些概念很有用）：https://github.com/stormpath/stormpath-express/blob/master/lib/authentication.js

apiAuthenticationRequired 中间件本身非常好，因为如果用户未通过 API 身份验证（HTTP 基本身份验证或带有承载令牌 + JWT 的 OAuth2）正确进行身份验证，它将拒绝用户的请求。

希望这会有所帮助！

【讨论】：

首先，感谢您花时间发布如此详细的回复。我确实看过 Stormpath，虽然当时我是从 php 的角度（所以 cURL）接近它......而且我不是 cURL 的忠实粉丝。我很感兴趣你说在本地存储中存储 jwt 是一个坏主意 - I had the impression 这可以吗？

不，那篇文章实际上解释了相反的情况——最好使用 cookie 来存储令牌——而不是本地存储。这种方式有几种已知的攻击媒介。这是一个常见的误解。另外：Stormpath 的东西直接通过 express.js（或节点）工作，所以如果你有兴趣，你可以将它用于任何一个。它可以完成所有这些事情以及更多（并且是免费的）。

存储在 cookie 中不是问题，但我仍然有点困惑为什么它是必要的，特别是为什么你说它们也应该被加密。无论如何，我并没有怀疑你，我只是想弄清楚这一切。我一直在关注 Scotch.io 团队制作的一本书，其中令牌以纯文本形式存储在客户端的本地存储中。据我了解，任何恶意的人可以对“被盗”令牌做的所有事情都是在令牌有效期内伪装成特定用户。虽然这显然不理想，但是否存在我不知道的更严重的风险？

这是主要风险：您的代币会暴露给第三方。使用 LocalStorage，您始终可以通过 javascript 访问存储在其中的内容。因此，如果有人能够在您或他们的网站上运行 javascript，并且能够访问该本地存储令牌，那么该 javascript 代码就可以执行您的用户可以执行的任何操作：更改他们的密码、向他们收费、更改帐户电子邮件等等。 .这通常通过 XSS 发生。我在答案中链接到的那篇博客文章展示了如何发生这种情况的一个很好的例子=）但是是的，这是主要风险。 cookie 不会发生这种情况，因为您可以设置 httpOnly 模式

这行得通吗……用户使用 SITE 的表单登录。提交给 SITE 服务器的表单，SITE 服务器验证凭据，生成令牌并将此客户端存储为签名和加密的 httponly cookie。对于我想通过 AJAX 直接提交给 API 的 SITE 上的表单等，通过服务器端将令牌值作为纯文本传递给我的视图是否安全，然后可以将其存储为表单上的（隐藏）输入。然后我可以通过javascript访问它吗？我是否更正了在 SITE 上生成的令牌仍然对 API 有效，因为我使用的是相同的“秘密”。