SPA 中令牌存储和刷新的选项

Question

我一直在阅读 Aaron Parecki 的基于浏览器的应用程序草案（意思是使用 React 或 Angular 开发的 SPA）使用 OAuth 2 以及 OWASP 安全指南的身份验证最佳实践，这让我感到非常困惑：

1. RFC 草案提到了轮换刷新令牌。现在我将如何在坚持 REST 的无状态约束的同时做到这一点？我是否在 cookie 和刷新令牌中包含一些随机字符串的摘要并检查它们是否相等？
2. 在浏览器中存储刷新令牌的正确方法（或者更确切地说，一些更安全的方法）是什么？我检查了 okta 的 JS auth 库，它localStorage默认使用，这是 OWASP 指南推荐的。它有某种额外的保护吗？我是否应该在其中放入一些额外的摘要并将其放入 cookie 中并进行匹配？
3. OWASP 建议 session ID 应该对客户端完全不透明，但是如果我们使用 JWT，是不是违反了这个原则？这是否意味着我应该始终使用对称密码加密我的 JWT？

一些参考：

• https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-4
• https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md
• https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/JSON_Web_Token_Cheat_Sheet_for_Java.md
• https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md

Answer 1

SPA 的标准选项是使用iframe 以静默方式更新令牌，而根本不使用刷新令牌。

我写的UI 令牌存储可能也很有趣 - 因为该解决方案在很大程度上是安全性和可用性之间的权衡。

最安全的选择是将令牌存储在浏览器内存中 - 但刷新页面意味着用户被重定向到再次登录。因此，将 HTML5 会话存储用于短期访问令牌是很常见的。

My Cloud SPA使用不支持标准的 AWS Cognito（因为它很便宜）。

相反，它向 SPA 发出刷新令牌。我的解决方案使用了一种中间立场，即在 HTML5 会话存储中存储访问令牌，在内存中存储刷新令牌。

此处提供了2 个选项：

• 在支持时使用 iframe
• Cognito 使用刷新令牌

也许这会变得更简单，我想每个人都同意当前基于标准的指南是模棱两可的。

截至 2020 年初，iframe 解决方案和基于内存或会话的存储是最标准的 - 正如使用最广泛的 SPA 安全库的作者撰写的本文所述。