Configurar o comportamento da sessão no Azure Active Directory B2C

Antes de começar, use o seletor Escolher um tipo de política para escolher o tipo de política que você está configurando. O Azure Active Directory B2C oferece dois métodos para definir como os usuários interagem com seus aplicativos: por meio de fluxos dos usuários predefinidos ou de políticas personalizadas totalmente configuráveis. As etapas necessárias neste artigo são diferentes para cada método.

O logon único (SSO) adiciona segurança e conveniência quando os usuários se conectam a aplicativos no Azure Active Directory B2C (Azure AD B2C). Este artigo descreve os métodos de logon único utilizados no Azure AD B2C e ajuda você a escolher o método de SSO mais adequado ao configurar a sua política.

Com o logon único, os usuários entram uma vez com uma única conta e obtêm acesso a vários aplicativos. O aplicativo pode ser um aplicativo web, móvel ou de página única, independentemente da plataforma ou do nome de domínio.

Quando o usuário entra inicialmente em um aplicativo, o Azure AD B2C insiste em uma sessão baseada em cookies. Após as solicitações de autenticação subsequentes, o Azure AD B2C lê e valida a sessão baseada em cookies e emite um token de acesso sem solicitar que o usuário entre novamente. Se a sessão baseada em cookies expirar ou se tornar inválida, o usuário será solicitado a entrar novamente.

Pré-requisitos

• Criar um fluxo do usuário para que os usuários podem se registrar e entrar no seu aplicativo.
• Registrar um aplicativo Web.

• Conclua as etapas em Introdução às políticas personalizadas no Active Directory B2C
• Registrar um aplicativo Web.

Visão geral da sessão do Azure AD B2C

A integração com o Azure AD B2C envolve três tipos de sessões de SSO:

• Azure AD B2C - sessão gerenciada pelo Azure AD B2C
• Provedor de identidade federada - sessão gerenciada pelo provedor de identidade, por exemplo, Facebook, Salesforce ou conta Microsoft
• Aplicativo - sessão gerenciada pelo aplicativo Web, móvel ou de página única

Configuração do Azure AD B2C

Quando um usuário é autenticado com êxito com uma conta local ou social, o Azure AD B2C armazena uma sessão baseada em cookies no navegador do usuário. O cookie é armazenado sob o nome de domínio do locatário Azure AD B2C, como https://contoso.b2clogin.com.

Quando um usuário entra com uma conta federada, uma janela de tempo de sessão, também conhecida como TTL (vida útil), é iniciada. Se o usuário entrar no mesmo aplicativo ou em um aplicativo diferente dentro desse TTL, o Azure AD B2C tentará adquirir um novo token de acesso do provedor de identidade federado. Se a sessão do provedor de identidade federada tiver expirado ou for inválida, o provedor de identidade federada solicitará ao usuário suas credenciais. Se a sessão ainda estiver ativa (ou se o usuário entrou com uma conta local em vez de uma conta federada), o Azure AD B2C autorizará o usuário e eliminará as solicitações adicionais.

Você pode configurar o comportamento da sessão, incluindo o TTL da sessão e como o Azure AD B2C compartilha a sessão entre políticas e aplicativos.

Sessão do provedor de identidade federado

Um provedor de identidade social ou empresarial gerencia sua própria sessão. O cookie é armazenado sob o nome de domínio do provedor de identidade, como https://login.salesforce.com. O Azure AD B2C não controla a sessão do provedor de identidade federada. Em vez disso, o comportamento da sessão é determinado pelo provedor de identidade federada.

Considere o cenário a seguir.

1. Um usuário entra no Facebook para verificar o feed.
2. Posteriormente, o usuário abre seu aplicativo e inicia o processo de entrada. O aplicativo redireciona o usuário para o Azure AD B2C para concluir o processo de entrada.
3. Na página de inscrição ou entrada do Azure AD B2C, o usuário opta por entrar com sua conta do Facebook. O usuário é redirecionado para o Facebook. Se houver uma sessão ativa no Facebook, o usuário não receberá uma solicitação para fornecer suas credenciais e será redirecionado imediatamente para o Azure AD B2C com um token do Facebook.

Sessão do aplicativo

Um token de acesso OAuth2, um token de ID ou um token SAML pode proteger um aplicativo web, móvel ou de página única. Quando um usuário tenta acessar um recurso protegido no aplicativo, o aplicativo verifica se há uma sessão ativa no lado dele. Se uma sessão de aplicativo não existir ou a sessão expirar, o aplicativo direcionará o usuário para a página de entrada do Azure AD B2C.

A sessão de aplicativo pode ser uma sessão baseada em cookies armazenada sob o nome de domínio do aplicativo, como https://contoso.com. Os aplicativos móveis podem armazenar a sessão de forma diferente, mas usando uma abordagem semelhante.

Configurar o comportamento da sessão do Azure AD B2C

Você pode configurar o comportamento de sessão do Azure AD B2C, incluindo:

• A duração da sessão do aplicativo Web (minutos) - o tempo em que o cookie de sessão do Azure AD B2C fica armazenado no navegador do usuário após a autenticação bem-sucedida. Você pode definir o tempo de vida da sessão para até 24 horas.

• Tempo limite da sessão do aplicativo web - indica como uma sessão é estendida pela configuração de tempo de vida da sessão ou pela configuração manter-me conectado (KMSI).

  • Sem interrupção - indica que a sessão é estendida toda vez que o usuário executa uma autenticação baseada em cookie (padrão).
  • Absoluta – indica que o usuário é forçado a autenticar novamente após o período de tempo especificado.

• Configuração de logon único – a sessão de Azure AD B2C pode ser configurada com os seguintes escopos:

  • Locatário -essa configuração é o padrão. O uso dessa configuração permite a vários aplicativos e fluxos de usuário em seu locatário B2C compartilhar a mesma sessão de usuário. Por exemplo, depois que um usuário fizer login em um aplicativo, o usuário também poderá fazer login em outro ao acessá-lo.
  • Aplicação - Esta configuração permite que você mantenha uma sessão de usuário exclusivamente para um aplicativo, independente de outros aplicativos. Por exemplo, você pode usar essa configuração se quiser que o usuário entre no Contoso Pharmacy, independente do usuário já estar conectado ao Contoso Groceries.
  • Política - Essa configuração permite que você mantenha uma sessão de usuário exclusivamente para um fluxo de usuário, independentemente dos aplicativos que a usam. Por exemplo, o Azure AD B2C concede ao usuário acesso a partes de segurança superior de vários aplicativos se o usuário já entrou e concluiu uma etapa de MFA (autenticação multifator). Esse acesso continua contanto que a sessão associada ao fluxo do usuário permaneça ativa.
  • Desabilitado – essa configuração força o usuário a percorrer o fluxo do usuário inteiro em cada execução da política.

Configurar o fluxo do usuário

Para configurar o comportamento da sessão no seu fluxo de usuário, siga estas etapas:

1. Entre no portal do Azure.
2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o seu locatário do Azure Active Directory B2C no menu Diretórios + assinaturas.
3. Escolha Todos os serviços no canto superior esquerdo do Portal do Azure, pesquise Azure AD B2C e selecione-o.
4. Escolha Fluxos de usuário.
5. Abra o fluxo de usuários criado anteriormente.
6. Selecione Propriedades.
7. Configure o tempo de vida da sessão do aplicativo web (minutos) , o tempo limite da sessão do aplicativo web, a configuração de logon únicoe exigir o token de ID em solicitações de logout, conforme necessário.
8. Clique em Salvar.

Configurar uma política personalizada

Para configurar o comportamento da sessão na sua política personalizada, siga estas etapas:

1. Abra o arquivo RP (terceira parte confiável), por exemplo, SignUpOrSignin.xml

2. Se ele ainda não existir, adicione o elemento <UserJourneyBehaviors> a seguir ao elemento <RelyingParty>. Ele precisa estar localizado imediatamente após o <DefaultUserJourney ReferenceId="UserJourney Id"/>.

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

   Depois de adicionar os elementos de comportamento do percurso do usuário, o elemento RelyingParty deve ser semelhante ao seguinte exemplo:

   <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. Altere o valor do atributo Scope para um dos possíveis valores: Suppressed, Tenant, Application ou Policy. Para obter mais informações, confira o artigo de referência do RelyingParty.

4. Defina o elemento SessionExpiryType como Rolling ou Absolute. Para obter mais informações, confira o artigo de referência do RelyingParty.

5. Defina o elemento SessionExpiryInSeconds como um valor numérico entre 900 segundos (15 minutos) e 86.400 segundos (24 horas). Para obter mais informações, confira o artigo de referência do RelyingParty.

Habilitar manter-me conectado (KMSI)

Você pode habilitar o recurso KMSI para os usuários de seus aplicativos web e nativos que têm contas locais em seu diretório de Azure AD B2C. Quando você habilita o recurso, os usuários podem optar por permanecerem conectados para que a sessão permaneça ativa após fechar o navegador. A sessão é mantida configurando um cookie persistente. Os usuários que escolhem KMSI podem reabrir o navegador sem precisarem inserir novamente seu nome de usuário e senha. Esse acesso (cookie persistente) é revogado quando um usuário se desconecta. Para obter mais informações, confira a Demonstração ao vivo.

A KMSI é configurável no nível de fluxo de usuário individual. Antes de habilitar a KMSI para seus fluxos de usuário, considere o seguinte:

• A KMSI é suportada apenas as versões recomendadas de entrada e inscrição (SUSI), entrada e fluxos de usuário de edição de perfil. Se, no momento, você tiver as versões Padrão (Herdado) ou Herdado de visualização - v2 desses fluxos de usuário e quiser habilitar a KMSI, precisará criar novas versões Recomendado desses fluxos de usuário.
• Não há suporte para KMSI com fluxos de usuário de inscrição ou redefinição de senha.
• Se você quiser habilitar a KMSI para todos os aplicativos em seu locatário, recomendamos que você habilite a KMSI para todos os fluxos de usuário em seu locatário. Como um usuário pode ser apresentado a várias políticas durante uma sessão, é possível que eles encontrem um que não tenha a KMSI habilitada, o que removeria o cookie KMSI da sessão.
• A KMSI não deve ser habilitada em computadores públicos.

Configurar a KMSI para um fluxo de usuário

Para habilitar a KMSI para o seu fluxo de usuário:

1. Entre no portal do Azure.

2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o seu locatário do Azure Active Directory B2C no menu Diretórios + assinaturas.

3. Escolha Todos os serviços no canto superior esquerdo do Portal do Azure, pesquise Azure AD B2C e selecione-o.

4. Selecione Fluxos de usuários (políticas) .

5. Abra o fluxo de usuários criado anteriormente.

6. Selecione Propriedades.

7. EmComportamento da sessão, selecione Habilitar manter-me conectado na sessão. Ao lado de Manter-me conectado na sessão (dias) , insira um valor de 1 a 90 para especificar o número de dias que uma sessão pode permanecer aberta.

   

Os usuários não devem habilitar essa opção em computadores públicos.

Configurar o identificador de página

Para habilitar a KMSI, defina o elemento de definição de conteúdo DataUri para oidentificador da páginaunifiedssp e a versão da página1.1.0 ou superior.

1. Abra o arquivo de extensão da sua política. Por exemplo, SocialAndLocalAccounts/TrustFrameworkExtensions.xml. Esse arquivo de extensão é um dos arquivos de política incluídos no pacote de início de política personalizada, que você deve ter obtido no pré-requisito, Introdução às políticas personalizadas.

2. Pesquise o elemento BuildingBlocks. Se o elemento não existir, adicione-o.

3. Adicione o elemento ContentDefinitions ao elemento BuildingBlocksda política.

   Sua política personalizada deverá ter o seguinte snippet de código:

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

Adicionar os metadados ao perfil técnico autodeclarado

Para adicionar a caixa de seleção KMSI à página de inscrição e entrada, defina os setting.enableRememberMe metadados como true. Substitua os perfis técnicos de SelfAsserted-LocalAccountSignin-Email no arquivo de extensão.

1. Localize o elemento ClaimsProviders. Se o elemento não existir, adicione-o.

2. Adicione os seguintes provedores de declarações ao elemento ClaimsProviders:

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

3. Salve o arquivo de extensões.

Criar um arquivo de terceira parte confiável

Atualize o arquivo de RP (terceira parte confiável) que iniciará o percurso do usuário que você criou. O parâmetro keepAliveInDays permite que você configure o quanto o cookie de sessão KMSI (Manter-me conectado) deve persistir. Por exemplo, se você definir o valor para 30, o cookie de sessão KMSI persistirá por 30 dias. O intervalo para o valor é de 1 a 90 dias. A definição do valor como 0 desliga a funcionalidade KMSI.

1. Abra o arquivo de política personalizada. Por exemplo, SignUpOrSignin.xml.

2. Se ele ainda não existir, adicione um nó filho <UserJourneyBehaviors> ao nó <RelyingParty>. Ele deve estar localizado imediatamente após <DefaultUserJourney ReferenceId="User journey Id" />, por exemplo: <DefaultUserJourney ReferenceId="SignUpOrSignIn" />.

3. Adicione o seguinte nó como um filho do elemento <UserJourneyBehaviors>.

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

Você define KeepAliveInDays e SessionExpiryInSeconds para que, durante uma conexão, se um usuário habilitar o KMSI, o KeepAliveInDays seja usado para definir os cookies, caso contrário, o valor especificado no parâmetro SessionExpiryInSeconds será usado. É recomendável que você defina o valor de SessionExpiryInSeconds para um período curto (1200 segundos), enquanto o valor de KeepAliveInDays pode ser definido como um período relativamente longo (30 dias), conforme mostrado no exemplo a seguir:

<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>

Sair

Quando você quiser conectar o usuário do aplicativo, não basta limpar os cookies do aplicativo ou encerrar a sessão do usuário. Você também deve redirecionar o usuário ao Azure AD B2C para sair. Caso contrário, o usuário pode ser capaz de autenticar novamente seus aplicativos sem inserir suas credenciais de novo.

Após uma solicitação de saída, o Azure AD B2C:

1. Invalida a sessão baseada em cookies do Azure AD B2C.
2. Tenta se desconectar de provedores de identidade federados.

1. Invalida a sessão baseada em cookies do Azure AD B2C.
2. Tenta sair de provedores de identidade federada:
   • OpenId Connect – se o ponto de extremidade de configuração bem conhecido do provedor de identidade especificar um end_session_endpoint local. A solicitação de saída não passa o id_token_hint parâmetro. Se o provedor de identidade federada exigir esse parâmetro, a solicitação de saída falhará.
   • OAuth2 – se os metadados do provedor de identidade contiverem o end_session_endpoint local.
   • SAML - se os metadados do provedor de identidade contiverem o SingleLogoutService local.
3. De forma opcional, desconecta-se dos outros aplicativos. Para obter mais informações, consulte a seção de saída única.

Observação

Você pode desabilitar a saída de provedores de identidade federada, definindo os metadados do perfil técnico do provedor de identidade SingleLogoutEnabled como false.

A saída limpa o estado de logon único no Azure AD B2C, mas talvez não execute a saída do usuário de sua sessão do provedor de identidade social. Se o usuário selecionar o mesmo provedor de identidade durante uma conexão subsequente, o usuário poderá ser autenticado novamente, sem entrar em suas credenciais. Se um usuário desejar sair do seu aplicativo, isso não significa, necessariamente, que ele deseja se desconectar de sua conta do Facebook. No entanto, se forem usadas contas locais, a sessão do usuário será encerrada corretamente.

Logout único

Ao redirecionar o usuário para o ponto de extremidade de saída do Azure AD B2C (para o OAuth2 e o OpenID Connect) ou enviar um LogoutRequest (para o SAML), o Azure AD B2C limpa a sessão do usuário no navegador. No entanto, o usuário pode ainda entrar em outros aplicativos que usam o Azure AD B2C para autenticação. Para desconectar o usuário de todos os aplicativos que têm uma sessão ativa, o Azure AD B2C oferece suporte à desconexão única, também conhecida como SLO (Single Log-out).

Durante a desconexão, o Azure AD B2C envia simultaneamente uma solicitação HTTP para a URL de logoff registrada de todos os aplicativos nos quais o usuário está conectado no momento.

Configurar sua política personalizada

Para dar suporte ao logout único, os perfis técnicos do emissor do token para JWT e SAML devem especificar:

• O nome do protocolo, como <Protocol Name="OpenIdConnect" />
• A referência ao perfil técnico da sessão, como UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />.

O exemplo a seguir mostra os emissores JWT e token SAML com logout único:

<ClaimsProvider>
  <DisplayName>Local Account SignIn</DisplayName>
  <TechnicalProfiles>
    <!-- JWT Token Issuer -->
    <TechnicalProfile Id="JwtIssuer">
      <DisplayName>JWT token 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>

Configurar seu aplicativo

Para que um aplicativo participe da desconexão única:

• Para provedores de serviços SAML, configure o aplicativo com o local SingleLogoutService no documento de metadados SAML dele. Você também pode configurar o registro do aplicativo logoutUrl. Para saber mais, confira configurar a URL de logoff.
• Para aplicativos OpenID Connect ou OAuth2, defina o atributo logoutUrl do manifesto de registro do aplicativo. Para configurar a URL de logoff:
  1. No menu do Azure AD B2C, selecione Registros de aplicativos.
  2. Selecione o registro do seu aplicativo.
  3. Em Gerenciar, selecione Autenticação.
  4. Na URL de logoff do canal frontal, configure a URL de logoff.

Como lidar com solicitações de desconexão única

Quando o Azure AD B2C recebe a solicitação de logoff, ele usa um iframe HTML de canal frontal para enviar uma solicitação HTTP à URL de logoff registrada de cada aplicativo participante no qual o usuário está conectado no momento. Observe que o aplicativo que dispara a solicitação de logoff não recebe essa mensagem de logoff. Seus aplicativos devem responder à solicitação de desconexão limpando a sessão do aplicativo que identifica o usuário.

• Para aplicativos OpenID Connect e OAuth2, o Azure AD B2C envia uma solicitação HTTP GET para a URL de logoff registrada.
• Para aplicativos SAML, o Azure AD B2C envia uma solicitação de logoff SAML para a URL de logoff registrada.

Quando o Azure AD B2C notifica todos os aplicativos sobre a saída, ele continua fazendo o seguinte:

• Para os aplicativos OpenID Connect ou OAuth2, o usuário é redirecionado para o post_logout_redirect_uri solicitado, incluindo o parâmetro state (opcional) especificado na solicitação inicial. Por exemplo, https://contoso.com/logout?state=foo.
• Para os aplicativos SAML, uma resposta de logoff SAML é enviada via HTTP POST ao aplicativo que enviou inicialmente a solicitação de logoff.

Proteger seu redirecionamento de logout

Após o logout, o usuário é redirecionado para o URI especificado no parâmetro post_logout_redirect_uri, independentemente das URLs de resposta especificadas para o aplicativo. No entanto, se um valor válido id_token_hint for passado e o token de ID necessário em solicitações de logout estiver ativado, o Azure AD B2C verificará se o valor de post_logout_redirect_uri corresponde a um dos URIs de redirecionamento configurados do aplicativo antes de executar o redirecionamento. Se nenhuma URL de resposta correspondente foi configurada para o aplicativo, uma mensagem de erro será exibida e o usuário não será redirecionado.

Para exigir um token de ID em solicitações de logout:

1. Entre no portal do Azure.
2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o seu locatário do Azure Active Directory B2C no menu Diretórios + assinaturas.
3. Escolha Todos os serviços no canto superior esquerdo do Portal do Azure, pesquise Azure AD B2C e selecione-o.
4. Escolha Fluxos de usuário.
5. Abra o fluxo de usuários criado anteriormente.
6. Selecione Propriedades.
7. Habilitar a exigência de token de ID em solicitações de logout.

Para exigir um token de ID em solicitações de logout, adicione um elemento UserJourneyBehaviors dentro do elemento RelyingParty. Em seguida, defina EnforceIdTokenHintOnLogout do elemento SingleSignOn como true. Para obter mais informações, confira a Demonstração ao vivo. O seu elemento UserJourneyBehavors deve ficar parecido com este exemplo:

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

Para configurar a URL de logout do aplicativo:

1. Selecione Registros de aplicativo e, em seguida, selecione o seu aplicativo.
2. Selecione Autenticação.
3. Na caixa de texto URL de logout, digite o URI de redirecionamento de logout de postagem e, em seguida, selecione Salvar.

Próximas etapas

• Saiba como configurar tokens no Azure AD B2C.