Question

Azure AD B2C中的自定义策略一直存在问题。当我们尝试使用隐式授权从JavaScript前端进行令牌的静默更新时，会发生此问题。看来，当B2C收到来自MSAL.js创建的隐藏iframe的请求时，它将用户重定向到第三方提供商的授权端点。但是，第三方提供商可以阻止该页面的框架。有时，X-Frame-Options：Deny发生在B2C本身的oauthresp端点上。

据我所知，以标准方式配置了外部提供程序的会话管理。看起来像这样：

<TechnicalProfile Id="SM-ExternalLogin">
  <DisplayName>Session Mananagement Provider</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.ExternalLoginSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="AlwaysFetchClaimsFromProvider">true</Item>
  </Metadata>
  <PersistedClaims>
    <PersistedClaim ClaimTypeReferenceId="AlternativeSecurityId" />
  </PersistedClaims>
</TechnicalProfile>

它使用ExternalLoginSSOSessionProvider，根据{{3}}的含义是：

用于隐藏“选择身份提供者”屏幕

嗯，我们实际上没有选择IDP屏幕。我们有一个电子邮件条目和自定义家庭领域发现。

我将尝试两种方法来解决该问题：

将AlwaysFetchClaimsFromProvider设置为false
切换为使用DefaultSSOSessionProvider

但是，这样做似乎违反了建议，如docs所说：

Azure AD B2C不会覆盖或绕过外部参与者可能持有的SSO会话。而是“记住”通过Azure AD B2C到达外部方的路线，从而避免了提示用户选择其社交或企业身份提供者的需求。 SSO的最终决定权仍在外部一方。

我当然可以看到B2C不应覆盖第三方的SSO会话的一些原因。如果用户在第3方IdP中被禁用，则可以轻松注销，也可以更快地禁用该用户。

如果不是针对隐式授予的问题，这将不是一个问题。我将尝试这两个选项，并在此处用我的发现进行更新。如果您认为这都是一个糟糕的主意，请提供评论/答案，并说明它们是一个糟糕的主意的原因。这些文档在这方面没有帮助。

更新：将SSO提供程序更改为默认提供程序，现在它似乎可以重定向回客户端，而无需任何对第三方IdP的请求：

<TechnicalProfile Id="SM-ExternalLogin">
  <DisplayName>Session Mananagement Provider</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <PersistedClaims>
    <PersistedClaim ClaimTypeReferenceId="AlternativeSecurityId" />
    <PersistedClaim ClaimTypeReferenceId="objectId" />
    <PersistedClaim ClaimTypeReferenceId="signInName" />
    <PersistedClaim ClaimTypeReferenceId="authenticationSource" />
    <PersistedClaim ClaimTypeReferenceId="identityProvider" />
    <PersistedClaim ClaimTypeReferenceId="newUser" />
    <PersistedClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" />
    <PersistedClaim ClaimTypeReferenceId="email" />
  </PersistedClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
  </OutputClaims>
</TechnicalProfile>

基本上，这是我们本地帐户所拥有的，除了它还包括备用安全ID。查看跟踪，看来现在它从AAD获取具有备用安全性ID的用户信息，然后又获得具有对象ID的相同信息。我想这不是真正的问题，我可能可以添加一个前提条件，以跳过按社会对象的对象ID进行读取。

我不会说这个问题现在已经解决，我们仍然需要对其进行更多测试，以确保一切正常。

与Azure AD B2C中的第三方提供商的隐式授权流

0 个答案: