angular - SPA 中 token 存储和刷新的选项

Question

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

RFC 草案提到了轮换刷新 token 。现在我将如何在坚持 REST 的无状态约束的同时做到这一点？我是否在 cookie 和刷新 token 中包含一些随机字符串的摘要并检查它们是否相等？

在浏览器中存储刷新 token 的正确方法(或者更确切地说，一些更安全的方法)是什么？我检查了 okta 的 JS auth 库，它默认使用 localStorage，这是 OWASP 指南推荐的。它有某种额外的保护吗？我是否应该在其中放入一些额外的摘要并将其放入 cookie 中并进行匹配？

OWASP 建议 session IDs 应该对客户端完全不透明，但是如果我们使用 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 的标准选项是使用 iframes to silently renew tokens 而根本不使用刷新 token 。
我写的关于 UI token storage 的文章可能也很有趣——因为解决方案在很大程度上是安全性和可用性之间的权衡。
最安全的选择是将 token 存储在浏览器内存中 - 但刷新页面意味着用户被重定向到再次登录。因此，将 HTML5 session 存储用于短期访问 token 是很常见的。
我的 Cloud SPA 使用不支持标准的 AWS Cognito(因为它很便宜)。
相反，它向 SPA 发出刷新 token 。我的解决方案使用了一种中间立场，即在 HTML5 session 存储中存储访问 token ，在内存中存储刷新 token 。
有 2 个选项可用 here :

在支持时使用 iframe

Cognito 使用刷新 token

也许这会变得更简单，我想每个人都同意当前基于标准的指南是模棱两可的。
到 2020 年初，iframe 解决方案和基于内存或 session 的存储是最标准的 - 正如使用最广泛的 SPA 安全库的作者在 this article 中所做的那样。