3

为什么我们需要多个令牌请求:

我们为 SPA 使用隐式流从 Azure AD B2C 获取访问令牌,以访问受 B2C 保护的 API。我们需要访问多个 API,这些 API 都在 B2C 中注册为不同的应用程序,因此每个 API 都有不同的受众。由于他们都是不同的受众,B2C 不支持多个受众的单个令牌请求,因此我们必须发出多个令牌请求。

B2C 设置背景

我们支持本地帐户登录,以及使用我们其他 Azure AD 身份提供程序的社交登录。我们还为我们的 B2C(身份体验框架)使用自定义策略

问题

使用 Azure AD login social login的用户会出现此问题。用户以前登录过。

当发出多个请求时,我们在 google chrome 中注意到以下网络跟踪:

Chrome 网络跟踪 上面的跟踪显示:

  1. 第 1 行和第 2 行是对 2 个不同 api/范围/受众的 B2C授权端点的令牌请求。
  2. 第 3+4 行和第 5+6 行,这些重定向到login.windows.netlogin.microsoftonline.com都作为特定 api/scope/audience 的 1 组。
  3. 第 7 行和第 8 行都是发回 B2C 的响应(id 令牌)表单。第 7 行从表单发布返回了错误的请求响应。

问题

  1. 为什么需要重定向回l​​ogin.windows.netlogin.microsoftonline.com由于用户之前已经登录,他不应该有一个有效的会话,因此 B2C 可以返回请求的令牌吗?
  2. B2C 能否支持来自同一浏览器的并发令牌请求(或登录)以获得社交登录身份?我们怀疑这是由于 B2C 期望从社交登录获得的身份验证状态只有一个且唯一,因此并发登录会导致此状态相互覆盖,从而导致另一个请求无效。根本没有关于错误请求响应的详细信息。它只显示一个带有“错误请求”文本的空白页面。

-- 2019 年 3 月 5 日更新 --

在对 B2C 自定义策略进行了一些修改之后,我在登录一次后通过更改以下内容设法抑制了重定向:

        <TechnicalProfile Id="SM-SocialLogin">
          <DisplayName>Session Mananagement Provider</DisplayName>
          <!--Changed to this provider instead of ExternalLoginSSOSessionProvider-->
          <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" />
            ... removed for brevity ...
            <PersistedClaim ClaimTypeReferenceId="groups" />
          </PersistedClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
          </OutputClaims>
        </TechnicalProfile>

所做的更改是使用默认会话提供程序。

为什么外部会话提供者不会抑制重新身份验证?设置为 false的元数据AlwaysFetchClaimsFromProvider也不会抑制重新验证。

但是使用这种解决方法会给我们带来另一个问题,该问题在一个单独的问题中提出。

4

0 回答 0