设置
我们正在构建一个 PWA(渐进式网络应用程序)。主要组件是应用程序 shell (SPA) 和 API。 REST API 将提供应用程序所需的数据，而 SPA 将处理其余的 ( as per Google recommendation )。
问题
最终用户的身份验证似乎有问题，因为需要考虑 Web 浏览器。我们希望用户登录通过关闭浏览器来保持。
我们已经对可能的实现方式进行了研究，但是我们希望确保我们不会走错方向。
我们考虑过的解决方案
基于 session 的身份验证 - 用户将用户名和密码发送到/accounts/auth 并接收带有 session ID 的仅 HTTP cookie。 session 需要存储在数据库或 Redis 中。此选项的问题在于 cookie 是由浏览器自动发送的，因此我们需要适当的 CSRF 保护。使用 同步器 token 模式 每次发出状态更改请求时都会生成一个新 token ，例如邮政。这意味着应用程序需要为每个请求提供一个 CSRF token ，以便 PWA 可以通过 AJAX 发送它。我们确定这并不理想，因为用户可以发送 快速连续发布多个帖子请求 使其中一些失败并导致糟糕的用户体验。
我们也可以在没有 CSRF 的情况下使用这种方法，方法是将 CORS 策略限制在同一域并添加一个从技术上讲应该停止所有 CSRF 的 header 要求，但是我们不确定它的安全性。
基于 JWT token 的身份验证 - 用户将用户名和密码发送到/accounts/auth 并发出新的 JWT token 。然后需要将 JWT 存储在 中本地存储或 cookies .使用localstorage意味着JWT是 XSS 易受攻击 如果 token 被盗，攻击者可以完全冒充用户。使用 cookie 我们仍然会有 CSRF 问题 解决。我们考虑了 双重提交 cookie 方法，但 CSRF 只会在每次重新发布 JWT 时刷新，这会为攻击者创建一个窗口来找出 CSRF 是什么。目前尚不清楚哪种方法最好使用。
基于 session 的身份验证 + JWT token 身份验证 - 用户将用户名和密码发送到/accounts/auth，创建 session ，在浏览器中设置仅 HTTP cookie 并将 JWT token 发送回用户。 PWA 可以使用 JWT 对请求进行身份验证，并且每当 JWT 到期时，应用程序都会再次调用/accounts/auth 以获取新的请求。/accounts/auth 端点仍然需要受 CSRF 保护，但是它对可用性的影响将被最小化。
似乎有大量文章声称本地存储不安全，不应使用，为什么像亚马逊这样的知名组织仍然推荐它？ https://github.com/aws/amazon-cognito-auth-js - 此 SDK 使用 本地存储来存储 token 。
最佳答案
每次客户端发出请求时，您都不需要生成新的 CSRF token 。使用像 token = hash(id + secret + current_day) 这样的方案要容易得多。 .您只需要每天更新一次，甚至可以采用混合方案(如果 token 今天无效，但前一天还可以，则服务器接受该操作并在预定义的 header 中返回新 token 供客户端更新) .您也可以使用 cookie 作为 id，使 token 完全无状态且更容易检查，无需将它们存储在数据库中。
关于authentication - PWA 的 API 身份验证，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/60001390/