Google Firebase:如何“解决”客户的 OIDC 发现文档中无效的“发行者”值?

问题描述 投票:0回答:1

我们的软件使用 Google Firebase 为已实施 OIDC (OpenID Connect) 提供商的企业客户提供“单点登录”体验。

我们与一位客户有问题。

他们的 OIDC 发现文档位于:
https://abc-vis-cert-cloud3.ourclient.com/.well-known/openid-configuration.

在此发现文件中,我们预计发行人声明如下:

"issuer": "https://abc-vis-cert-cloud3.ourclient.com"

但他们的发行人声称是:

"issuer": "urn:VISCertC3:abc"

当我们尝试连接到他们的 OIDC 提供商时,Google Firebase(非常正确)返回错误:
“INVALID_IDP_RESPONSE:

issuer
OIDC 发现文档中的声明与请求中指定的颁发者不匹配。”

我们已要求客户修复其发现文档中的

issuer
值,但他们表示无法......他们有数百个依赖于当前配置的现有集成,并且所有这些都正在运行就好了。

我的问题:
我们(或他们)可以实施解决方法来实现这项工作吗?

即有 Google Firebase 设置吗? 或者我们可以实现某种代理?或者通过某种方式让他们向我们(以及我们自己)显示不同的发现文档?

这里有一个关于 Azure B2C 的类似问题,Azure B2C 中的答案看起来就像设置

skipIssuerCheck: true
strictDiscoveryDocumentValidation: false
一样简单。 另一个类似的问题这里

firebase google-cloud-platform openid-connect
1个回答
0
投票

完全跳过发行人检查应被视为安全问题,因为这样就无法保证代币是否由正确的一方发行。它会影响其他客户端,这些客户端的令牌验证不太严格,并且可能会向有问题的客户端传递由任何方颁发的令牌。

如果绝对不可能做到正确,我宁愿建议一个可以处理白名单异常的解决方案。

大多数后端身份验证库都可以挂钩令牌验证过程并引入自定义验证逻辑。您的逻辑可能是“如果是客户端 X 的令牌,请检查颁发者字段是否与 X 的白名单异常/覆盖匹配”。将您的白名单存储为后端配置,然后就可以开始了。

© www.soinside.com 2019 - 2024. All rights reserved.