问题标签 [json-web-token]

在需要角色的身份验证机制中使用 JWT 的标准做法是什么？

• 角色是否应该包含在预定义的公共声明名称中？
  • ['iss', 'sub', 'aud', 'exp', 'nbf', 'iat', 'jti]
• ...或者应该使用特定于应用程序的私有声明名称？
• 或者应用程序是否应该避免在 JWT 中放置角色，而只在应用程序中保留所有基于角色的逻辑？

更多详情：

当使用 JSON Web 令牌作为用户身份验证机制时，并且您将身份验证应用于一组路由，当令牌有效时，身份验证对集合中的所有路由都有效。如果令牌无效，则对集合中的所有路由都无效。

如果所有用户都具有相同的访问级别，那就太好了。但是，如果用户具有不同的角色，比如“用户”和“管理员”，并且只有“管理员”可以访问某些路由，那么这就会失败。

我目前正在使用 node-jsonwebtoken ( https://github.com/auth0/node-jsonwebtoken ) 库来生成身份验证令牌。我只是调用 jwt.sign 来生成令牌。

在我的登台和开发服务器上，生成的令牌是 941 个字符，但在我的生产服务器上（CPU 数量是 8 倍，RAM 更大，但没有其他差异），它要大得多（>8KB）。有谁知道这是为什么 - 我现在最好的猜测是它是基于我的 RAM 或多个 CPU 生成的，但这只是一种相关性。

我应该怎么做才能降低令牌的大小？在我的客户端上，我不允许发送标头超过 8KB 的请求。

谢谢

使用数据库会话令牌系统，我可以让用户使用用户名/密码登录，服务器可以生成一个令牌（例如 uuid）并将其存储在数据库中并将该令牌返回给客户端。来自那里的每个请求都将包含令牌，服务器将查找令牌是否有效以及它属于哪个用户。

使用 JWT，由于服务器上保存的密钥和客户端保存并随每个请求发送的签名令牌的组合，因此无需将任何关于会话/令牌的内容保存到数据库中。

这很好，但除了保存数据库检查每个请求（无论如何都会很快，因为它只是检查哈希表），我不清楚使用 JWT 有什么好处。有熟悉这个的能解释一下吗？让我们忽略 cookie，它特别是如上所述的数据库自定义令牌和我试图比较和理解其好处的 JWT。

我正在用 Java 构建一个无状态的 RESTful 服务器后端，它将由 AngularJS 前端使用。因为它应该是无状态的，所以我不创建会话而是生成访问令牌，更准确地说是 JSON Web 令牌，客户端必须在每个请求上呈现。

令牌包含一个“过期”字段，作为绝对过期日期。但是，我希望对用户不活动有一个额外的到期时间。因此，如果用户每 30 分钟活动一次，我会将访问令牌定义为 24 小时有效。

我可以通过在每个请求上向数据库写入一些内容并验证请求之间的时间来实现这一点，但是对于使用应用程序服务器的会话管理时开箱即用的东西来说，这似乎需要做很多工作。

我想使用 angular、nodejs 和 express-jwt 实现带有 json web 令牌的滑动过期概念。我对如何做到这一点有点困惑，并且正在努力寻找刷新令牌的任何示例或与这些技术/框架的会话相关的其他材料。

我想到的几个选择是

• 在初始登录后为每个请求生成一个新令牌
• 跟踪服务器端发出的令牌

但老实说，我不确定，请帮助

我有需要 Azure AD 不记名身份验证的 API。

那么是否可以查询 Azure AD（可能使用 Graph API）来确定调用用户的组信息？此处的最终目标是将基于角色的安全性应用于 API 方法/控制器，如下所示（或类似）。

此外，身份信息如何以及在何处应用于执行线程？

我对基于令牌的授权相当陌生。我试图找出自定义过期/令牌刷新方案中的缺陷。

我在 Express API 中有一个基本的 JWT 身份验证设置；我将 JWT 到期时间设置为 1 小时；但是，JWT 会检查相对于令牌发布时间的令牌过期时间。我希望在每次成功的 api 调用后重置过期时间。如果我的用户正在积极使用该应用程序超过一个小时，我不希望他们必须重新登录以刷新令牌（并且可能会丢失他们正在处理的任何数据。）

另一方面，如果令牌超过一个小时没有响应，我确实希望令牌过期。

我想出了以下方法：

在每个成功的 API 请求期间，发出一个新的 JWT 并将其发送到自定义响应标头中。我的客户端代码负责检查此 JWT 响应标头并将其值用作新的默认授权请求标头。因此，如果超过 1 小时没有来自用户的 API 请求，则令牌将过期并且不会被刷新。然后需要登录。此外，将存储令牌的原始发行日期（登录身份验证的时间戳），以便在 24 小时后强制执行令牌的“硬过期”。

这看起来相当简单且相当安全，但我在 JWT 研究中没有看到任何提及它的内容。有没有更好的方法来实现相同的目标？我是否错过了这种方法的主要安全漏洞？

更新： 在考虑了一段时间后，我意识到这样做的问题是它打开了重放无法被令牌过期阻止的攻击的大门。所以绝对应该有一个“硬到期”检查：硬到期将使令牌在发行日期后的某个时间失效，无论最近的用户活动如何。

我正在使用 expressJwt ( https://github.com/auth0/express-jwt ) 对 angularjs 网站进行用户验证。我有一个有趣的情况，我有一个 URL（/username/somedata），任何人都可以访问这个页面。如果他们没有登录，或者不是这个用户，他们只会得到标记为公开的数据。如果他们已登录并且是正确的用户，他们将获得公共和私人数据。

问题是您只能在以 /api （需要登录）开头的任何路径上从 req.user 访问 JWT（json Web 令牌）......并且由于此页面不需要登录，因此它不会下降在 /api 下。

有什么方法可以允许访问不在 /api 下的路径上的 req.user 吗？另一个想法是在请求数据并使用不同的路径之前检查他们是否已登录......

IE：

未登录始终使用：/username/somedata（始终只公开数据）

已登录：/api/username/somedata（在输出之前检查用户是否是数据的作者，如果作者输出公共和私人......否则也只有公共）

更新：我测试了多条路径，效果很好，但我仍然很好奇你是否可以通过另一种方式访问​​ req.user，所以我现在不打算回答我自己的问题。

我对 Firebase 安全性和一般的 Web 开发有点陌生，但我在我的 Rails 应用程序的服务器端生成 JWT。但是，要将它们传递给 firebase，似乎我必须使用以下 Javascript 代码在视图中传递令牌（存储在数据库中的 users 表中）：

这是您应该如何处理身份验证令牌的方式吗？我认为这可能会破坏这一点，因为用户可以从页面源查看身份验证令牌。

我设置为我的项目 json Web 令牌身份验证。我在“私人”路径下保护了所有请求。使用标签 img 和属性 src 从客户端下载图像的最佳方法是什么？

到目前为止，我唯一的解决方案是在客户端上设置一个带有令牌值的 cookie，而不是私有的来访问公共路径。比在服务器上，我将获取 cookie 值并在标头中设置正确的令牌向我的私有路径发出新请求。

有没有更优雅的方式？