我们有一个简单的场景，但技术（或实施）使事情变得有点复杂 -
我们将 Sitecore 作为客户主要网站的 CMS，对于业务功能，我们拥有 Dynamics 365 门户，并且我们使用 Azure AD B2C 作为两者的身份提供者。
我们有大量定制的 B2C 定制策略以满足特定要求。
我们在 Sitecore 和 Dynamics 365 门户中使用相同的自定义策略，因此请单独登录并完美运行，没有任何问题。
关于 SSO，我们将配置保留为 OOTB，您可以在此处找到它。
只有 1 或 2 个用户旅程与无缝旅程一样完美。在特定的旅程中，我们需要用户在两端都登录才能使其工作（我们可以强制用户去登录页面，但并非所有页面都需要这样做）。
为了了解在 Azure AD B2C 中真实和适当的 SSO 应该如何工作，我不知道或没有经验将此过程与此相关联。所以我在这里寻求指导和帮助。
我在这篇文章中发现了关于 B2C 在登录和提供令牌过程方面如何工作的非常好的信息，但它有点老问题，从那时起事情发生了很大变化，特别是 UI 和一些操作。
这是为那些对我们如何实现这一目标感兴趣的人准备的 -
Sitecore 也提供 OOTB Azure AD B2C 配置，但是 Sitecore 交付方的供应商决定不使用 OOTB 配置方法，因此引起了很多问题。根据我所阅读的有关 Azure AD B2C 的 Sitecore 配置的信息，经过仔细配置，它确实可以与 B2C 顺利配合使用。
解决方法：我们不得不依赖外部触发器（例如 cookie），它会指示并触发用户已在任一方签名，因此双方的登录过程都会启动。
在为自定义策略配置会话管理时使用以下文档。会话行为部分是您定义 SSO 行为的地方。具体来说：
<SingleSignOn Scope="Application" />
如果您希望您的用户在所有应用程序之间获得 SSO，则将此值定义为“租户”。在会话之间创建分离有几个有用的场景 - 例如，一家公司拥有多个不想相互冲突的品牌。或者经验的分离。
遵循要放置在您的保单中的确切格式和位置，否则您将无法获得所需的结果。
另一个重要的概念是了解会话提供者：
SSO 会话管理有两个部分。第一个处理用户直接与 Azure AD B2C 的交互，另一个处理用户与 Facebook 等外部方的交互。Azure AD B2C 不会覆盖或绕过可能由外部方持有的 SSO 会话。而是“记住”通过 Azure AD B2C 到达外部方的路线，避免再次提示用户选择他们的社交或企业身份提供者的需要。最终的 SSO 决定仍由外部方做出。
会话提供程序用于定义在执行策略时维护生成会话的内容（在身份体验框架内）。如果标记不正确，这可能会导致不良结果，例如发送错误的索赔、额外的 MFA 提示、运行时未维护您的部分保单或只是一般错误。