Azure AD B2C并发访问令牌请求

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

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

B2C设置的背景信息

我们支持本地帐户登录，以及使用其他Azure广告身份提供商的社交登录。我们还为我们的B2C（身份体验框架）使用定制策略

问题

此问题发生在使用Azure AD登录社交登录的用户身上。用户以前登录过

当发出多个请求时，我们注意到google chrome中的以下网络跟踪：

上面的跟踪显示：

第1行和第2行是对B2C授权端点的令牌请求，用于2个不同的api/范围/受众

第3+4行和第5+6行，这些都是重定向到login.windows.net和login.microsoftonline.com的，都是针对特定api/范围/受众的1集

第7行和第8行都是返回B2C的响应（id令牌）表单。第7行从表单post返回一个错误请求响应

问题

为什么需要重定向回login.windows.net或login.microsoftonline.com？既然用户以前登录过，他不应该有一个有效的会话，这样B2C就可以返回请求的令牌吗

B2C能否支持来自同一浏览器的并发令牌请求（或登录）以获取社交登录身份？我们怀疑这是因为B2C期望社交登录的身份验证状态只有一个且唯一，因此并发登录会导致此请求相互覆盖，从而导致其他请求无效。没有关于错误请求响应的详细信息。它只显示一个空白页面，其中有“错误请求”文本 --更新日期：2019年3月5日--

在对B2C自定义策略进行了一些修补之后，我在登录一次后，通过更改以下内容，成功地抑制了重定向：

会话管理提供程序
... 为简洁起见删除。。。

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

但是为什么外部会话提供程序不会禁止重新验证？元数据

AlwaysFetchClaimsFromProvider

设置为false也不会抑制重新身份验证

---

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

我认为需要重定向来测试会话（sessioncookies只发送到从该域提供服务的页面）。双重重定向可能是由社交组件引起的，因为它不是AzureAD登录（不确定）@eckes是的重定向需要针对Azure AD idp进行身份验证（获取令牌），但问题是b2c一直在这样做。我设法修改了b2c自定义策略，将Azure广告声明存储在会话cookie中，以防止其重定向，但出现了另一个问题，stringCollection声明（声明数组）被序列化为List.ToString（）在反序列化时无法恢复原始值的情况下。您能否将更新作为您自己问题的答案？我几乎错过了它，因为当我最初读它的时候，我略读了一下，就像“哦，不，宝贝，这一切都错了”。。。然后我意识到这是一个更新，它为你工作。这对我有用！谢谢