时间戳

首页 > 解决方案 > 如何在 Firebase 后端存储访问令牌？

firebase - 如何在 Firebase 后端存储访问令牌？

问题描述

我的 React 应用程序使用 Firebase 身份验证和实时数据库。我现在需要使用 OAuth 2.0 访问 3rd 方服务。为了安全地执行此操作，我使用带有 Firebase 功能的 OAuth 2.0 授权代码流作为我的后端：

  1. React 应用程序从第 3 方获取授权码。
  2. 授权代码被传递给 Firebase 函数以获取访问令牌。

但这就是我卡住的地方。如何将访问令牌保存在后端，以便 React 应用程序可以访问 3rd 方资源？我不想将访问令牌存储在 React 应用程序中，因为这不安全。

  1. 如何使用 Firebase Functions 在后端维护会话？
  2. 会话应该绑定到 React 应用实例还是 Firebase 用户？前一种方法需要进行会话清理。后者的优点是可以使用刷新令牌获得新的访问令牌。这样用户就不必再次登录到第 3 方了！

标签： firebaseoauth-2.0google-cloud-functions

解决方案

总体因素

通常，这些是您的 SPA 安全选择影响的领域，并且存在权衡：

  • 应用类型
  • 强大的安全性
  • 托管和全球性能
  • 技术简单

在所有情况下

您的应用应该：

  • 分别为每个用户维护一个令牌
  • 您将希望在登录后从令牌中识别用户

选项 1：前端型号/无烹饪设备

这涉及在浏览器中使用令牌并具有以下好处：

  • 后端只是静态内容
  • Web 资源可以通过 CDN 部署在用户附近
  • 您可以使用OIDC 客户端库来管理安全性

这被广泛使用，并且只有在您的应用程序存在跨站点脚本漏洞时才能被利用。我的一些资源：

选项 2：后端模型/授权 Cookie

这涉及通过后端代理并在身份验证 cookie 中携带令牌。如果开发在线银行应用程序，我会使用此模型，但对于中等安全性应用程序，它会增加很多开销。您可能需要编写更多安全代码，并且最终可能会得到一个比选项 1 更不安全的解决方案：

  • 需要运行代码的代理后端
  • 后端代码可能需要集群化和全局分布，以实现良好的性能
  • 您需要保护 auth cookie 并应对跨站请求伪造风险

出于兴趣，受人尊敬的mod_auth_openidc库可能对这种类型的解决方案有所帮助。

两全其美

如果在浏览器中使用令牌被认为是不可接受的，我将尽可能遵循选项 1。然后将选项 2 实施为附加步骤：

  • 将 Web 静态内容单独部署到执行后端令牌管理的代码
  • 继续使用 OIDC 客户端库，让授权码交换调用你的后端
  • 与选项 1 的唯一区别是令牌对浏览器代码不可用

推荐阅读