Credenciais da Web com OpenID Connect - Azure AD B2C

2025-06-23

Importante

A partir de 1º de maio de 2025, o Azure AD B2C não estará mais disponível para compra para novos clientes. Saiba mais em nossas perguntas frequentes.

O OpenID Connect é um protocolo de autenticação, criado com base no OAuth 2.0, que pode ser usado para conectar usuários com segurança a aplicativos Web. Ao usar a implementação do Azure Active Directory B2C (Azure AD B2C) do OpenID Connect, você pode terceirizar o registro, o login e outras experiências de gerenciamento de identidade em suas aplicações web para o Microsoft Entra ID. Este guia mostra como fazer isso de maneira independente da linguagem. Ele descreve como enviar e receber mensagens HTTP sem usar nenhuma de nossas bibliotecas de software livre.

Observação

A maioria das bibliotecas de autenticação de software livre adquire e valida os JWTs 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 MSAL (Biblioteca de Autenticação da Microsoft) e da biblioteca de autenticação da Microsoft Identity Web.

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 apresenta o conceito de um token de ID, que permite que o cliente verifique a identidade do usuário e obtenha 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 Web hospedado em um servidor e acessado por meio de um navegador. Para obter mais informações sobre tokens, consulte a visão geral dos tokens no Azure Active Directory B2C

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

Enviar solicitações 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 toma medidas dependendo do fluxo do usuário.

Nesta 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 solicitação no navegador e execute-a. Substituir:

{tenant} pelo nome do seu locatário.
00001111-aaaa-2222-bbbb-3333cccc4444 pela ID de um aplicativo que você registrou no seu locatário.
{application-id-uri}/{scope-name} pelo URI da ID de aplicativo e o escopo de um aplicativo que você registrou anteriormente no seu locatário.
{policy} pelo nome da política que você tem no seu locatário, por exemplo b2c_1_sign_in.

GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&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	Descrição
{inquilino}	Sim	O nome de seu locatário do Azure AD B2C. Se você estiver usando um domínio personalizado, substitua `tenant.b2clogin.com` por seu domínio, como `fabrikam.com`.
{política}	Sim	O fluxo de usuário ou a política executada pelo aplicativo. 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`.
ID do cliente	Sim	A ID do aplicativo que o portal do Azure atribuiu ao seu aplicativo.
Nonce	Recomendado	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 verificar esse valor para reduzir os ataques de reprodução de token. O valor normalmente é uma cadeia de caracteres exclusiva aleatória que pode ser usada para identificar a origem da solicitação.
tipo_de_resposta	Sim	Deve incluir um token de ID para OpenID Connect. Se seu aplicativo Web também precisar de tokens para chamar uma API Web, você poderá usar `code+id_token`.
âmbito	Sim	Uma lista separada por espaços de âmbitos. O escopo `openid` indica uma permissão para entrar no usuário e obter dados sobre ele na forma de tokens de ID. O escopo `offline_access` é opcional para aplicativos Web. 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 os recursos protegidos, como uma API Web. Para obter mais informações, consulte Solicitar um token de acesso.
solicitação	Não	O tipo de interação do usuário que você precisa. O único valor válido neste momento é `login`, o que força o usuário a inserir suas credenciais nessa solicitação.
URI de redirecionamento	Sim	O `redirect_uri` parâmetro do seu aplicativo, em que o servidor envia respostas de autenticação para 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 em URL.
modo_de_resposta	Não	O método usado para enviar o código de autorização resultante de volta para seu aplicativo. Pode ser `query`, `form_post`ou `fragment`. Recomendamos que você use o `form_post` modo de resposta para melhor segurança.
estado	Não	Um valor que você pode incluir na solicitação para que o servidor de autorização o retorne na resposta do token. Pode ser uma cadeia de caracteres de qualquer conteúdo desejado. 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 ele estava. Se você não quiser registrar várias URLs de redirecionamento no portal do Azure, poderá usar o `state` parâmetro para diferenciar respostas em seu aplicativo do serviço do Azure AD B2C devido a solicitações diferentes.
login_hint	Não	Pode ser usado para preencher previamente o campo do nome de entrada da página de entrada. Para obter mais informações, consulte Pré-preencher o nome de entrada.
domain_hint	Não	Fornece uma dica ao 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 a entrada para um provedor social.
Parâmetros personalizados	Não	Parâmetros personalizados que podem ser usados com políticas personalizadas. Por exemplo, URI de conteúdo de página personalizado dinâmico 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 inserir 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 de usuário é definido.

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

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	Descrição
token_de_identidade	O token de ID solicitado pelo aplicativo. Você pode usar o token de ID para verificar a identidade do usuário e iniciar uma sessão com o usuário.
código	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. Normalmente, os códigos de autorização expiram após cerca de 10 minutos.
estado	Se um parâmetro `state` 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 resposta são idênticos.

As respostas de erro também podem ser enviadas para o redirect_uri parâmetro para que o aplicativo possa tratá-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	Descrição
erro	Um código que pode ser usado para classificar os tipos de erros que ocorrem.
descrição_do_erro	Uma mensagem de erro específica que pode ajudar a identificar a causa raiz de um erro de autenticação.
estado	Se um parâmetro `state` 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 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 aplicativo. O Azure AD B2C usa JWTs (Tokens Web JSON) e criptografia de chave pública para assinar tokens e verificar se eles são válidos.

Observação

A maioria das bibliotecas de autenticação de software livre valida os JWTs 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 MSAL (Biblioteca de Autenticação da Microsoft) e da biblioteca de autenticação da Microsoft Identity Web.

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 no runtime. Essas informações incluem terminais, dados do 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 fluxo de usuário b2c_1_sign_in 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 acr no token da ID, consulte a declaração que representa o fluxo de usuário. Sua outra opção é codificar o fluxo de usuário no valor do state parâmetro quando você emitir a solicitação e decodificá-la para determinar qual fluxo de usuário foi usado. Qualquer um dos métodos é válido.

Após ter adquirido o documento de metadados pelo ponto de extremidade de metadados do OpenID Connect, você poderá usar as chaves públicas RSA 256 para validar a assinatura do token da ID. Pode haver várias chaves listadas neste endpoint, cada uma identificada por um atributo kid. O cabeçalho do token de ID também contém uma kid declaração, que indica quais dessas chaves foram usadas 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 modulus(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 nonce para evitar ataques de reprodução de token. Seu valor deve ser o que você especificou na solicitação de login.
Valide a declaração aud para garantir que o token de ID foi emitido para seu aplicativo. O valor deve ser a ID do seu aplicativo.
Valide as declarações iat e exp para garantir que o token de ID não tenha expirado.

Há também várias outras validações que você deve executar. As validações são descritas detalhadamente na Especificação do OpenID Connect Core. Talvez você também queira validar mais declarações, dependendo do seu cenário. Algumas validações comuns incluem:

Verifique se o usuário/organização se inscreveu no aplicativo.
Verifique se o usuário tem autorização/privilégios adequados.
Verifique se ocorreu um determinado nível 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 dessas 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, ignore as próximas seções. Essas seções são aplicáveis somente a aplicativos Web que precisam fazer chamadas autenticadas para uma API Web, que é protegida pelo próprio Azure AD B2C.

Você pode resgatar o código de autorização que adquiriu (usando response_type=code+id_token) por um token para o recurso desejado ao enviar uma solicitação POST para o endpoint /token. No Azure AD B2C, você pode solicitar tokens de acesso para outras APIs , como de costume, especificando seus escopos na solicitação.

Você também pode solicitar um token de acesso para a API Web de back-end do seu aplicativo. Nesse caso, você usa a ID do cliente do aplicativo como o escopo solicitado, o que resulta em um token de acesso com essa ID do cliente como o "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=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Parâmetro	Obrigatório	Descrição
{inquilino}	Sim	Nome do inquilino do Azure AD B2C
{política}	Sim	O fluxo de usuário usado para adquirir o código de autorização. Você não pode usar um fluxo de usuário diferente nesta solicitação. Adicione esse parâmetro à cadeia de caracteres de consulta, não ao corpo POST.
ID do cliente	Sim	A ID do aplicativo que o portal do Azure atribuiu ao seu aplicativo.
segredo_do_cliente	Sim, em Aplicativos Web	O segredo do aplicativo foi gerado no portal do Azure. Os segredos do cliente são usados nesse fluxo para cenários de Aplicativo Web, em que 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.
código	Sim	O código de autorização que você adquiriu no início do fluxo do usuário.
tipo_de_concessão	Sim	O tipo de concessão, que deve ser `authorization_code` para o fluxo do código de autorização.
URI de redirecionamento	Não	O `redirect_uri` parâmetro do aplicativo em que você recebeu o código de autorização.
âmbito	Não	Uma lista separada por espaços de âmbitos. O escopo `openid` indica uma permissão para conectar o usuário e obter dados sobre ele na forma de parâmetros de id_token. Ele pode ser usado para obter tokens para a própria API Web de back-end do seu aplicativo, representado pela mesma 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": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Parâmetro	Descrição
não antes	O horário da época em que o token se torna válido.
tipo_de_token	O valor do tipo de token. `Bearer` é o único tipo com suporte.
token_de_acesso	O JWT assinado que você solicitou.
âmbito	Os escopos válidos para o token.
expira_em	O período de tempo em que o token de acesso é válido (em segundos).
expira_em	A época em que o token de acesso se torna inválido.
token de atualização	Um token de atualização do 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 reter 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 se parecem com:

{
    "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	Descrição
erro	Um código que pode ser usado para classificar tipos de erros que ocorrem.
descrição_do_erro	Uma mensagem que pode ajudar a identificar a causa raiz de um erro de autenticação.

Usar o token

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

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

Atualizar o token

Tokens de acesso e tokens de ID são de curta duração. 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á os valores de declaração atualizados nbf (não antes), iat (emitido 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 requisição para o /token endpoint. 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=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Parâmetro	Obrigatório	Descrição
{inquilino}	Sim	Nome do inquilino do Azure AD B2C
{política}	Sim	O fluxo de usuário usado para adquirir o token de atualização original. Você não pode usar um fluxo de usuário diferente nesta solicitação. Adicione esse parâmetro à cadeia de caracteres de consulta, não ao corpo POST.
ID do cliente	Sim	A ID do aplicativo que o portal do Azure atribuiu ao seu aplicativo.
segredo_do_cliente	Sim, em Aplicativos Web	O segredo do aplicativo foi gerado no portal do Azure. Os segredos do cliente são usados nesse fluxo para cenários de Aplicativo Web, em que 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 nessa chamada. Se estiver usando um segredo do cliente, altere-o periodicamente.
tipo_de_concessão	Sim	O tipo de concessão, que deve ser `refresh_token` para essa parte do fluxo do código de autorização.
token de atualização	Sim	O token de atualização original foi adquirido na segunda parte do fluxo. O escopo `offline_access` dever ser usado nas solicitações de autorização e de token para receber um token de atualização.
URI de redirecionamento	Não	O `redirect_uri` parâmetro do aplicativo em que você recebeu o código de autorização.
âmbito	Não	Uma lista separada por espaços de âmbitos. O escopo `openid` indica uma permissão para entrar no usuário e obter dados sobre ele na forma de tokens de ID. Ele pode ser usado para enviar tokens para a própria API Web de back-end do seu aplicativo, que é representado pela mesma ID do aplicativo do 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": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
    "refresh_token_expires_in": "1209600"
}

Parâmetro	Descrição
não antes	O horário da época em que o token se torna válido.
tipo_de_token	O valor do tipo de token. `Bearer` é o único tipo com suporte.
token_de_acesso	O JWT assinado que foi solicitado.
âmbito	Os escopos válidos para o token.
expira_em	O período de tempo em que o token de acesso é válido (em segundos).
token de atualização	Um token de atualização do 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 reter 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 se parecem com:

{
    "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	Descrição
erro	Um código que pode ser usado para classificar tipos de erros que ocorrem.
descrição_do_erro	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. Redirecione o usuário para o Azure AD B2C para sair. Se você não fizer isso, o usuário poderá reautenticar seu aplicativo sem inserir suas credenciais novamente. Para obter mais informações, consulte o comportamento da sessão do Azure AD B2C.

Para desconectar o usuário, redirecione o usuário 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	Descrição
{inquilino}	Sim	O nome do seu locatário do Azure AD B2C. Se você estiver usando um domínio personalizado, substitua `tenant.b2clogin.com` por 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 conectou-se com o fluxo de usuário `b2c_1_sign_in`, especifique `b2c_1_sign_in` na solicitação de logout.
dica_sobre_o_token_de_id	Não	Um token de ID emitido anteriormente para passar para o ponto de extremidade de logoff 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 Azure AD B2C aplicativo. Para obter mais informações, consulte proteger seu redirecionamento de logoff.
ID do cliente	Não*	A ID do aplicativo que o portal do Azure atribuiu ao seu aplicativo. * Isso é necessário ao usar a configuração de SSO de isolamento `Application` e quando a solicitação Exigir token da ID* no logoff estiver definido como `No`.*
post_logout_redirect_uri	Não	A URL para a qual o usuário deve ser redirecionado após a saída bem-sucedida. Se não estiver incluído, o Azure AD B2C mostrará ao usuário uma mensagem genérica. A menos que você forneça uma `id_token_hint`URL, você não deve registrar essa URL como uma URL de resposta nas configurações do aplicativo Azure AD B2C.
estado	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 logout, o Azure AD B2C invalida a sessão baseada em cookies do Azure AD B2C e tenta fazer logout dos provedores de identidade federados. Para saber mais, confira Logoff único.

Proteja seu redirecionamento de logout

Após o logout, o usuário é redirecionado para a URL especificada no parâmetro post_logout_redirect_uri, independentemente das URLs de resposta especificadas para o aplicativo. No entanto, se um id_token_hint válido for passado e a opção Exigir Token de ID em solicitações de logout estiver ativada, 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 definir o Token de ID necessário em solicitações de logoff, consulte Configurar o comportamento da sessão no Azure Active Directory B2C.

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

Compartilhar via

Login na Web usando OpenID Connect no Azure Active Directory B2C