firebase - Rest API 身份验证策略以及如何在客户端应用程序上存储令牌

Question

我正在为本地（移动应用程序）和基于浏览器的应用程序（反应等）设置一个 Rest API。我正在使用express.js和passport.js使用 LocalStrategy 和 JwtStrategy。

我已经研究过这个主题，并且有很多不同的对话或教程。大多数教程只是创建一个访问令牌，从不讨论如何刷新它。很多其他人只是使用像Oktaor之类的提供者Auth0。我不想重新发明轮子，但我认为我应该能够创建一个简单的身份验证机制。

我现在的流程是这样的；
* 在登录时创建访问和刷新令牌。将它们作为响应返回。
* 客户存储它。在反应中，我localStorage用来存储令牌。
*Authorization: Bearer <access_token>向请求添加标头。
* 当access_token过期时，使用当前的refresh_token.

我将刷新令牌存储到服务器上的数据库。因此，用户可以跟踪他们当前的所有会话，或者管理员可以在出现安全问题时调用它们。

经过大量研究，我发现在使用localStorage在浏览器上存储令牌或将令牌作为httpOnlycookie 返回方面存在很大分歧。

当我检查一些流行的网站时，我发现，像 Facebook、Github、Youtube、9gag 这样的网站使用 cookie 来让你保持登录状态。它们不发送Authorization: Bearer <access_token>标题。localStorage 中主要有关于 UI 状态的信息。但是，当您删除SIDcookie 时，它​​们都会将您注销。他们是否使用基于会话的身份验证？

当您登录到 TMDb（电影数据库）时，它会设置 2 个名为access_token（这只是一个 JWT）和session. 我猜这是一种服务器返回访问令牌和某种“持久性”信息（会话）作为 cookie 的实现。

Firebase（我最喜欢这个主题之一）只是将访问和刷新令牌存储到localStorage. 它实际上使用indexedDB，但我读过它在不能使用 indexedDB 时回退到 localStorage。

但 OWASP 建议“基于浏览器的应用程序永远不应检索刷新令牌”。我猜这意味着当访问令牌过期时，应该检查授权服务器以查看是否仍有会话正在进行，然后检索新的访问令牌。（无声更新）

我见过的唯一例外是 Azure 门户。它在标头中发送不记名令牌Authorization。它将刷新令牌存储在localStorage. 许多“安全敏感”公司使用它来部署/维护他们的应用程序或数据库等。

因此，Firebase 和 Azure 门户是访问/刷新保存到浏览器 localStorage 的令牌的示例。httpOnlyTMDb 是在cookie中获取令牌的示例。Facebook、Youtube 等正在使用某种我无法理解的身份验证机制。我认为是 Cookie 和会话？

将访问和刷新令牌返回到本机和基于浏览器的应用程序具有非常简单的逻辑和实现。将它们存储在 localStorage 中总是觉得这是一个很大的风险。但我不想为 Web 应用程序设置 cookie 并为移动应用程序返回 JSON 响应。我觉得他们应该是一样的。在看到像 Firebase 和 Azure Portal 这样的例子之后，我觉得它并没有那么大的错误。

但是，即使有很多关于这方面的分歧和文章，它真的安全吗？即使 Firebase 和 Azure Portal 是这种策略的好例子，为什么 Facebook、9gag、Youtube 等网站主要使用 cookie（和我认为的会话）进行身份验证？

我知道这是一个很大的话题。我知道可能有很多不同的方法。但我认为我需要某种基石思想来实现简单应用程序的身份验证。

标签： firebasefirebase-authenticationjwtpassport.jsrefresh-token