ADB2C 用户流和 IEF 策略不能互操作？答案

【问题标题】：ADB2C User Flow and IEF policies not interoperable?ADB2C 用户流和 IEF 策略不能互操作？
【发布时间】：2020-09-08 06:23:39
【问题描述】：

我有一个 .NET WebApi 应用程序项目，它一直在使用内置的用户流策略。这些政策正在被 IEF 的新政策所取代。

我发现，如果我从 IEF 策略生成令牌，但尝试在默认设置为使用 UserFlow 策略的 WebAPI 上使用它，则会因为签名不匹配而失败。

WebApi 应用设置示例

"AzureAdB2C": {
    "Instance": "https://XXXXX.b2clogin.com/tfp/",
    "ClientId": "XXXXX",
    "Domain": "XXX.onmicrosoft.com",
    "SignUpSignInPolicyId": "B2C_1_signinsignup" //UserFlow policy
    "SignUpSignInPolicyId": "B2C_1A_CustomSigninAndSignUp" //IEF policy
  },

由于 UserFlow 和 IEF 策略在同一个租户上，我原以为它们可以互换/互操作？如果我将 WebApi 设置为使用其中一种 IEF 策略，它就可以工作。

是否有办法让 UserFlow 和 IEF 策略协同工作？

【问题讨论】：

"将WebApi设置为使用IEF策略之一" 能不能表述的更详细一点？这一步是怎么做的？
您是如何从 IEF 策略中生成代币的？能否提供代码？
基本上如果我做一个文件>新建 WebAPI 项目并选择个人帐户，您可以输入租户名称、客户端 ID 和唯一的“SignUpSignInPolicyId”策略。例如，如果您在此处使用用户流策略，但传递给它的令牌是从 IEF 策略（同一租户）生成的，则会收到签名失败不匹配错误。我使用入门指南docs.microsoft.com/en-us/azure/active-directory-b2c/… 生成了 IEF 令牌

标签： azure-active-directory asp.net-core-webapi azure-ad-b2c

【解决方案1】：

@Raj，

不同的策略有自己的签名，不能互相使用，除非你在 .net 中禁用签名验证。

如果您查看每个策略的 OpenID 元数据，您会在 keys 元素中注意到每个都有不同的签名并且不会验证其他策略。

https://flirb2cdev.b2clogin.com/flirb2cdev.onmicrosoft.com//v2.0/.well-known/openid-configuration

【讨论】：

我查看了这些 OpenID 文档以了解我的用户流和 IEF 策略，但没有一个包含签名？（他们都提到了 id_token_signing_alg_values_supported = RS256）。
对于我的 webapp 集成，我使用了 github.com/Azure-Samples/active-directory-b2c-dotnetcore-webapp，它已被归档并替换为更新的 UI 集成库。但是，这似乎在没有任何禁用签名的情况下工作正常，所以我在这里有点迷失。
在 Azure Active Directory B2C 中，自定义策略主要用于解决复杂场景。对于大多数场景，建议使用内置用户流。
该评论在这种情况下没有真正的帮助:)

【解决方案2】：

据我了解，当您创建自定义策略 (IEF) 时，设置的一部分要求您创建/添加签名和加密密钥：https://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-get-started?tabs=applications#add-signing-and-encryption-keys

因此，如果您创建了一堆自定义策略，则可以导入相同的签名/加密密钥，以使所有自定义策略都使用相同的令牌。

理论上，如果您可以下载内置策略使用的签名/加密密钥（用户流程），那么您可以将它们导入自定义策略，理论上它们应该匹配和验证。但是，由于用户流（内置）策略实际上是从 microsoft 的租户继承并使用 microsoft 公钥/私钥，我认为没有办法提取这些。这意味着，可能无法同时让 ief 和 userflow 策略验证相同的密钥签名。如果您需要这两种策略，唯一剩下的解决方案是根据 Christopher 的建议忽略验证，但不强烈建议这样做.. 因为验证是有原因的.. 所以这将是一个安全风险。

【讨论】：

如果是这种情况，这确实需要在 Microsoft 文档中进行澄清。我认为很多人会从用户流开始并迁移到 IEF，因此了解其中的陷阱会很好。