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

Artigo
11/20/2023

Antes de começar, use o seletor Escolha um tipo de política 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.

Pré-requisitos

Crie um fluxo de usuários para que os usuários possam se inscrever e entrar em seu aplicativo.
Registe uma aplicação Web.

Conclua as etapas em Introdução às políticas personalizadas no Ative Directory B2C
Registe uma aplicação 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, conta do Facebook, Salesforce ou Microsoft
Aplicação - Sessão gerida pela Web, telemóvel ou aplicação de página única

SSO session

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 sob o nome de domínio do locatário do 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 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:

Um utilizador inicia sessão no Facebook para verificar o respetivo feed.
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.
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, token de ID ou token SAML pode proteger um aplicativo da 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 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).
- Rolagem - Indica que a sessão é estendida sempre que o usuário executa uma autenticação baseada em cookie (padrã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:

Inicie sessão no portal do Azure.
Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para seu locatário do Azure AD B2C no menu Diretórios + assinaturas .
Escolha Todos os serviços no canto superior esquerdo do portal do Azure e, em seguida, procure e selecione Azure AD B2C.
Selecione Fluxos de usuário.
Abra o fluxo de usuário que você criou anteriormente.
Selecione Propriedades.
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 único e Exigir Token de ID em solicitações de logout, conforme necessário.
Clique em Guardar.

Configurar a política personalizada

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

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

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 elemento deve se parecer com o RelyingParty 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>

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

Example sign-up sign-in page showing a Keep me signed in checkbox

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 com fluxos de usuário de redefinição de senha ou inscrição.
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:

Inicie sessão no portal do Azure.
Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para seu locatário do Azure AD B2C no menu Diretórios + assinaturas .
Escolha Todos os serviços no canto superior esquerdo do portal do Azure e, em seguida, procure e selecione Azure AD B2C.
Selecione Fluxos de usuário (políticas).
Abra o fluxo de usuário que você criou anteriormente.
Selecione Propriedades.
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.

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ãode página 1.1.0 ou superior.

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.
Procure o elemento BuildingBlocks . Se o elemento não existir, adicione-o.

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

Sua política personalizada deve se parecer com o 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 inscrição e entrada, defina os setting.enableRememberMe metadados como true. Substitua os perfis técnicos SelfAsserted-LocalAccountSignin-Email no arquivo de extensão.

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

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>

Salve o arquivo de extensões.

Configurar um arquivo de terceira parte confiável

Atualize o arquivo de terceira parte confiável (RP) que inicia a jornada do usuário 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.

Abra o arquivo de política personalizado. Por exemplo, SignUpOrSignin.xml.
Se ainda não existir, adicione um <UserJourneyBehaviors> nó filho ao <RelyingParty> nó. Deve localizar-se imediatamente a seguir <DefaultUserJourney ReferenceId="User journey Id" />, por exemplo: <DefaultUserJourney ReferenceId="SignUpOrSignIn" />.

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

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

Invalida a sessão baseada em cookies do Azure AD B2C.
Tenta sair de provedores de identidade federada.

Invalida a sessão baseada em cookies do Azure AD B2C.
Tentativas de sair de provedores de identidade federada:
- OpenId Connect - Se o ponto de extremidade de configuração 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.
Opcionalmente, sai de outros aplicativos. Para obter mais informações, consulte a seção Saída única.

Nota

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.

Fim de sessão único

Quando você redireciona o usuário 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 limpa a sessão do usuário do 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 saída única:

<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 a aplicação

Para que uma candidatura participe no single sign-out:

Para provedores de serviços SAML, configure o aplicativo com o local SingleLogoutService em seu documento de metadados SAML. Você também pode configurar o registro logoutUrldo aplicativo . Para obter mais informações, consulte definir o URL de logout.
Para aplicativos OpenID Connect ou OAuth2, defina o atributo do manifesto logoutUrl de registro do aplicativo. 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.

Processar pedidos de fim 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 aplicativos SAML, o Azure AD B2C envia uma solicitação de logout SAML para a URL de logout registrada.

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 seu 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 corresponde a um dos URIs de redirecionamento configurados do aplicativo antes de post_logout_redirect_uri 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:

Inicie sessão no portal do Azure.
Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para seu locatário do Azure AD B2C no menu Diretórios + assinaturas .
Escolha Todos os serviços no canto superior esquerdo do portal do Azure e, em seguida, procure e selecione Azure AD B2C.
Selecione Fluxos de usuário.
Abra o fluxo de usuário que você criou anteriormente.
Selecione Propriedades.
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:

Selecione Registos de aplicações e, em seguida, selecione a sua aplicação.
Selecione Autenticação.
Na caixa de texto URL de logout, digite o URI de redirecionamento de logout e selecione Salvar.

Próximos passos

Saiba como configurar tokens no Azure AD B2C.

Partilhar via