Запрос токена одновременного доступа Azure AD B2C

Question

Почему нам нужно несколько запросов токенов:

Мы используем неявный поток для нашего SPA, чтобы получить токены доступа из Azure AD B2C для доступа к API, защищенным B2C.Нам необходимо получить доступ к нескольким API, и все они зарегистрированы как разные приложения в B2C, следовательно, для каждой аудитории.Поскольку все они являются разной аудиторией, B2C не поддерживает один запрос токена для нескольких аудиторий, поэтому нам придется сделать несколько запросов токена.

Справочная информация о настройке B2C

Мы поддерживаем вход в локальную учетную запись, а также вход в социальную сеть , который использует наш другой поставщик удостоверений Azure AD.Мы также используем настраиваемые политики для нашей B2C (среда идентификации пользователей)

Проблема

Проблема возникает для пользователя, использующего вход в Azure AD социальный вход.Пользователь ранее уже входил в систему .

При выполнении нескольких запросов мы заметили следующую сетевую трассировку в Google Chrome:

Трасса, показанная выше:

1. Строки 1 и 2 являются запросом токена для B2C авторизация конечной точки для 2 различных API / областей / аудитории.
2. Строка 3 + 4 и строка 5 + 6, это перенаправления на login.windows.net и login.microsoftonline.com оба в виде 1 набора для определенного API / области действия / аудитории.
3. Строки 7 и 8 являются ответом (id token) отправьте сообщение обратно в B2C.Строка 7 возвращает неверный запрос ответ из бланка.

Вопросы

1. Почемунеобходимо перенаправить обратно на login.windows.net или login.microsoftonline.com ? Поскольку пользователь уже выполнил вход в систему, не должен ли он иметь действительный сеанс и, следовательно,B2C может просто вернуть запрошенный токен?
2. Может ли B2C поддерживать одновременный запрос токена (или логин) от одного и того же браузера для входа в систему идентификатор? Мы подозреваем этопроисходит из-за состояния аутентификации, которое B2C ожидает от социального входа в систему только one и уникально, поэтому одновременный вход в систему заставляет это переопределять друг друга, что затем приводит к тому, что другой запрос будет недействительнымНет подробностей о неправильном ответе на запрос.Это просто показывает пустую страницу с текстом «Плохой запрос».

- Обновление от 5 марта 2019 г. -

После некоторой настройки пользовательских политик 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>

Внесены изменения для использования поставщика сеансов по умолчанию.

Почему внешний поставщик сеансов не будет подавлять повторную аутентификацию?Метаданные AlwaysFetchClaimsFromProvider, установленные в false, также не будут препятствовать повторной аутентификации.

Но использование этого обходного пути вызывает у нас еще одну проблему, которая задается в отдельном вопросе .