安全管理用户会话的最佳方式

这是关于会话管理的两部分系列文章的第2部分。如果读者理解JWT（JSON Web令牌）和用户会话的一般概念，那么可以在不阅读第1部分的情况下阅读第2部分。

第1部分：会话管理简介，最常用会话流分析和最佳实践

第2部分：分析安全且易于集成的新开源会话流

第1部分提供了会话管理的教育指南（如何在活动会话期间处理，存储和更改身份验证令牌），并讨论了几种常用的会话流程。但是，我们认为第1部分中提到的流程在大多数用例的安全性方面都是次优的。我们遇到了IETF（互联网工程任务组）在RFC 6819中概念化的流程。我们已经采用了建议的流程，并根据其他人的要求构建了流程，为更广泛的社区开放了我们的代码。

在这篇文章中，我们将探索和分析会话流程，讨论一些实现细节，并为您提供可自定义的库。该库已准备就绪，可在一天内与您的系统集成（目前可用于NodeJS和MySQL）。

建议的流程

使用短期访问令牌旋转刷新令牌

建议的Auth流程 – 单击缩放

• 访问令牌是短暂的，刷新令牌是长期存在的。
• 获得新的刷新令牌时，旧的刷新和访问令牌在后端无效并从前端删除。正确地做到这一点并不简单。请参阅后面讨论的“实施说明”。
• 如果用户自愿注销，则从前端撤销访问和刷新令牌并清除。

损伤分析
关键的身份验证令牌永远暴露在两个攻击面，即前端和后端，偶尔暴露在传输之外。

被盗的身份证令的影响：
访问令牌被盗：攻击者将在短时间内进行未经授权的访问（直到令牌到期）

刷新令牌被盗：盗窃检测将使被盗刷新令牌失效，将损坏限制在很短的时间内

检测盗窃：
访问令牌被盗：此盗窃只能通过使用启发式算法或用户通知服务提供商/开发者来检测。

刷新令牌被盗：只要攻击者和受害者在攻击后至少使用刷新令牌，就可以检测到盗窃。这通过以下示例说明。

• 攻击者已设法获取受害者的刷新令牌–RT0。在访问令牌（AT0）到期时，受害者和攻击者都需要使用RT0来获取一组新的令牌。
• 如果攻击者首先使用RT0，那么他们将收到一个新的RT1和AT1，使用它时将使RT0无效。当受害者使用无效的RT0时，服务器将收到一个明确的迹象，表明由于客户端应该使用RT1而发生了盗窃。如果受害者首先使用RT0，则类似的参数有效。
• 如果受害者和攻击者同时使用RT0，则会得到（RT1，AT1），另一个（RT2，AT2）。其中任何一个使用新访问令牌的下一个请求将使RT1或RT2无效，从而导致受害者或攻击者最终（1）注销。再次，这里的后端将清楚地表明盗窃。

一旦检测到：
访问令牌不需要被撤销，因为它们是短暂的。但是，如果需要，可以通过从数据库中删除不透明访问令牌来撤销它们。

通过从数据库中删除刷新令牌，可以轻松撤消该令牌。

这总结了对概念流程的讨论。下面是一些额外的指示，要记住想要自己实现此流程的读者。或者，我们在Github上提供了此流程的开源实现。

实施说明

1. 后端在生成新对时会使先前的令牌无效。在前端没有收到新令牌（无论出于何种原因）的情况下，它将继续使用先前失效的令牌 – 导致用户被注销。为了防止这种情况，只有当前端使用新令牌时，后端才会使之前的令牌无效 – 确认其成功收到。
2. 每次使用有效的RT时，系统都会生成一个新的不同刷新令牌（RT）。为了防止误报（盗窃的迹象）和用户注销，必须考虑前端可能发生的竞争条件（2）。
3. 如果刷新令牌被撤销，那么理想情况下也应该撤销其访问令牌。
4. 检测刷新令牌被盗不需要数据库显式存储无效令牌。这可以通过使用父子层次结构构建刷新令牌来实现（请参阅Github实现）。
5. 具有JWT访问令牌的实现在空间和时间复杂度方面可以像第1部分中的会话流5那样可扩展。我们只需要在数据库中为每个设备的每个登录用户存储一个刷新令牌。

这就是我们在会话管理方面的大部分问题。下面是一个GitHub存储库，其中包含处理所有实现问题的源代码。它可根据您的要求进行高度自定义，并可快速集成到您的系统中。它在防止和检测令牌盗窃方面也非常安全。我们很想知道您的想法 – 请发表评论或发送电子邮件给我们。

SuperToken图书馆

只要股票活 – 我们承诺支持它（修复错误，解决问题，添加功能和更新文档）并做出响应（通过SO，电子邮件等）。

为了向我们的早期读者展示一些额外的爱，我们提供以下专门的支持：

• 对您当前的会话管理系统进行免费咨询，包括识别漏洞并建议针对您的特定用例进行改进。
• 免费支持SuperToken库。如果您在实施，错误和自定义方面存在任何问题 – 我们将按需提供。

专用支持只能在2019年7月10日之前免费使用

如果您将其他人推荐到图书馆（任何贡献或使用图书馆的人），我们将在7月以后为您和该人提供额外一个月的免费专用支持。人越多，支持越多（最多6个月）。请参阅Git自述文件以查看有关此内容的更多详细信息。

最后的结论和建议

构建生产就绪会话管理解决方案非常重要。它需要深入的知识，并且在时间和金钱方面都很昂贵。许多开发人员没有优先考虑会话管理 – 导致生产中的次优，不安全系统。

我们已经讨论了这两个帖子中的各种会话流程。根据要求，一个流程可能比其他流程更适合。一般而言，我们的建议如下：

对于处理非常敏感数据的服务（例如：股票交易平台或类似Ashley Madison），安全性可能优先于用户体验。理想的流程将是会话流程3和来自第1部分的会话流程4的组合。具体而言，使用短期访问令牌，其活动使用将在一段有限的时间内延长到期时间。但是，这将要求用户在令牌过期时重新登录 – 这可能经常发生。

对于所有其他服务，上述流程可能是合适的。在此范围内，建议使用JWT访问令牌（以便更容易扩展）。但是，如果访问令牌立即可以撤销是很重要的，那么请使用不透明访问令牌。此外，通过使用双因素身份验证或无密码登录方法可以提高安全性。后者的好处是不要求用户记住另一个密码。

就是这样请通过评测或发送电子邮件告诉我们您的想法。我们希望这很有用。

脚注

（1）如果使用不透明令牌，则立即注销，否则它们将在新JWT的到期时间之后注销。

（2）这是竞争条件问题：假设用户已在浏览器中的Tab1和Tab2中打开了您的应用。这两个选项卡共享同一组cookie。下图演示了竞争条件如何导致用户注销。