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