Partilhar via

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

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

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

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

Quando o usuário entra inicialmente em um aplicativo, o Azure AD B2C persiste uma sessão baseada em cookies. Após solicitações de autenticação subsequentes, o Azure AD B2C lê e valida a sessão baseada em cookie 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.

Observação

Se o usuário usa um navegador que bloqueia cookies de terceiros, há limitações com o SSO devido ao acesso limitado à sessão baseada em cookies. O impacto mais visível para o usuário é que há mais interações necessárias para entrar. Além disso, a desconexão pelo canal frontal não remove de imediato o estado de autenticação dos aplicativos federados. Consulte as nossas formas recomendadas de como lidar com o bloqueio de cookies de terceiros em navegadores.

Pré-requisitos

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, conta do Facebook, Salesforce ou Microsoft
  • Aplicação - Sessão gerida pela Web, telemóvel ou aplicação de página única

Sessão SSO

Sessão do Azure AD B2C

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

Quando um utilizador entra com uma conta federada, uma janela de tempo de sessão, também conhecida como tempo de vida (TTL), é 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 federada. Se a sessão do provedor de identidade federada expirar ou for inválida, o provedor de identidade federada solicitará suas credenciais ao usuário. Se a sessão do usuário estiver em andamento ou se o usuário estiver conectado usando uma conta local em vez de uma federada, o Azure AD B2C autorizará o usuário e impedirá quaisquer outros prompts.

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 federada

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 seguinte cenário:

  1. Um utilizador inicia sessão no Facebook para verificar o respetivo feed.
  2. Mais tarde, o utilizador abre a sua aplicação e inicia o processo de início de sessão. 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 escolhe 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 será solicitado a fornecer suas credenciais e será imediatamente redirecionado para o Azure AD B2C com um token do Facebook.

Sessão de candidatura

Um token de acesso OAuth2, um token de identificação ou um token SAML pode proteger uma aplicação móvel, web 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 do aplicativo. 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 do aplicativo pode ser uma sessão baseada em cookie armazenada sob o nome de domínio do aplicativo, como https://contoso.com. Os aplicativos móveis podem armazenar a sessão de uma maneira diferente, mas usando uma abordagem semelhante.

Configurar o comportamento de sessão do Azure AD B2C

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

  • Tempo de vida da sessão do aplicativo Web (minutos) - A quantidade de tempo que o cookie de sessão do Azure AD B2C é armazenado no navegador do usuário após a autenticação bem-sucedida. Você pode definir o tempo de vida da sessão 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).

    • Contínuo - Indica que a sessão é estendida sempre que o utilizador executa uma autenticação através de cookies (por predefinição).
    • Absoluto - Indica que o usuário é forçado a se autenticar novamente após o período de tempo especificado.

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

    • Locatário - Esta configuração é o padrão. O uso dessa configuração permite que vários aplicativos e fluxos de usuários em seu locatário B2C compartilhem a mesma sessão de usuário. Por exemplo, uma vez que um usuário entra em um aplicativo, o usuário também pode entrar perfeitamente em outro ao acessá-lo.
    • Aplicação - Esta definição permite-lhe manter uma sessão de utilizador exclusivamente para uma aplicação, independentemente de outras aplicações. Por exemplo, você pode usar essa configuração se quiser que o usuário entre na Contoso Pharmacy, independentemente de o usuário já estar conectado à Contoso Groceries.
    • Política - Esta configuração permite que você mantenha uma sessão de usuário exclusivamente para um fluxo de usuário, independentemente dos aplicativos que a utilizam. Por exemplo, o Azure AD B2C concede ao usuário acesso a partes de segurança mais alta de vários aplicativos se o usuário já tiver entrado e concluído uma etapa de autenticação multifator (MFA). Esse acesso continua enquanto a sessão associada ao fluxo de usuário permanecer ativa.
    • Suprimido - Essa configuração força o usuário a executar todo o fluxo de usuários em cada execução da política.

Configurar o fluxo do usuário

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

  1. Inicie sessão no portal Azure.
  2. Se tiver acesso a vários inquilinos, selecione o ícone Definições no menu superior para mudar para o inquilino do Azure AD B2C no menu Diretórios + subscrições.
  3. Escolha Todos os serviços no canto superior esquerdo do portal do Azure e, em seguida, procure e selecione Azure AD B2C.
  4. Selecione Fluxos de usuário.
  5. Abra o fluxo de usuário que você criou anteriormente.
  6. Selecione Propriedades.
  7. Configure o tempo de vida da sessão da aplicação web (minutos), o tempo limite da sessão da aplicação web, a configuração de início de sessão único e requerer o token de identificação nas solicitações de terminação de sessão conforme necessário.
  8. Selecione Guardar.

Configurar a política personalizada

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

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

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

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

    Depois de adicionar os elementos de comportamento da jornada do usuário, o RelyingParty elemento deve se parecer com o exemplo a seguir:

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

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

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

Ativar Manter-me conectado (KMSI)

Você pode habilitar o recurso KMSI para usuários de seus aplicativos Web e nativos que têm contas locais no diretório do Azure AD B2C. Quando você ativa o recurso, os usuários podem optar por permanecer conectados para que a sessão permaneça ativa depois de fechar o navegador. A sessão é mantida através da definição de um cookie persistente. Os usuários que selecionam KMSI, podem reabrir o navegador sem serem solicitados a redigitar seu nome de usuário e senha. Este acesso (cookie persistente) é revogado quando um utilizador termina sessão. Para mais informações, consulte a demonstração ao vivo.

Exemplo de página de registo e início de sessão com uma caixa de verificação Manter-me ligado

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

  • O KMSI é suportado apenas para as versões recomendadas de fluxos de usuário de inscrição e entrada (SUSI), entrada e edição de perfil. Se você tiver versões Standard (Legacy) ou Legacy preview - v2 desses fluxos de usuário e quiser habilitar o KMSI, precisará criar novas versões recomendadas desses fluxos de usuário.
  • O KMSI não é suportado nos fluxos de redefinição de senha ou inscrição de utilizador.
  • Se você quiser habilitar o KMSI para todos os aplicativos em seu locatário, recomendamos que habilite o KMSI para todos os fluxos de usuários em seu locatário. Como um usuário pode receber várias políticas durante uma sessão, é possível que ele encontre uma que não tenha o KMSI habilitado, o que removeria o cookie KMSI da sessão.
  • O KMSI não deve ser ativado em computadores públicos.

Configurar KMSI para um fluxo de usuário

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

  1. Inicie sessão no portal Azure.

  2. Se tiver acesso a vários inquilinos, selecione o ícone Definições no menu superior para mudar para o inquilino do Azure AD B2C no menu Diretórios + subscrições.

  3. Escolha Todos os serviços no canto superior esquerdo do portal do Azure e, em seguida, procure e selecione Azure AD B2C.

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

  5. Abra o fluxo de usuário que você criou anteriormente.

  6. Selecione Propriedades.

  7. Em Comportamento da sessão, selecione Ativar 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.

    Ativar manter-me conectado na sessão

Os utilizadores não devem ativar esta opção em computadores públicos.

Configurar o identificador de página

Para habilitar o KMSI, defina o elemento de definição DataUri de conteúdo como identificadorunifiedssp de página e versão de 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 inicial de política personalizada, que você obtém no pré-requisito, Introdução às políticas personalizadas.

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

  3. Adicione o elemento ContentDefinitions ao elemento BuildingBlocks da política.

    A sua política personalizada deve assemelhar-se ao seguinte trecho 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 registo e início de sessão, defina os setting.enableRememberMe metadados como "true". Substitua os perfis técnicos SelfAsserted-LocalAccountSignin-Email no arquivo de extensão.

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

  2. Adicione o seguinte provedor 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.

Configurar um arquivo de terceira parte confiável

Atualize o ficheiro da parte confiável (RP) que inicia a jornada do utilizador que você criou. O keepAliveInDays parâmetro permite configurar por quanto tempo o cookie de sessão keep me signed in (KMSI) deve persistir. Por exemplo, se você definir o valor como 30, o cookie de sessão KMSI persistirá por 30 dias. O intervalo para o valor é de 1 a 90 dias. Definir o valor como 0 desativa a funcionalidade KMSI.

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

  2. Se ainda não existir, adicione um nó filho <UserJourneyBehaviors> ao nó <RelyingParty>. Deve localizar-se imediatamente a seguir <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 um login, se um usuário habilitar KMSI, o KeepAliveInDays seja usado para definir os cookies, caso contrário, o valor especificado no parâmetro SessionExpiryInSeconds será usado. Recomendamos que você defina o valor de SessionExpiryInSeconds como 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>

Terminar sessão

Quando você deseja desconectar o usuário do aplicativo, não é suficiente limpar os cookies do aplicativo ou encerrar a sessão com o usuário. Você deve redirecionar o usuário para o Azure AD B2C para sair. Caso contrário, o usuário poderá se autenticar novamente em seus aplicativos sem inserir suas credenciais novamente.

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. Tentativas de sair dos provedores de identidade federada.
  1. Invalida a sessão baseada em cookies do Azure AD B2C.
  2. Tentativas de sair de sistemas de identidade federada:
    • OpenId Connect - Se o ponto de extremidade de configuração conhecido do provedor de identidade especificar uma end_session_endpoint localização. A solicitação de saída não passa o parâmetro id_token_hint. 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 incluírem a end_session_endpoint localização.
    • SAML - Se os metadados do provedor de identidade contiverem a SingleLogoutService localização.
  3. Opcionalmente, sai de outros aplicativos. Para obter mais informações, consulte a seção Saída única .

Observação

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

A saída limpa o estado de logon único do usuário com o Azure AD B2C, mas pode não desconectar o usuário da sessão do provedor de identidade social. Se o usuário selecionar o mesmo provedor de identidade durante uma entrada subsequente, ele poderá se autenticar novamente sem inserir suas credenciais. Se um usuário quiser sair do aplicativo, isso não significa necessariamente que ele deseja sair de sua conta do Facebook. No entanto, se forem usadas contas locais, a sessão do usuário termina corretamente.

Terminação única de sessão

Quando redireciona o utilizador para o ponto de extremidade de saída do Azure AD B2C (para OAuth2 e OpenID Connect) ou envia um LogoutRequest (para SAML), o Azure AD B2C elimina a sessão do utilizador no navegador. No entanto, o usuário ainda pode estar conectado a 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 dá suporte à saída única, também conhecida como SLO (Single Log-Out).

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

Configurar sua política personalizada

Para oferecer suporte à saída única, os perfis técnicos do emissor de 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 ilustra os emissores de token JWT e SAML com logout único:

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

Configurar a aplicação

Para que uma candidatura participe no single sign-out:

  • Para fornecedores de serviços SAML, configure a aplicação com a localização SingleLogoutService no seu documento de metadados SAML. Você também pode configurar o registro do aplicativo logoutUrl. Para obter mais informações, consulte definir o URL de logout.
  • Para aplicações OpenID Connect ou OAuth2, defina o atributo do manifesto logoutUrl de registo da aplicação. Para configurar o URL de logout:
    1. No menu Azure AD B2C, selecione Registros de aplicativos.
    2. Selecione o seu registo de candidatura.
    3. Em Gerir, selecione Autenticação.
    4. No URL de logout do canal Front, configure o URL de logout.

Tratamento de pedidos de encerramento de sessão único

Quando o Azure AD B2C recebe a solicitação de logout, ele usa um iframe HTML de canal frontal para enviar uma solicitação HTTP para a URL de logout registrada de cada aplicativo participante no qual o usuário está conectado no momento. Observe que o aplicativo que dispara a solicitação de saída recebe essa mensagem de logout. Seus aplicativos devem responder à solicitação de saída 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 logout registrada.
  • Para aplicações SAML, o Azure AD B2C envia uma solicitação de encerramento de sessão SAML para o URL de encerramento de sessão registado.

Quando o Azure AD B2C notifica todos os aplicativos sobre a saída, ele prossegue com um dos seguintes procedimentos:

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

Proteja o redirecionamento de logout

Após o logout, o usuário é redirecionado para o URI especificado no post_logout_redirect_uri parâmetro, independentemente das URLs de resposta especificadas para o aplicativo. No entanto, se um válido id_token_hint for passado e o Exigir Token de ID 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 tiver sido 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. Inicie sessão no portal Azure.
  2. Se tiver acesso a vários inquilinos, selecione o ícone Definições no menu superior para mudar para o inquilino do Azure AD B2C no menu Diretórios + subscrições.
  3. Escolha Todos os serviços no canto superior esquerdo do portal do Azure e, em seguida, procure e selecione Azure AD B2C.
  4. Selecione Fluxos de usuário.
  5. Abra o fluxo de usuário que você criou anteriormente.
  6. Selecione Propriedades.
  7. Habilite o Exigir 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 o EnforceIdTokenHintOnLogout do elemento SingleSignOn como true. Para mais informações, consulte a demonstração ao vivo. Seu elemento UserJourneyBehaviors deve se parecer com este exemplo:

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

Para configurar o URL de logout do aplicativo:

  1. Selecione Registos de aplicações e, em seguida, selecione a sua aplicação.
  2. Selecione Autenticação.
  3. Na caixa de texto URL de terminar sessão, digite o URI de redirecionamento após terminar sessão e selecione Guardar.

Conteúdo relacionado

  • Last updated on