Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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 nas nossas Perguntas Frequentes.
Muitos aplicativos modernos têm um front-end de aplicativo de página única (SPA) que é escrito principalmente em JavaScript. Muitas vezes, o aplicativo é escrito usando uma estrutura como React, Angular ou Vue.js. Os SPAs e outros aplicativos JavaScript executados principalmente em um navegador têm alguns desafios adicionais para autenticação:
As características de segurança dessas aplicações são diferentes das aplicações Web tradicionais baseadas em servidor.
Muitos servidores de autorização e provedores de identidade não oferecem suporte a solicitações de compartilhamento de recursos entre origens (CORS).
Redirecionamentos de navegador de página inteira para longe do aplicativo podem ser invasivos para a experiência do usuário.
Advertência
A Microsoft recomenda que você não use o fluxo de concessão implícito. A maneira recomendada de suportar SPAs é o fluxo de código de autorização OAuth 2.0 (com PKCE). Certas configurações desse fluxo exigem um grau muito alto de confiança no aplicativo e acarretam riscos que não estão presentes em outros fluxos. Você só deve usar esse fluxo quando outros fluxos mais seguros não forem viáveis. Para obter mais informações, consulte as preocupações de segurança com o fluxo de concessão implícito.
Algumas estruturas, como MSAL.js 1.x, suportam apenas o fluxo de subvenção implícito. Nesses casos, o Azure Ative Directory B2C (Azure AD B2C) dá suporte ao fluxo de concessão implícita de autorização OAuth 2.0. O fluxo é descrito na secção 4.2 da especificação OAuth 2.0. No fluxo implícito, o aplicativo recebe tokens diretamente do ponto de extremidade de autorização do Azure AD B2C, sem qualquer troca de servidor para servidor. Toda a lógica de autenticação e manipulação de sessão é feita inteiramente no cliente JavaScript com um redirecionamento de página ou uma caixa pop-up.
O Azure AD B2C estende o fluxo implícito OAuth 2.0 padrão para mais do que simples autenticação e autorização. O Azure AD B2C introduz o parâmetro de política. Com o parâmetro policy, você pode usar o OAuth 2.0 para adicionar políticas ao seu aplicativo, como fluxos de usuário de inscrição, entrada e gerenciamento de perfis. No exemplo de solicitações HTTP neste artigo, usamos {tenant}.onmicrosoft.com para ilustração. Substitua {tenant}pelo nome do seu inquilino , se tiver um. Além disso, você precisa ter criado um fluxo de usuário.
Usamos a figura a seguir para ilustrar o fluxo de entrada implícito. Cada etapa é descrita em detalhes mais adiante no artigo.
Enviar pedidos de autenticação
Quando a sua aplicação web precisa autenticar o utilizador e executar um fluxo de utilizador, direciona o utilizador para o endpoint do Azure AD B2C /authorize. 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 o fluxo de usuário para ser executado. Para ter uma ideia de como a solicitação funciona, tente colá-la em um navegador e executá-la. Substituir:
{tenant}com o nome do seu inquilino do Azure AD B2C.00001111-aaaa-2222-bbbb-3333cccc4444com o ID da aplicação que registou no seu inquilino.{policy}com o nome de uma política que criou no seu inquilino, por exemplob2c_1_sign_in.
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
Os parâmetros na solicitação HTTP GET são explicados na tabela abaixo.
| Parâmetro | Obrigatório | Descrição |
|---|---|---|
| {inquilino} | Sim | Nome do inquilino do Azure AD B2C |
| {política} | Sim | O nome do fluxo de usuário que você deseja executar. Especifique o nome de um fluxo de usuário que você criou 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. |
| tipo_de_resposta | Sim | Deve incluir id_token para login no OpenID Connect. Também pode incluir o tipo tokende resposta . Se você usar tokeno , seu aplicativo poderá receber imediatamente um token de acesso do ponto de extremidade de autorização, sem fazer uma segunda solicitação ao ponto de extremidade de autorização. Se você usar o tipo de token resposta, o scope parâmetro deverá conter um escopo que indique para qual recurso emitir o token. |
| uri_de_redirecionamento | Não | O URI de redirecionamento do seu aplicativo, onde as respostas de autenticação podem ser enviadas e recebidas pelo seu aplicativo. Ele deve corresponder exatamente a um dos URIs de redirecionamento que você adicionou a um aplicativo registrado no portal, exceto que ele deve ser codificado por URL. |
| modo_de_resposta | Não | Especifica o método a ser usado para enviar o token resultante de volta ao seu aplicativo. Para fluxos implícitos, use fragment. |
| Alcance | Sim | Uma lista de escopos separados por espaço. Um único valor de escopo indica ao Microsoft Entra ID ambas as permissões que estão sendo solicitadas. O openid escopo indica uma permissão para iniciar sessão do utilizador e obter dados sobre o utilizador na forma de tokens de identificação. O offline_access escopo é opcional para aplicativos Web. Ele indica que seu aplicativo precisa de um token de atualização para acesso de longa duração aos recursos. |
| Estado | Não | Um valor incluído na solicitação que também é retornado na resposta do token. Pode ser uma cadeia de caracteres de qualquer conteúdo que você queira usar. Normalmente, um valor exclusivo gerado aleatoriamente é 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, por exemplo, a página em que o usuário estava ou o fluxo de usuário que estava sendo executado. |
| Nonce | Sim | Um valor incluído na solicitação (gerado pelo aplicativo) que é incluído no token de ID resultante como uma declaração. O aplicativo pode verificar esse valor para mitigar ataques de repetição de token. Normalmente, o valor é uma cadeia de caracteres aleatória e exclusiva que pode ser usada para identificar a origem da solicitação. |
| Sugestão | Não | O tipo de interação de utilizador que é necessária. Atualmente, o único valor válido é login. Esse parâmetro força o usuário a inserir suas credenciais nessa solicitação. A Sign-On única não entra em vigor. |
Esta é a parte interativa do fluxo. O usuário é solicitado a concluir o fluxo de trabalho da política. O utilizador poderá ter de introduzir o seu nome de utilizador e palavra-passe, iniciar sessão com uma identidade social, inscrever-se numa conta local ou qualquer outro número de passos. As ações do usuário dependem de como o fluxo do usuário é definido.
Depois que o usuário conclui o fluxo de usuário, o Azure AD B2C retorna uma resposta ao seu aplicativo por meio do redirect_uri. Ele usa o método especificado no response_mode parâmetro. A resposta é exatamente a mesma para cada um dos cenários de ação do usuário, independentemente do fluxo de usuário que foi executado.
Resposta com êxito
Uma resposta bem-sucedida que usa response_mode=fragment e response_type=id_token+token se parece com o seguinte, com quebras de linha para legibilidade:
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
| Parâmetro | Descrição |
|---|---|
| token de acesso | O token de acesso que o aplicativo solicitou do Azure AD B2C. |
| tipo_de_token | O valor do tipo de 'token'. O único tipo que o Azure AD B2C suporta é Bearer. |
| expira em | O período de tempo em que o token de acesso é válido (em segundos). |
| Alcance | Os escopos para os quais o token é válido. Você também pode usar escopos para armazenar tokens em cache para uso posterior. |
| id_token (token de identificação) | 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. Para obter mais informações sobre tokens de ID e o seu conteúdo, consulte a referência de token do Azure AD B2C. |
| Estado | 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. |
Resposta de erro
As respostas de erro também podem ser enviadas para o URI de redirecionamento para que o aplicativo possa manipulá-las adequadamente:
GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response
| Parâmetro | Descrição |
|---|---|
| erro | Um código usado para classificar tipos de erros que ocorrem. |
| descrição_do_erro | Uma mensagem de erro específica que pode ajudá-lo a identificar a causa raiz de um erro de autenticação. |
| Estado | 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 identidade
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.
Muitas bibliotecas de código aberto estão disponíveis para validar JWTs, dependendo do idioma que você prefere usar. Considere explorar bibliotecas de código aberto disponíveis em vez de implementar sua própria lógica de validação. Você pode usar as informações deste artigo para ajudá-lo a aprender como usar corretamente essas bibliotecas.
O Azure AD B2C tem um endpoint de metadados do OpenID Connect. Um aplicativo pode usar o endpoint para obter informações sobre o Azure AD B2C durante o tempo de execução. Essas informações incluem pontos de extremidade, conteúdos de tokens e chaves de assinatura de token. Há um documento de metadados JSON para cada fluxo de usuário em seu locatário do Azure AD B2C. Por exemplo, o documento de metadados para um fluxo de usuário nomeado b2c_1_sign_in em um fabrikamb2c.onmicrosoft.com locatário está localizado em:
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 é o jwks_uri. O 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 (e de onde buscar os metadados), você pode usar qualquer uma das seguintes opções:
O nome do fluxo de usuário está incluído na reivindicação de
acremid_token. Para obter informações sobre como interpretar as declarações de um token de ID, consulte a referência de token do Azure AD B2C.Codifique o fluxo de usuário no valor do
stateparâmetro quando você emitir a solicitação. Em seguida, decodifice ostateparâmetro para determinar qual fluxo de usuário foi usado.
Depois de adquirires o documento de metadados do endpoint de metadados OpenID Connect, podes usar as chaves públicas RSA-256 (localizadas neste endpoint) para validar a assinatura do token de ID. Pode haver várias chaves listadas neste ponto de extremidade a qualquer momento, cada uma identificada por um kid. O cabeçalho de id_token também contém uma kid declaração. Ele indica qual dessas chaves foi usada para assinar o token de ID. Para obter mais informações, incluindo aprender sobre a validação de tokens, consulte a referência de token do Azure AD B2C.
Depois de validar a assinatura do token de ID, várias declarações exigem verificação. Por exemplo:
Valide a reivindicação
noncepara evitar ataques de repetição de tokens. Seu valor deve ser o que você especificou na solicitação de entrada.Valide a
auddeclaração para garantir que o token de ID foi emitido para seu aplicativo. O seu valor deve ser a identificação da sua aplicação.Valide as
iateexpafirmações para garantir que o token de ID não tenha expirado.
Várias outras validações que você deve executar são descritas em detalhes na especificação principal do OpenID Connect. Você também pode querer validar declarações adicionais, dependendo do seu cenário. Algumas validações comuns incluem:
Garantir que o usuário ou organização se inscreveu no aplicativo.
Garantir que o usuário tenha a devida autorização e privilégios.
Garantir que um determinado nível de autenticação foi alcançado, por exemplo, através da utilização de autenticação multifator do Microsoft Entra.
Para obter mais informações sobre as declarações em um token de ID, consulte a referência de token do Azure AD B2C.
Depois de validar o token de ID, você pode iniciar uma sessão com o usuário. Em seu aplicativo, use as declarações no token de ID para obter informações sobre o usuário. Essas informações podem ser usadas para exibição, registros, autorização e assim por diante.
Obter tokens de acesso
Se a única coisa que seus aplicativos Web precisam fazer é executar fluxos de usuários, você pode pular as próximas seções. As informações nas seções a seguir são aplicáveis somente a aplicativos Web que precisam fazer chamadas autenticadas para uma API Web protegida pelo próprio Azure AD B2C.
Agora que autenticou o utilizador na sua SPA, pode obter tokens de acesso para chamar APIs Web que são protegidas pelo Microsoft Entra ID. Mesmo que você já tenha recebido um token usando o token tipo de resposta, você pode usar esse método para adquirir tokens para recursos adicionais sem redirecionar o usuário para entrar novamente.
Em um fluxo típico de aplicativo Web, você faria uma solicitação para o /token ponto de extremidade. No entanto, um endpoint não suporta pedidos CORS, portanto, efetuar chamadas AJAX para obter um token de refresh não é uma opção. Em vez disso, você pode usar o fluxo implícito em um elemento iframe HTML oculto para obter novos tokens para outras APIs da Web. Aqui está um exemplo, com quebras de linha para legibilidade:
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none
| Parâmetro | Necessário? | Descrição |
|---|---|---|
| {inquilino} | Obrigatório | Nome do inquilino do Azure AD B2C |
| {política} | Obrigatório | O fluxo de utilizador que será executado. Especifique o nome de um fluxo de usuário que você criou 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 | Obrigatório | A ID do aplicativo atribuída ao seu aplicativo no portal do Azure. |
| tipo_de_resposta | Obrigatório | Deve incluir id_token para login no OpenID Connect. Também pode incluir o tipo de resposta token. Se usar token aqui, a sua aplicação poderá receber imediatamente um token de acesso do endpoint de autorização, sem fazer uma segunda solicitação. Se você usar o tipo de token resposta, o scope parâmetro deverá conter um escopo que indique para qual recurso emitir o token. |
| uri_de_redirecionamento | Recomendado | O URI de redirecionamento do seu aplicativo, onde as respostas de autenticação podem ser enviadas e recebidas pelo seu aplicativo. Ele deve corresponder exatamente a um dos URIs de redirecionamento que você registrou no portal, exceto que ele deve ser codificado por URL. |
| Alcance | Obrigatório | Uma lista de escopos separados por espaço. Para obter tokens, inclua todas as permissões necessárias para o recurso pretendido. |
| modo_de_resposta | Recomendado | Especifica o método usado para enviar o token resultante de volta ao seu aplicativo. Para fluxo implícito, use fragment. Dois outros modos podem ser especificados query e form_post, mas não funcionam no fluxo implícito. |
| Estado | Recomendado | Um valor incluído na solicitação que é retornado na resposta do token. Pode ser uma cadeia de caracteres de qualquer conteúdo que você queira usar. Normalmente, um valor exclusivo gerado aleatoriamente é 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. Por exemplo, a página ou visualização em que o usuário estava. |
| Nonce | Obrigatório | Um valor incluído na solicitação, gerado pelo aplicativo e incluído no token de ID resultante como uma reivindicação. O aplicativo pode verificar esse valor para mitigar ataques de repetição de token. Normalmente, o valor é uma cadeia de caracteres aleatória e exclusiva que identifica a origem da solicitação. |
| Sugestão | Obrigatório | Para atualizar e obter tokens em um iframe oculto, use prompt=none para garantir que o iframe não fique preso na página de login e retorne imediatamente. |
| login_hint | Obrigatório | Para atualizar e obter tokens em um iframe oculto, inclua o nome de usuário do usuário nesta dica para distinguir entre várias sessões que o usuário pode ter em um determinado momento. Você pode extrair o nome de usuário de um login anterior usando a preferred_username declaração (o profile escopo é necessário para receber a preferred_username declaração). |
| sugestão_de_domínio | Obrigatório | Pode ser consumers ou organizations. Para atualizar e obter tokens em um iframe oculto, inclua o valor domain_hint na solicitação. Extraia a tid afirmação do token de ID de uma sessão anterior para determinar qual valor utilizar (o profile escopo é necessário para receber a tid afirmação). Se o valor da tid afirmação for 9188040d-6c67-4c5b-b112-36a304b66dad, use domain_hint=consumers. Caso contrário, use domain_hint=organizations. |
Ao definir o prompt=none parâmetro, essa solicitação é bem-sucedida ou falha imediatamente e retorna ao seu aplicativo. Uma resposta bem-sucedida é enviada ao seu aplicativo por meio do URI de redirecionamento, usando o método especificado no response_mode parâmetro.
Resposta com êxito
Uma resposta bem-sucedida usando response_mode=fragment se parece com este exemplo:
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
| Parâmetro | Descrição |
|---|---|
| token de acesso | O token que o aplicativo solicitou. |
| tipo_de_token | O tipo de token será sempre Bearer. |
| Estado | 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. |
| expira em | Por quanto tempo o token de acesso é válido (em segundos). |
| Alcance | Os escopos para os quais o token de acesso é válido. |
Resposta de erro
As respostas de erro também podem ser enviadas para o URI de redirecionamento para que o aplicativo possa manipulá-las adequadamente. Para prompt=none, um erro esperado se parece com este exemplo:
GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently
| Parâmetro | Descrição |
|---|---|
| erro | Uma cadeia de caracteres de código de erro que pode ser usada para classificar tipos de erros que ocorrem. Você também pode usar a cadeia de caracteres para reagir a erros. |
| descrição_do_erro | Uma mensagem de erro específica que pode ajudá-lo a identificar a causa raiz de um erro de autenticação. |
Se você receber esse erro na solicitação iframe, o usuário deverá entrar interativamente novamente para recuperar um novo token.
Atualizar tokens
Os tokens de ID e os tokens de acesso expiram após um curto período de tempo. Seu aplicativo deve estar preparado para atualizar esses tokens periodicamente. Os fluxos implícitos não permitem que você obtenha um token de atualização devido a razões de segurança. Para atualizar qualquer tipo de token, use o fluxo implícito em um elemento iframe HTML oculto. Na solicitação de autorização, inclua o prompt=none parâmetro. Para receber um novo valor de id_token, certifique-se de usar response_type=id_token e scope=openid, e um nonce parâmetro.
Enviar uma solicitação de saída
Quando quiser desassociar o utilizador da aplicação, redirecione-o para o endpoint de sign-out do Azure AD B2C. Em seguida, você pode limpar a sessão do usuário no aplicativo. Se você não redirecionar o usuário, ele poderá se autenticar novamente em seu aplicativo sem inserir suas credenciais novamente, porque ele tem uma sessão de Sign-On única válida com o Azure AD B2C.
Você pode simplesmente redirecionar o usuário para o end_session_endpoint que está listado no mesmo documento de metadados do OpenID Connect descrito em Validar o token de ID. Por exemplo:
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
| Parâmetro | Obrigatório | Descrição |
|---|---|---|
| {inquilino} | Sim | Nome do seu inquilino do Azure AD B2C. |
| {política} | Sim | O fluxo de usuário que você deseja usar para sair do aplicativo. Este precisa ser o mesmo fluxo de utilizador que a aplicação usou para autenticar o utilizador. |
| URI_de_redirecionamento_apos_logout | 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. |
| Estado | Não | 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. |
Observação
Direcionar o utilizador para o end_session_endpoint limpa parte do estado único Sign-On do utilizador com o Azure AD B2C. No entanto, não encerra a sessão do usuário no provedor de identidade social. Se o usuário selecionar o mesmo provedor de identidade durante uma entrada subsequente, o usuário será autenticado novamente, sem inserir suas credenciais. Se um usuário quiser sair do seu aplicativo Azure AD B2C, isso não significa necessariamente que ele deseja sair completamente de sua conta do Facebook, por exemplo. No entanto, para contas locais, a sessão do usuário será encerrada corretamente.
Próximos passos
Consulte o exemplo de código: Entrar com o Azure AD B2C em um SPA JavaScript.