Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Importante
A partir de 1 de maio de 2025, o Azure AD B2C deixará de estar 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
Microsoft recomenda que não utilizes o fluxo implícito de autorização. 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. Nestes casos, o Azure Active Directory B2C (Azure AD B2C) suporta o fluxo implícito de concessão de autorização OAuth 2.0. O fluxo é descrito na secção 4.2 da especificação OAuth 2.0. No fluxo implícito, a aplicação recebe tokens diretamente do endpoint de autorização Azure AD B2C, sem qualquer troca 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 padrão OAuth 2.0 para mais do que apenas autenticação e autorização. Azure AD B2C introduz o parâmetro policy. 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 de autenticar o utilizador e executar um fluxo de utilizador, ela direciona o utilizador para o endpoint /authorize do AD B2C do Azure. 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 tenant 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 teu inquilino Azure AD B2C |
| {política} | Sim | O nome do fluxo de usuário que você deseja executar. Especifique o nome de um fluxo de utilizador que criou no seu tenant B2C do Azure AD. Por exemplo: b2c_1_sign_in, b2c_1_sign_up, ou b2c_1_edit_profile. |
| ID do cliente | Sim | O ID da aplicação que o portal Azure atribuiu à sua aplicação. |
| 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. |
| âmbito | Sim | Uma lista de escopos separados por espaço. Um único valor de âmbito indica ao Microsoft Entra ID ambas as permissões que estão a ser 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. |
| avisar | 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 de o utilizador completar o fluxo de utilizador, Azure AD B2C devolve uma resposta à sua aplicação através 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 a aplicação solicitou ao Azure AD B2C. |
| tipo_de_token | O valor do tipo de 'token'. O único tipo que o Azure AD B2C suporta é o Portador. |
| expira em | O período de tempo em que o token de acesso é válido (em segundos). |
| âmbito | 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 mais informações sobre os ID tokens e o seu conteúdo, consulte a referência Azure AD B2C token. |
| 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. Azure AD B2C usa JSON Web Tokens (JWTs) e criptografia de chave pública para assinar tokens e verificar se 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 OpenID Connect. Uma aplicação pode usar o endpoint para obter informação sobre o Azure AD B2C em tempo de execução. Essas informações incluem pontos de extremidade, conteúdos de tokens e chaves de assinatura de token. Existe um documento de metadados JSON para cada fluxo de utilizador no seu tenant B2C do Azure AD. 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 informações sobre como analisar as declarações de um ID token, 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 mais informações, incluindo informações sobre validar tokens, consulte a referência de tokens 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 ocorreu um determinado nível de autenticação, utilizando a autenticação multifator do Microsoft Entra.
Para mais informações sobre as reivindicações num ID token, consulte a referência Azure AD B2C token.
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. A informação nas secções seguintes aplica-se apenas a aplicações web que necessitem de fazer chamadas autenticadas para uma API web protegida pelo próprio Azure AD B2C.
Agora que assinou o utilizador no seu SPA, pode obter tokens de acesso para chamadas de 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 teu inquilino Azure AD B2C |
| {política} | Obrigatório | O fluxo de utilizador que será executado. Especifique o nome de um fluxo de utilizador que criou no seu tenant B2C do Azure AD. Por exemplo: b2c_1_sign_in, b2c_1_sign_up, ou b2c_1_edit_profile. |
| ID do cliente | Obrigatório | O ID da aplicação atribuído à sua aplicação no portal 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. |
| âmbito | 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. |
| avisar | 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). |
| âmbito | 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 quiseres desligar o utilizador da aplicação, redireciona-o para o endpoint de saída de sessão do Azure AD B2C. Em seguida, você pode limpar a sessão do usuário no aplicativo. Se não redirecionares o utilizador, ele pode conseguir autenticar-se novamente na tua aplicação sem ter de voltar a introduzir as credenciais porque tem uma sessão válida de Sign-On única com 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 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 utilizador deve ser redirecionado após sair com sucesso. Se não estiver incluído, o Azure AD B2C mostra ao utilizador 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 Single Sign-On do utilizador com 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 utilizador quiser sair da sua aplicação B2C do Azure AD, isso não significa necessariamente que queira sair completamente da sua conta do Facebook, por exemplo. No entanto, para contas locais, a sessão do usuário será encerrada corretamente.
Próximos passos
Veja o exemplo de código: Log-in com Azure AD B2C num JavaScript SPA.