我正在为本机（移动应用程序）和基于浏览器的应用程序（反应等）设置Rest API。我正在将express.js和passport.js与LocalStrategy和JwtStrategy一起使用。
我已经研究了这个主题，并且有很多不同的对话或教程。大多数教程只创建访问令牌，而从不谈论如何刷新它。许多其他提供商仅使用Okta或Auth0之类的提供程序。我不想重新发明轮子，但我认为我应该能够创建一个简单的身份验证机制。
我当前的流程是这样的
*在登录时创建访问和刷新令牌。返回它们作为响应。
*客户端存储它。在反应中，我使用localStorage来存储令牌。
*将Authorization: Bearer <access_token>标头添加到请求中。
* access_token到期后，使用当前的refresh_token获取新令牌。
我正在将刷新令牌存储到服务器上的DB。因此，当存在安全问题时，用户可以跟踪其所有当前会话，或者管理员可以调用它们。
经过大量研究，我发现对于使用localStorage在浏览器中存储令牌，还是将令牌作为httpOnly Cookie进行返回，存在很大的分歧。
当我检查一些受欢迎的网站时，发现诸如Facebook，Github，Youtube，9gag之类的网站使用cookie来保持您的登录状态。它们没有发送Authorization: Bearer <access_token>标头。在localStorage中主要有关于UI状态的信息。但是，当您删除SID Cookie时，所有这些都将您注销。他们在使用基于会话的身份验证吗？
登录到TMDb（电影数据库）时，它将设置2个名为access_token（仅是JWT）和session的cookie。我想这是服务器将访问令牌和某种“持久性”信息（会话）作为cookie返回的一种实现。
Firebase（我对此主题的最爱之一）仅将访问令牌和刷新令牌存储到localStorage。它实际上使用了indexedDB，但是我读到它不能使用indexedDB时会退回到localStorage。
但是OWASP建议“基于浏览器的应用程序永远不要检索刷新令牌”。我想这意味着当访问令牌过期时，应该检查授权服务器以查看是否还有会话正在进行，然后检索新的访问令牌。 （静音续订）
我所见的唯一例外是Azure门户。它在Authorization头中发送承载令牌。它将刷新令牌存储在localStorage中。许多“安全敏感”的公司都使用它来部署/维护其应用程序或数据库等。
因此，Firebase和Azure门户是访问/刷新保存在浏览器上localStorage的令牌的示例。 TMDb是在httpOnly Cookie中获取令牌的示例。 Facebook，Youtube等正在使用某种我无法理解的身份验证机制。我认为是Cookie和会话？
将访问令牌和刷新令牌返回给本机和基于浏览器的应用程序都具有非常简单的逻辑和实现。将它们存储在localStorage中总是觉得这是一个很大的风险。但是我不想为Web应用程序设置cookie并为移动应用程序返回JSON响应。我觉得他们应该一样。在看到了诸如Firebase和Azure Portal之类的示例之后，我觉得它并没有那么大的错。
但是，即使对此存在很多分歧和文章，它真的安全吗？即使Firebase和Azure Portal是该策略的很好示例，为什么Facebook，9gag，Youtube之类的网站仍主要使用Cookie（我认为是会话）进行身份验证？
我知道这是一个大话题。我知道可能有很多不同的方法。但是我认为我需要某种基础的想法来为简单的应用程序实现身份验证。