security - 验证刷新 token 和发布新的不记名 token 的工作流程是什么？

Question

这不是一个编码问题，而是一个关于正确处理和处理刷新 token 的概念问题。

我有一个单页应用程序，它在登录时发出 jwt token 。 token 工作得很好。现在，我想将过期设置为一个较低的值，并使用刷新 token 来刷新不记名 token 。

问题是，刷新 token 中应该存储哪些声明？在发布新 token 之前应该执行哪些步骤来验证刷新 token ？

例如，现在我的刷新 token 是一个存储过期时间的 jwt，因此客户端知道刷新 token 何时过期，以及用户名声明，以便我知道刷新 token 与哪个用户相关联。

那么当收到刷新 token 时:

检查它是否未过期。

检查它是否未被撤销。

使用刷新 token 中的 UserName 来发布一个新的短期持有者 token 。

这是正确的工作流程吗？我只是想确保我没有错过任何安全检查。

Answer 1

如果您的应用程序是单页应用程序，则不应使用长期存在的刷新 token ，因为您无法安全地存储它们。
OAuth2为不同类型的客户端(which I've described here)定义了许多授权流。刷新 token 仅适用于 secret 客户端(例如安全服务器上的 Web 应用程序)。
您的刷新 token 与访问 token 一样容易被盗，因为两者都是存储在客户端上的不记名 token 。
一些 OAuth 库允许 SPA 或其他非 secret 客户端通过使用 cookie 中的 session token 与授权服务器的 token 端点对话来获取新的访问 token 。只要 cookie 有效，用户就可以获得新的访问 token 。之后，用户将需要重新进行身份验证。当然 cookie 可以标记为安全和仅 http，这使得它们更难被窃取。
如果您从使用访问 token 的同一服务端点发出 JWT token ，您可以让客户端在您散列的 token 请求中包含一个随机数，并将其作为声明包含在 token 中。客户端可以在 Authorization header 中发送 JWT，在自定义 header 中发送 nonce。您的 token 验证将再次散列随机数并将其与 JWT 中的声明进行比较。这样，如果你的代币被盗，没有随机数值(value)就很难使用。当然，在有针对性的攻击中，您的 nonce 也可能被盗。