Partilhar via

Iniciar sessão na Web com OpenID Connect no Azure Ative Directory B2C

  • Artigo

O OpenID Connect é um protocolo de autenticação, construído sobre o OAuth 2.0, que pode ser usado para conectar usuários com segurança a aplicativos da Web. Usando a implementação do Azure Ative Directory B2C (Azure AD B2C) do OpenID Connect, você pode terceirizar a inscrição, o logon e outras experiências de gerenciamento de identidade em seus aplicativos Web para o Microsoft Entra ID. Este guia mostra-lhe como fazê-lo de uma forma independente da língua. Ele descreve como enviar e receber mensagens HTTP sem usar nenhuma de nossas bibliotecas de código aberto.

Nota

A maioria das bibliotecas de autenticação de código aberto adquire e valida os tokens JWT para seu aplicativo. Recomendamos explorar essas opções, em vez de implementar seu próprio código. Para obter mais informações, consulte Visão geral da Microsoft Authentication Library (MSAL) e Microsoft Identity Web authentication library.

O OpenID Connect estende o protocolo de autorização OAuth 2.0 para uso como um protocolo de autenticação. Esse protocolo de autenticação permite que você execute o logon único. Ele introduz o conceito de um token de ID, que permite ao cliente verificar a identidade do usuário e obter informações básicas de perfil sobre o usuário.

O OpenID Connect também permite que os aplicativos adquiram tokens de acesso com segurança. Você pode usar tokens de acesso para acessar recursos que o servidor de autorização protege. Recomendamos o OpenID Connect se você estiver criando um aplicativo da Web que hospeda em um servidor e acessado por meio de um navegador. Para obter mais informações sobre tokens, consulte Visão geral de tokens no Azure Ative Directory B2C

O Azure AD B2C estende o protocolo padrão OpenID Connect para fazer mais do que simples autenticação e autorização. Ele introduz o parâmetro de fluxo de usuário, que permite que você use o OpenID Connect para adicionar experiências de usuário ao seu aplicativo, como inscrição, login e gerenciamento de perfil.

Enviar pedidos de autenticação

Quando seu aplicativo Web precisa autenticar o usuário e executar um fluxo de usuário, ele pode direcionar o usuário para o /authorize ponto de extremidade. O usuário executa uma ação dependendo do fluxo do usuário.

Nessa solicitação, o cliente indica as permissões que precisa adquirir do usuário no scope parâmetro e especifica o fluxo de usuário a ser executado. Para ter uma ideia de como a solicitação funciona, cole-a em seu navegador e execute-a. Substituir:

  • {tenant} com o nome do seu inquilino.
  • 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 com o ID da aplicação de uma aplicação que registou no seu inquilino.
  • {application-id-uri}/{scope-name} com o URI da ID do Aplicativo e o escopo de um aplicativo que você registrou em seu locatário.
  • {policy} com o nome da política que você tem em seu locatário, por exemplo b2c_1_sign_in.
GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com

client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
Parâmetro Obrigatório Description
{inquilino} Sim Nome do seu locatário do Azure AD B2C. Se estiver a utilizar um domínio personalizado, substitua tenant.b2clogin.com pelo seu domínio, como fabrikam.com.
{política} Sim O fluxo de usuário ou a política que o aplicativo executa. Especifique o nome de um fluxo de usuário que você cria em seu locatário do Azure AD B2C. Por exemplo: b2c_1_sign_in, b2c_1_sign_up, ou b2c_1_edit_profile.
client_id Sim A ID do aplicativo que o portal do Azure atribuiu ao seu aplicativo.
nonce Sim Um valor incluído na solicitação (gerada pelo aplicativo) que é incluído no token de ID resultante como uma declaração. O aplicativo pode então verificar esse valor para mitigar ataques de repetição de token. O valor é normalmente uma cadeia de caracteres exclusiva aleatória que pode ser usada para identificar a origem da solicitação.
response_type Sim Deve incluir um token de ID para o OpenID Connect. Se seu aplicativo Web também precisar de tokens para chamar uma API da Web, você poderá usar code+id_tokeno .
âmbito Sim Uma lista de escopos separados por espaços. O openid escopo indica uma permissão para entrar no usuário e obter dados sobre o usuário na forma de tokens de ID. O offline_access escopo é opcional para aplicativos Web. Ele indica que seu aplicativo precisa de um token de atualização para acesso estendido aos recursos. O https://{tenant-name}/{app-id-uri}/{scope} indica uma permissão para recursos protegidos, como uma API da Web. Para obter mais informações, consulte Solicitar um token de acesso.
Prompt Não O tipo de interação do usuário que você precisa. O único valor válido no momento é login, que força o usuário a inserir suas credenciais nessa solicitação.
redirect_uri Sim O redirect_uri parâmetro do seu aplicativo, onde o servidor envia respostas de autenticação para o seu aplicativo. Ele deve corresponder exatamente a redirect_uri um dos parâmetros que você registrou no portal do Azure, exceto que ele deve ser codificado por URL.
response_mode Não O método que é usado para enviar o código de autorização resultante de volta para o seu aplicativo. Pode ser , queryform_postou fragment. Recomendamos que você use o modo de form_post resposta para melhor segurança.
state Não Um valor que você pode incluir na solicitação que o servidor de autorização retorna na resposta do token. Pode ser uma sequência de qualquer conteúdo que você quiser. Um valor exclusivo gerado aleatoriamente é normalmente usado para evitar ataques de falsificação de solicitação entre sites. O estado também é usado para codificar informações sobre o estado do usuário no aplicativo antes da solicitação de autenticação ocorrer, como a página em que eles estavam. Se você não quiser registrar várias URLs de redirecionamento em seu portal do Azure, poderá usar o parâmetro para diferenciar as state respostas em seu aplicativo do serviço Azure AD B2C devido a solicitações diferentes.
login_hint Não Pode ser utilizado para pré-preencher o campo de nome de início de sessão da página de início de sessão. Para obter mais informações, consulte Pré-preencher o nome de entrada.
domain_hint Não Fornece uma dica para o Azure AD B2C sobre o provedor de identidade social que deve ser usado para entrar. Se um valor válido for incluído, o usuário irá diretamente para a página de entrada do provedor de identidade. Para obter mais informações, consulte Redirecionar o login para um provedor social.
Parâmetros personalizados Não Parâmetros personalizados que podem ser usados com políticas personalizadas. Por exemplo, URI dinâmico de conteúdo de página personalizada ou resolvedores de declaração de chave-valor.

Neste ponto, o usuário é solicitado a concluir o fluxo de trabalho. O usuário pode ter que digitar seu nome de usuário e senha, entrar com uma identidade social ou se inscrever no diretório. Pode haver qualquer outro número de etapas, dependendo de como o fluxo do usuário é definido.

Depois que o usuário conclui o fluxo de usuário, uma resposta é retornada ao seu aplicativo no parâmetro indicado redirect_uri , usando o método especificado no response_mode parâmetro. A resposta é a mesma para cada um dos casos anteriores, independentemente do fluxo de usuários.

Uma resposta bem-sucedida usando response_mode=fragment seria semelhante a:

GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response
Parâmetro Description
id_token O token de ID que o aplicativo solicitou. Você pode usar o token de ID para verificar a identidade do usuário e iniciar uma sessão com o usuário.
code O código de autorização que o aplicativo solicitou, se você usou response_type=code+id_token. O aplicativo pode usar o código de autorização para solicitar um token de acesso para um recurso de destino. Os códigos de autorização normalmente expiram após cerca de 10 minutos.
state Se um state parâmetro for incluído na solicitação, o mesmo valor deverá aparecer na resposta. O aplicativo deve verificar se os state valores na solicitação e na resposta são idênticos.

As respostas de erro também podem ser enviadas para o parâmetro para que o redirect_uri aplicativo possa manipulá-las adequadamente:

GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response
Parâmetro Description
erro Um código que pode ser usado para classificar os tipos de erros que ocorrem.
error_description Uma mensagem de erro específica que pode ajudar a identificar a causa raiz de um erro de autenticação.
state Se um state parâmetro for incluído na solicitação, o mesmo valor deverá aparecer na resposta. O aplicativo deve verificar se os state valores na solicitação e na resposta são idênticos.

Validar o token de ID

Apenas receber um token de ID não é suficiente para autenticar o usuário. Valide a assinatura do token de ID e verifique as declarações no token de acordo com os requisitos do seu aplicativo. O Azure AD B2C usa JSON Web Tokens (JWTs) e criptografia de chave pública para assinar tokens e verificar se eles são válidos.

Nota

A maioria das bibliotecas de autenticação de código aberto valida os tokens JWT para seu aplicativo. Recomendamos explorar essas opções, em vez de implementar sua própria lógica de validação. Para obter mais informações, consulte Visão geral da Microsoft Authentication Library (MSAL) e Microsoft Identity Web authentication library.

O Azure AD B2C tem um ponto de extremidade de metadados do OpenID Connect, que permite que um aplicativo obtenha informações sobre o Azure AD B2C em tempo de execução. Essas informações incluem pontos de extremidade, conteúdo de token e chaves de assinatura de token. Há um documento de metadados JSON para cada fluxo de usuário em seu locatário B2C. Por exemplo, o documento de metadados para o b2c_1_sign_in fluxo de usuário está localizado em fabrikamb2c.onmicrosoft.com :

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration

Uma das propriedades deste documento de configuração é jwks_uri, cujo valor para o mesmo fluxo de usuário seria:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys

Para determinar qual fluxo de usuário foi usado para assinar um token de ID, você tem duas opções. Primeiro, o nome do fluxo de usuário é incluído na declaração no token de ID, consulte declaração que representa o fluxo do acrusuário. Sua outra opção é codificar o fluxo de usuário no valor do parâmetro quando você emitir a solicitação e, em seguida, decodificá-lo para determinar qual fluxo de state usuário foi usado. Qualquer um dos métodos é válido.

Depois de adquirir o documento de metadados do ponto de extremidade de metadados do OpenID Connect, você pode usar as chaves públicas RSA 256 para validar a assinatura do token de ID. Pode haver várias chaves listadas neste ponto de extremidade, cada uma identificada por uma kid declaração. O cabeçalho do token de ID também contém uma kid declaração, que indica qual dessas chaves foi usada para assinar o token de ID.

Para verificar os tokens do Azure AD B2C, você precisa gerar a chave pública usando o expoente(e) e o módulo(n). Para fazer isso, você precisa aprender a gerar a chave pública em uma linguagem de programação de sua escolha. A documentação oficial sobre a geração de Chave Pública com o protocolo RSA pode ser encontrada aqui: https://tools.ietf.org/html/rfc3447#section-3.1

Depois de validar a assinatura do token de ID, há várias declarações que você precisa verificar. Por exemplo:

  • Valide a declaração para evitar ataques de repetição de nonce token. Seu valor deve ser o que você especificou na solicitação de entrada.
  • Valide a aud declaração para garantir que o token de ID foi emitido para seu aplicativo. Seu valor deve ser o ID do aplicativo do seu aplicativo.
  • Valide as iat declarações e exp para certificar-se de que o token de ID não expirou.

Há também várias outras validações que você deve realizar. As validações são descritas em detalhes na especificação principal do OpenID Connect. Você também pode querer validar mais declarações, dependendo do seu cenário. Algumas validações comuns incluem:

  • Certifique-se de que o usuário/organização se inscreveu no aplicativo.
  • Certifique-se de que o usuário tem autorização/privilégios adequados.
  • Verifique se ocorreu uma determinada força de autenticação, como a autenticação multifator do Microsoft Entra.

Depois que o token de ID for validado, você poderá iniciar uma sessão com o usuário. Você pode usar as declarações no token de ID para obter informações sobre o usuário em seu aplicativo. Os usos para essas informações incluem exibição, registros e autorização.

Obter um token

Se você precisar que seu aplicativo Web execute apenas fluxos de usuário, poderá ignorar as próximas seções. Essas seções são aplicáveis somente a aplicativos Web que precisam fazer chamadas autenticadas para uma API da Web, que é protegida pelo próprio Azure AD B2C.

Você pode resgatar o código de autorização adquirido (usando response_type=code+id_token) por um token para o recurso desejado enviando uma POST solicitação para o /token ponto de extremidade. No Azure AD B2C, você pode solicitar tokens de acesso para outras APIs como de costume, especificando o(s) seu(s) escopo(s) na solicitação.

Você também pode solicitar um token de acesso para a API Web back-end do seu aplicativo. Nesse caso, você usa o ID do cliente do aplicativo como o escopo solicitado, o que resulta em um token de acesso com esse ID do cliente como "público-alvo":

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parâmetro Obrigatório Description
{inquilino} Sim Nome do locatário do Azure AD B2C
{política} Sim O fluxo de usuário que foi usado para adquirir o código de autorização. Não é possível usar um fluxo de usuário diferente nessa solicitação. Adicione esse parâmetro à cadeia de caracteres de consulta, não ao corpo do POST.
client_id Sim A ID do aplicativo que o portal do Azure atribuiu ao seu aplicativo.
client_secret Sim, em Aplicações Web O segredo do aplicativo que foi gerado no portal do Azure. Os segredos do cliente são usados nesse fluxo para cenários de aplicativo Web, onde o cliente pode armazenar com segurança um segredo do cliente. Para cenários de aplicativo nativo (cliente público), os segredos do cliente não podem ser armazenados com segurança, portanto, não são usados nesse fluxo. Se estiver usando um segredo do cliente, altere-o periodicamente.
code Sim O código de autorização que você adquiriu no início do fluxo de usuário.
grant_type Sim O tipo de concessão, que deve ser authorization_code para o fluxo de código de autorização.
redirect_uri Não O redirect_uri parâmetro do aplicativo onde você recebeu o código de autorização.
âmbito Não Uma lista de escopos separados por espaços. O openid escopo indica uma permissão para entrar no usuário e obter dados sobre o usuário na forma de parâmetros id_token. Ele pode ser usado para obter tokens para a própria API da Web de back-end do seu aplicativo, que é representada pelo mesmo ID do aplicativo que o cliente. O offline_access escopo indica que seu aplicativo precisa de um token de atualização para acesso estendido aos recursos.

Uma resposta de token bem-sucedida se parece com:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parâmetro Description
not_before A época em que o token se torna válido.
token_type O valor do tipo de token. Bearer é o único tipo suportado.
access_token O token JWT assinado que você solicitou.
âmbito Os escopos válidos para o token.
expires_in O período de tempo em que o token de acesso é válido (em segundos).
expires_on A época em que o token de acesso se torna inválido.
refresh_token Um token de atualização OAuth 2.0. O aplicativo pode usar esse token para adquirir mais tokens depois que o token atual expirar. Os tokens de atualização podem ser usados para manter o acesso aos recursos por longos períodos de tempo. O escopo offline_access deve ter sido usado nas solicitações de autorização e token para receber um token de atualização.

As respostas de erro são parecidas:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}
Parâmetro Description
erro Um código que pode ser usado para classificar tipos de erros que ocorrem.
error_description Uma mensagem que pode ajudar a identificar a causa raiz de um erro de autenticação.

Use o token

Depois de adquirir com êxito um token de acesso, você pode usá-lo em solicitações para suas APIs da Web de back-end incluindo-o Authorization no cabeçalho:

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Atualizar o token

Os tokens de acesso e os tokens de ID têm vida curta. Depois que eles expirarem, você deve atualizá-los para continuar a acessar recursos. Quando você atualiza o token de acesso, o Azure AD B2C retorna um novo token. O token de acesso atualizado terá valores de declaração atualizados nbf (não antes), iat (emitidos em) e exp (expiração). Todos os outros valores de declaração são semelhantes aos do token de acesso anterior.

Atualize um token enviando outra POST solicitação para o /token ponto de extremidade. Desta vez, forneça o refresh_token parâmetro em vez do code parâmetro:

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parâmetro Obrigatório Description
{inquilino} Sim Nome do locatário do Azure AD B2C
{política} Sim O fluxo de usuário que foi usado para adquirir o token de atualização original. Não é possível usar um fluxo de usuário diferente nessa solicitação. Adicione esse parâmetro à cadeia de caracteres de consulta, não ao corpo do POST.
client_id Sim A ID do aplicativo que o portal do Azure atribuiu ao seu aplicativo.
client_secret Sim, em Aplicações Web O segredo do aplicativo que foi gerado no portal do Azure. Os segredos do cliente são usados nesse fluxo para cenários de aplicativo Web, onde o cliente pode armazenar com segurança um segredo do cliente. Para cenários de aplicativo nativo (cliente público), os segredos do cliente não podem ser armazenados com segurança, portanto, não são usados nesta chamada. Se estiver usando um segredo do cliente, altere-o periodicamente.
grant_type Sim O tipo de concessão, que deve ser refresh_token para esta parte do fluxo de código de autorização.
refresh_token Sim O token de atualização original que foi adquirido na segunda parte do fluxo. O offline_access escopo deve ser usado nas solicitações de autorização e token para receber um token de atualização.
redirect_uri Não O redirect_uri parâmetro do aplicativo onde você recebeu o código de autorização.
âmbito Não Uma lista de escopos separados por espaços. O openid escopo indica uma permissão para entrar no usuário e obter dados sobre o usuário na forma de tokens de ID. Ele pode ser usado para enviar tokens para a própria API da Web de back-end do seu aplicativo, que é representada pelo mesmo ID do aplicativo que o cliente. O offline_access escopo indica que seu aplicativo precisa de um token de atualização para acesso estendido aos recursos.

Uma resposta de token bem-sucedida se parece com:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
    "refresh_token_expires_in": "1209600"
}
Parâmetro Description
not_before A época em que o token se torna válido.
token_type O valor do tipo de token. Bearer é o único tipo suportado.
access_token O token JWT assinado que foi solicitado.
âmbito Os escopos válidos para o token.
expires_in O período de tempo em que o token de acesso é válido (em segundos).
refresh_token Um token de atualização OAuth 2.0. O aplicativo pode usar esse token para adquirir tokens adicionais depois que o token atual expirar. Os tokens de atualização podem ser usados para manter o acesso aos recursos por longos períodos de tempo.
refresh_token_expires_in O período de tempo em que o token de atualização é válido (em segundos).

As respostas de erro são parecidas:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}
Parâmetro Description
erro Um código que pode ser usado para classificar tipos de erros que ocorrem.
error_description Uma mensagem que pode ajudar a identificar a causa raiz de um erro de autenticação.

Enviar uma solicitação de saída

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. Redirecionar o usuário para o Azure AD B2C para sair. Se você não fizer isso, o usuário poderá se autenticar novamente em seu aplicativo sem inserir suas credenciais novamente. Para obter mais informações, consulte Comportamento de sessão do Azure AD B2C.

Para sair do usuário, redirecione-o para o end_session_endpoint que está listado no documento de metadados do OpenID Connect descrito anteriormente:

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F
Parâmetro Obrigatório Description
{inquilino} Sim Nome do seu locatário do Azure AD B2C. Se você estiver usando um domínio personalizado, substitua tenant.b2clogin.com pelo seu domínio, como fabrikam.com.
{política} Sim O fluxo de usuário especificado na solicitação de autorização. Por exemplo, se o usuário entrou com o fluxo de b2c_1_sign_in usuário, especifique b2c_1_sign_in na solicitação de saída.
id_token_hint Não Um token de ID emitido anteriormente para passar para o ponto de extremidade de logout como uma dica sobre a sessão autenticada atual do usuário final com o cliente. O id_token_hint garante que o post_logout_redirect_uri é uma URL de resposta registrada em suas configurações de aplicativo do Azure AD B2C. Para obter mais informações, consulte Proteger o redirecionamento de logout.
client_id Não* A ID do aplicativo que o portal do Azure atribuiu ao seu aplicativo.

*Isso é necessário ao usar Application a configuração de SSO de isolamento e Exigir Token de ID na solicitação de logout é definido como No.
post_logout_redirect_uri Não A URL para a qual o usuário deve ser redirecionado após o logout bem-sucedido. Se não estiver incluído, o Azure AD B2C mostrará ao usuário uma mensagem genérica. A menos que forneça um , não deve registar este URL como um id_token_hintURL de resposta nas definições da aplicação Azure AD B2C.
state Não Se você incluir um state parâmetro na solicitação de autorização, o servidor de autorização retornará o mesmo valor na resposta ao post_logout_redirect_uri. O aplicativo deve verificar se o state valor na solicitação e na resposta são idênticos.

Após uma solicitação de saída, o Azure AD B2C invalida a sessão baseada em cookies do Azure AD B2C e tenta sair de provedores de identidade federados. Para obter mais informações, consulte Saída única.

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 definir o Token de ID necessário em solicitações de logout, consulte Configurar o comportamento da sessão no Azure Ative Directory B2C.

Próximos passos

  • Saiba mais sobre a sessão B2C do Azure AD.