【问题标题】:End user authentication in Google Cloud StorageGoogle Cloud Storage 中的最终用户身份验证
【发布时间】:2022-01-27 18:47:07
【问题描述】:

在过去的几天里,我研究了 Google Cloud Storage Buckets。 我想知道如何在访问数据时对用户进行身份验证,最好不使用后端。

上下文:我有一个具有以下要求的应用程序:经过身份验证的最终用户应该能够将数据上传到(或他们的)存储桶,默认读取权限是用户的范围。在任何时候,桶的所有者都应该允许桶的内容对公众可用(发布桶的内容,只读)。

目前正在浏览器上使用 JWT 对最终用户进行身份验证。

我研究了控制对存储桶的访问的不同方法。

据我了解:

  • IAM 不适合用于 Google 帐户,应在公司内部使用,而不是用于验证最终用户(客户)
  • ACL 似乎不被推荐,它被描述为旨在与 S3 互操作的传统方式
  • 签名 URL 可以“正常”上传,但我更希望有一种实际经过身份验证的上传方式。

我完全不清楚的是:可以使用哪种访问控制方法来验证我的最终用户(尤其是使用 JWT),尤其是读取数据?

这似乎是每个人都应该面对的问题,但我似乎找不到好的信息?附带说明:我知道 Firebase 就是因为这个原因而存在的,我只是想知道如何在 GCP 上解决这个问题。

【问题讨论】:

    标签: firebase authentication google-cloud-platform oauth-2.0 google-cloud-storage


    【解决方案1】:

    除了签名 URL 和后端(我知道这违反了您的要求)之外,没有其他解决方案可以检查身份验证并生成该签名 URL(仅在相关/授权文件上)

    【讨论】:

    • 所以我理解正确配置正确(短 TTL)的签名 URL 是要走的路吗?但是,如果有人要访问此链接怎么办?我应该求助于使用 firebase 并通过它连接我的存储桶吗?
    • 经过身份验证的用户向您的后端执行请求。后端检查身份验证有效性,并回复与用户相关的文件的 SignerURL(s)。您必须在用户和属于他们的文件(或存储桶)之间保持链接。在 firestore 中,它是完美的(您可以在该索引中执行搜索)。
    【解决方案2】:

    当纯粹在 GCP 中实现此功能时,您通常最终会为您的客户端实现自己的身份验证解决方案,然后在您的服务器端代码中实现您自己的授权模型。

    如果您不想自己实现此功能,则可以使用 Firebase 访问云存储。这实现了客户端身份验证和服务器端安全规则来控制访问。

    【讨论】:

    • 感谢您的回复!走 Firebase 路线时,我认为使用“一个桶供多个客户”的方法比“每个客户一个桶”更明智?
    • 两者都可以,因为您可以在初始化 SDK 时指定存储桶。但是,如果您通过 Firebase 安全规则控制访问,则通常无需为每个客户拥有一个存储桶。
    猜你喜欢
    • 2019-09-27
    • 1970-01-01
    • 2011-12-25
    • 1970-01-01
    • 2021-10-15
    • 1970-01-01
    • 2019-12-31
    • 2014-10-11
    • 1970-01-01
    相关资源
    最近更新 更多