Поделиться через

Настройка поведения сеанса в Azure Active Directory B2C

Прежде чем начать, используйте селектор типа политики в верхней части этой страницы, чтобы выбрать тип политики, которую вы настроите. Azure Active Directory B2C предлагает два метода определения способа взаимодействия пользователей с вашими приложениями: с помощью предопределенных потоков пользователей или полностью настраиваемых пользовательских политик. Действия, которые необходимо выполнить, отличаются для каждого метода.

Единый вход (SSO) добавляет безопасность и удобство при авторизации пользователей в различных приложениях Azure Active Directory B2C (Azure AD B2C). В этой статье описываются методы единого входа, используемые в Azure AD B2C, и вы можете выбрать наиболее подходящий метод единого входа при настройке политики.

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

Когда пользователь изначально входит в приложение, Azure AD B2C сохраняет сеанс на основе файлов cookie. После последующих запросов проверки подлинности Azure AD B2C считывает и проверяет сеанс на основе файлов cookie и выдает маркер доступа, не запрашивая повторного входа пользователя. Если срок действия сеанса на основе файлов cookie истекает или становится недопустимым, пользователю будет предложено снова войти в систему.

Примечание.

Если пользователь использует браузер, который блокирует сторонние куки-файлы, существуют ограничения SSO из-за ограниченного доступа к сеансу на основе куки-файлов. Наиболее заметное влияние на пользователя заключается в том, что для входа требуется больше взаимодействий. Кроме того, выход через фронтальный канал не сразу очищает состояние аутентификации из федеративных приложений. Ознакомьтесь с нашими рекомендуемыми способами обработки блокировки сторонних файлов cookie в браузерах.

Предпосылки

Общие сведения о сеансе Azure AD B2C

Интеграция с Azure AD B2C включает три типа сеансов единого входа:

  • Azure AD B2C — сеанс, управляемый Azure AD B2C
  • Федеративный поставщик удостоверений — сеанс, управляемый поставщиком удостоверений, например Facebook, Salesforce или учетной записью Майкрософт
  • Приложение — сеанс, управляемый веб-приложением, мобильным или одностраничным приложением

Сеанс единого входа

Сеанс Azure AD B2C

Когда пользователь успешно проходит проверку подлинности с помощью локальной или социальной учетной записи, Azure AD B2C сохраняет сеанс на основе файлов cookie в браузере пользователя. Файл cookie хранится в домене клиента Azure AD B2C, например https://contoso.b2clogin.com.

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

Вы можете настроить поведение сеанса, включая время жизни сеанса (TTL) и как Azure AD B2C делится сеансом между политиками и приложениями.

Сеанс поставщика федеративной идентификации

Поставщик удостоверений социальной или корпоративной идентичности управляет собственным сеансом. Файл cookie хранится под доменным именем поставщика удостоверений, например https://login.salesforce.com. Azure AD B2C не управляет сеансом федеративного поставщика удостоверений. Вместо этого поведение сеанса определяется федеративным поставщиком удостоверений.

Рассмотрим следующий сценарий:

  1. Пользователь входит в аккаунт Facebook, чтобы проверить свою ленту новостей.
  2. Позже пользователь открывает приложение и запускает процесс входа. Приложение перенаправляет пользователя в Azure AD B2C, чтобы завершить процесс входа.
  3. На странице регистрации или входа в Azure AD B2C пользователь выбирает вход с помощью учетной записи Facebook. Пользователь перенаправляется на Facebook. Если в Facebook есть активный сеанс, пользователю не предлагается предоставить свои учетные данные, и он немедленно перенаправляется в Azure AD B2C с токеном Facebook.

Сеанс приложения

Маркер доступа OAuth2, маркер идентификатора или токен SAML может защитить веб-, мобильное или одностраничное приложение. Когда пользователь пытается получить доступ к защищенному ресурсу приложения, приложение проверяет наличие активного сеанса на стороне приложения. Если сеанс приложения не существует или срок действия сеанса истекает, приложение направляет пользователя на страницу входа Azure AD B2C.

Сеанс приложения может быть сеансом на основе файлов cookie, хранящимся под доменным именем приложения, например https://contoso.com. Мобильные приложения могут хранить сеанс по-другому, но с помощью аналогичного подхода.

Настройка поведения сеанса Azure AD B2C

Вы можете настроить поведение сеанса Azure AD B2C, в том числе:

  • Время существования сеанса веб-приложения (минуты) — время хранения файла cookie сеанса Azure AD B2C в браузере пользователя после успешной проверки подлинности. Можно настроить время существования сеанса до 24 часов.

  • Время истечения сеанса веб-приложения — указывает, как сеанс продлевается настройкой длительности сеанса или параметром "Сохранить вход" (KMSI).

    • Rolling — указывает, что сеанс расширяется каждый раз, когда пользователь выполняет проверку подлинности на основе файлов cookie (по умолчанию).
    • Абсолютный — указывает, что пользователь вынужден повторно пройти проверку подлинности после указанного периода времени.

  • Конфигурация единого входа — сеанс Azure AD B2C можно настроить со следующими областями применения:

    • Клиент — этот параметр используется по умолчанию. Использование этого параметра позволяет нескольким приложениям и потокам пользователей в клиенте B2C совместно использовать один и тот же сеанс пользователя. Например, после входа пользователя в приложение пользователь также может легко войти в другой после доступа к нему.
    • Приложение — этот параметр позволяет поддерживать сеанс пользователя исключительно для приложения, независимо от других приложений. Например, этот параметр можно использовать, если вы хотите, чтобы пользователь авторизовался в Contoso Pharmacy независимо от того, авторизован ли он уже в Contoso Groceries.
    • Политика . Этот параметр позволяет поддерживать сеанс пользователя исключительно для потока пользователя, независимо от приложений, использующих его. Например, Azure AD B2C предоставляет пользователю доступ к частям более высокого уровня безопасности нескольких приложений, если пользователь уже выполнил вход и завершил многофакторную проверку подлинности (MFA). Этот доступ продолжается до тех пор, пока сеанс, связанный с потоком пользователя, остается активным.
    • Подавление . Этот параметр заставляет пользователя выполнять весь поток пользователя при каждом выполнении политики.

Настройка потока пользователя

Чтобы настроить поведение сеанса в потоке пользователя, выполните следующие действия.

  1. Войдите на портал Azure.
  2. Если у вас есть доступ к нескольким клиентам, щелкните значок Настройки в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню Каталоги и подписки.
  3. Выберите все службы в левом верхнем углу портала Azure, а затем найдите и выберите Azure AD B2C.
  4. Выберите потоки пользователей.
  5. Откройте ранее созданный поток пользователя.
  6. Выберите Свойства.
  7. Настройте время существования сеанса веб-приложения (минуты),время ожидания сеанса веб-приложения, конфигурацию единого входа и требовать маркер идентификатора в запросах выхода по мере необходимости.
  8. Выберите Сохранить.

Настройка настраиваемой политики

Чтобы настроить поведение сеанса в пользовательской политике, выполните следующие действия.

  1. Откройте файл доверяющей стороны (RP), например SignUpOrSignin.xml

  2. Если он еще не существует, добавьте следующий <UserJourneyBehaviors> элемент в <RelyingParty> элемент. Он должен находиться сразу после <DefaultUserJourney ReferenceId="UserJourney Id"/>.

    <UserJourneyBehaviors>
  <SingleSignOn Scope="Application" />
  <SessionExpiryType>Absolute</SessionExpiryType>
  <SessionExpiryInSeconds>86400</SessionExpiryInSeconds>
</UserJourneyBehaviors>

    После добавления элементов RelyingParty поведения взаимодействия пользователя элемент должен выглядеть следующим образом:

    <RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <UserJourneyBehaviors>
    <SingleSignOn Scope="Application" />
    <SessionExpiryType>Absolute</SessionExpiryType>
    <SessionExpiryInSeconds>86400</SessionExpiryInSeconds>
  </UserJourneyBehaviors>
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      ...
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

  3. Измените значение атрибута Scope на одно из возможных значений: Suppressed, , TenantApplicationили Policy. Дополнительные сведения см. в справочной статье RelyingParty.

  4. Задайте для SessionExpiryType элемента Rolling значение или Absolute. Дополнительные сведения см. в справочной статье RelyingParty.

  5. SessionExpiryInSeconds Задайте для элемента числовое значение в диапазоне от 900 секунд (15 минут) до 86 400 секунд (24 часа). Дополнительную информацию см. в справочной статье Доверяющая сторона.

Включить опцию "Оставаться в системе" (KMSI)

Вы можете включить функцию KMSI для пользователей веб-приложений и собственных приложений, имеющих локальные учетные записи в каталоге Azure AD B2C. Когда вы включите эту функцию, пользователи могут выбрать оставаться в системе, чтобы сеанс оставался активным после закрытия браузера. Сеанс поддерживается путем установки постоянного файла cookie. Пользователи, которые выбирают KMSI, могут повторно открыть браузер, не запрашивая повторное ввод имени пользователя и пароля. Этот доступ (постоянный файл cookie) отменяется при выходе пользователя. Дополнительные сведения см. в демонстрации Live.

Пример страницы входа в систему и регистрации с флажком

KMSI настраивается на уровне отдельного потока пользователя. Прежде чем включить KMSI для потоков пользователей, рассмотрите следующее:

  • KMSI поддерживается только для рекомендуемых версий пользовательских потоков регистрации и входа (SUSI), а также входа и редактирования профиля. Если у вас есть версии пользовательских потоков Standard (Legacy) или Legacy preview - v2, и вы хотите включить KMSI, необходимо создать новые рекомендованные версии этих потоков пользователей.
  • KMSI не поддерживается при сбросе пароля или процессах регистрации пользователей.
  • Если вы хотите включить KMSI для всех приложений в клиенте, рекомендуется включить KMSI для всех потоков пользователей в клиенте. Пользователь может столкнуться с несколькими политиками во время сеанса, и может попасть на такую, которая не включает KMSI, что приведет к удалению файла cookie KMSI из сеанса.
  • KMSI не следует включать на общедоступных компьютерах.

Настройка KMSI для потока пользователя

Чтобы включить KMSI для потока пользователя, выполните приведенные действия.

  1. Войдите на портал Azure.

  2. Если у вас есть доступ к нескольким клиентам, щелкните значок Настройки в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню Каталоги и подписки.

  3. Выберите все службы в левом верхнем углу портала Azure, а затем найдите и выберите Azure AD B2C.

  4. Выберите потоки пользователей (политики).

  5. Откройте ранее созданный поток пользователя.

  6. Выберите Свойства.

  7. В разделе "Поведение сеанса" выберите "Включить" для входа в сеанс. Рядом со значением "Сохранить вход в сеанс" (дни) введите значение от 1 до 90, чтобы указать количество дней, в течение которых сеанс может оставаться открытым.

    Включение сохранения входа в сеанс

Пользователи не должны включать этот параметр на общедоступных компьютерах.

Настройка идентификатора страницы

Чтобы включить KMSI, задайте для элемента определения содержимого DataUriидентификатор страницыunifiedssp и версию страницы1.1.0 или более поздней.

  1. Откройте файл расширения вашей политики. Например, SocialAndLocalAccounts/TrustFrameworkExtensions.xml. Этот файл расширения является одним из файлов политики, включенных в начальный пакет настраиваемой политики, который вы получаете в предварительных требованиях, начало работы с настраиваемыми политиками.

  2. Найдите элемент BuildingBlocks . Если элемент не существует, добавьте его.

  3. Добавьте элемент ContentDefinitions в элемент BuildingBlocks политики.

    Ваша пользовательская политика должна выглядеть примерно как следующий фрагмент кода:

    <BuildingBlocks>
  <ContentDefinitions>
    <ContentDefinition Id="api.signuporsignin">
      <DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.1.0</DataUri>
    </ContentDefinition>
  </ContentDefinitions>
</BuildingBlocks>

Добавление метаданных в самозаверяемый технический профиль

Чтобы добавить флажок KMSI на страницу регистрации и входа, установите значение true для метаданных setting.enableRememberMe. Переопределите технические профили SelfAsserted-LocalAccountSignin-Email в файле расширения.

  1. Найдите элемент ClaimsProviders. Если элемент не существует, добавьте его.

  2. Добавьте в элемент ClaimsProviders следующий поставщик утверждений:

    <ClaimsProvider>
  <DisplayName>Local Account</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
      <Metadata>
        <Item Key="setting.enableRememberMe">True</Item>
      </Metadata>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

  3. Сохраните файл расширений.

Настройка файла доверяющей стороны

Обновите файл доверяющей стороны (RP), который инициирует созданный вами путь пользователя. Параметр keepAliveInDays позволяет настроить, как долго должен сохраняться файл cookie сеанса "Оставаться в системе" (KMSI). Например, если задать значение 30, файл cookie сеанса KMSI сохраняется в течение 30 дней. Диапазон значения составляет от 1 до 90 дней. Если задать значение 0, функция "Оставаться в системе" будет отключена.

  1. Откройте файл настраиваемой политики. Например, SignUpOrSignin.xml.

  2. Если он еще не существует, добавьте дочерний <UserJourneyBehaviors> узел в <RelyingParty> узел. Он должен находиться сразу после<DefaultUserJourney ReferenceId="User journey Id" />, например: <DefaultUserJourney ReferenceId="SignUpOrSignIn" />

  3. Добавьте следующий узел в качестве дочернего <UserJourneyBehaviors> элемента.

    <UserJourneyBehaviors>
  <SingleSignOn Scope="Tenant" KeepAliveInDays="30" />
  <SessionExpiryType>Absolute</SessionExpiryType>
  <SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
</UserJourneyBehaviors>

Вы задаете значение KeepAliveInDays и SessionExpiryInSeconds таким образом, чтобы во время входа, если пользователь включает KMSI, значение KeepAliveInDays используется для задания файлов cookie, в противном случае используется значение, указанное в параметре SessionExpiryInSeconds. Рекомендуется задать значение SessionExpiryInSeconds в течение короткого периода (1200 секунд), а значение KeepAliveInDays может быть относительно длинным (30 дней), как показано в следующем примере:

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <UserJourneyBehaviors>
    <SingleSignOn Scope="Tenant" KeepAliveInDays="30" />
    <SessionExpiryType>Absolute</SessionExpiryType>
    <SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
  </UserJourneyBehaviors>
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
      <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Выйти

Если вы хотите выйти из приложения, недостаточно просто очистить файлы cookie приложения или завершить сеанс с пользователем. Чтобы выйти из службы, необходимо перенаправить пользователя в Azure AD B2C. В противном случае пользователь может повторно пройти проверку подлинности в приложениях, не вводя учетные данные еще раз.

По запросу выхода из системы Azure AD B2C:

  1. Аннулирует сеанс Azure AD B2C, основанный на файлах cookie.
  2. Пытается выйти из учетных записей у федеративных поставщиков удостоверений.
  1. Аннулирует сеанс, основанный на файлах cookie Azure AD B2C.
  2. Пытается выйти из федеративных поставщиков удостоверений:
    • OpenId Connect - если известная конфигурация поставщика удостоверений указывает местоположение для конечной точки end_session_endpoint. Запрос на выход не передает параметр id_token_hint. Если федеративный поставщик удостоверений требует этого параметра, запрос на выход завершается сбоем.
    • OAuth2 — если метаданные поставщика удостоверений содержат местоположение.
    • SAML — если метаданные поставщика удостоверений содержат SingleLogoutService местоположение.
  3. Опционально, выйти из других приложений. Дополнительные сведения см. в разделе " Единый выход ".

Примечание.

Вы можете отключить выход из учетной записи у федеративных поставщиков удостоверений, настроив метаданные технического профиля поставщика удостоверений SingleLogoutEnabled на false.

Выход очищает состояние единого входа пользователя в Azure AD B2C, но может не завершить сеанс в социальной сети пользователя. Если пользователь выбирает тот же поставщик удостоверений во время последующего входа, он может повторно пройти проверку подлинности без ввода учетных данных. Если пользователь хочет выйти из приложения, это не обязательно означает, что они хотят выйти из своей учетной записи Facebook. Однако если используются локальные учетные записи, сеанс пользователя завершается правильно.

Единый выход из системы

При перенаправлении пользователя на конечную точку выхода Azure AD B2C (для OAuth2 и OpenID Connect) или отправки LogoutRequest (для SAML) Azure AD B2C очищает сеанс пользователя из браузера. Тем не менее пользователь может оставаться вошедшим в другие приложения, использующие Azure Active Directory B2C для аутентификации. Для выхода пользователя из всех приложений, имеющих активный сеанс, Azure AD B2C поддерживает единый выход, также известный как единый Log-Out (SLO).

Во время выхода Azure AD B2C одновременно отправляет HTTP-запрос на зарегистрированный URL-адрес выхода всех приложений, в которые в настоящее время входит пользователь.

Настройка настраиваемой политики

Для поддержки единого выхода из системы необходимо указать технические профили поставщика токенов для JWT и SAML.

  • Имя протокола, например <Protocol Name="OpenIdConnect" />
  • Ссылка на технический профиль сеанса, например UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />.

В следующем примере показаны издатели токенов JWT и SAML с функцией единого выхода из системы.

<ClaimsProvider>
  <DisplayName>Local Account SignIn</DisplayName>
  <TechnicalProfiles>
    <!-- JWT Issuer -->
    <TechnicalProfile Id="JwtIssuer">
      <DisplayName>JWT Issuer</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <OutputTokenFormat>JWT</OutputTokenFormat>
      ...    
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
    </TechnicalProfile>

    <!-- Session management technical profile for OIDC based tokens -->
    <TechnicalProfile Id="SM-jwt-issuer">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.OAuthSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </TechnicalProfile>

    <!--SAML token issuer-->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>SAML token issuer</DisplayName>
      <Protocol Name="SAML2" />
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      ...
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer" />
    </TechnicalProfile>

    <!-- Session management technical profile for SAML based tokens -->
    <TechnicalProfile Id="SM-Saml-issuer">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Настройка приложения

Чтобы приложение участвовало в едином выходе из системы:

  • Для поставщиков служб SAML настройте приложение с расположением SingleLogoutService в документе метаданных SAML. Вы также можете настроить регистрацию приложения logoutUrl. Дополнительные сведения см. в разделе "Настройка URL-адреса выхода".
  • Для приложений OpenID Connect или OAuth2 задайте logoutUrl атрибут манифеста регистрации приложения. Чтобы настроить URL-адрес выхода, выполните следующие действия.
    1. В меню Azure AD B2C выберите регистрации приложений.
    2. Выберите регистрацию приложения.
    3. В разделе Управление выберите Проверка подлинности.
    4. В разделе URL-адреса выхода Front-channel настройте ваш URL-адрес выхода.

Обработка запросов единого выхода из всех систем

Когда Azure AD B2C получает запрос на выход, он использует фронтальный HTML-кадр iframe для отправки HTTP-запроса на зарегистрированный URL-адрес выхода каждого участвующего приложения, в которое пользователь в данный момент вошел. Обратите внимание, что приложение, которое активирует запрос на выход, получает это сообщение об выходе. Приложения должны отвечать на запрос на выход, очищая сеанс приложения, который идентифицирует пользователя.

  • Для приложений OpenID Connect и OAuth2 Azure AD B2C отправляет HTTP-запрос GET на зарегистрированный URL-адрес выхода.
  • Для приложений SAML Azure AD B2C отправляет запрос на выход SAML на зарегистрированный URL-адрес выхода.

Когда Azure AD B2C уведомляет все приложения об уведомлении о выходе, она продолжает выполнение одного из следующих действий:

  • Для приложений OpenID Connect или OAuth2 он перенаправляет пользователя на запрошенный post_logout_redirect_uri параметр, включая (необязательный) state параметр, указанный в первоначальном запросе. Например, https://contoso.com/logout?state=foo.
  • Для приложений SAML система отправляет ответ выхода SAML через HTTP POST в приложение, которое первоначально отправило запрос на выход.

Обезопасьте перенаправление после выхода

После выхода пользователь перенаправляется в URI, указанный в параметре post_logout_redirect_uri , независимо от URL-адресов ответа, указанных для приложения. Однако если действительный id_token_hint передается, а маркер запрашиваемого идентификатора в запросах выхода включен, Azure AD B2C проверяет, соответствует ли значение post_logout_redirect_uri одного из настроенных URI перенаправления приложения перед выполнением перенаправления. Если для приложения не настроен соответствующий URL-адрес ответа, отображается сообщение об ошибке и пользователь не перенаправляется.

Чтобы требовать токен идентификации в запросах на выход из системы:

  1. Войдите на портал Azure.
  2. Если у вас есть доступ к нескольким клиентам, щелкните значок Настройки в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню Каталоги и подписки.
  3. Выберите все службы в левом верхнем углу портала Azure, а затем найдите и выберите Azure AD B2C.
  4. Выберите потоки пользователей.
  5. Откройте ранее созданный поток пользователя.
  6. Выберите Свойства.
  7. Включите требование токена идентификатора в запросах на выход из системы.

Чтобы требовать маркер идентификатора в запросах на выход, добавьте элемент UserJourneyBehaviors в элемент RelyingParty . Затем задайте для элемента SingleSignOn значение параметра EnforceIdTokenHintOnLogout равным true. Для получения дополнительной информации см. демонстрацию в реальном времени. Элемент UserJourneyBehaviors должен выглядеть следующим образом:

<UserJourneyBehaviors>
  <SingleSignOn Scope="Tenant" EnforceIdTokenHintOnLogout="true"/>
</UserJourneyBehaviors>

Чтобы настроить URL-адрес выхода приложения, выполните приведенные действия.

  1. Выберите регистрации приложений и выберите приложение.
  2. Выберите Проверка подлинности.
  3. В текстовом поле URL-адреса выхода введите URI перенаправления после выхода, затем выберите Сохранить.

Связанный контент