Compartilhar via

Tipos de aplicativo que podem ser usados no Active Directory B2C

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 Azure AD B2C (Azure Active Directory B2C) dá suporte à autenticação para várias arquiteturas de aplicativos modernas. Todos eles são baseados nos protocolos padrão do setor OAuth 2.0 ou OpenID Connect. Este artigo descreve os tipos de aplicativos que você pode criar, independentemente da linguagem ou plataforma que você preferir. Ele também ajuda você a entender os cenários de alto nível antes de começar a criar aplicativos.

Cada aplicativo que usa o Azure AD B2C deve ser registrado em seu locatário do Azure AD B2C usando o portal do Azure. O processo de registro do aplicativo coleta e atribui valores, como:

  • Uma ID do aplicativo que identifica exclusivamente seu aplicativo.
  • Uma URL de Resposta que pode ser usada para direcionar respostas de volta ao seu aplicativo.

Cada solicitação enviada ao Azure AD B2C especifica um fluxo de usuário (uma política interna) ou uma política personalizada que controla o comportamento do Azure AD B2C. Ambos os tipos de política permitem que você crie um conjunto altamente personalizável de experiências do usuário.

A interação de cada aplicativo segue um padrão de alto nível semelhante:

  1. O aplicativo direciona o usuário para o endpoint v2.0 para executar uma política.
  2. O usuário conclui a política segundo a definição estabelecida.
  3. O aplicativo recebe do endpoint v2.0 um token de segurança.
  4. O aplicativo usa o token de segurança para acessar informações protegidas ou um recurso protegido.
  5. O servidor de recursos valida o token de segurança para verificar se o acesso pode ser concedido.
  6. O aplicativo atualiza periodicamente o token de segurança.

Essas etapas podem ser ligeiramente diferentes com base no tipo de aplicativo que você está criando.

Aplicativos Web

Para aplicativos Web (incluindo .NET, PHP, Java, Ruby, Python e Node.js) que são hospedados em um servidor Web e acessados por meio de um navegador, o Azure AD B2C dá suporte ao OpenID Connect para todas as experiências do usuário. Na implementação do Azure AD B2C do OpenID Connect, seu aplicativo Web inicia as experiências do usuário emitindo solicitações de autenticação para a ID do Microsoft Entra. O resultado da solicitação é um id_token. Esse token de segurança representa a identidade do usuário. Ele também fornece informações sobre o usuário na forma de declarações:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Saiba mais sobre os tipos de tokens e declarações disponíveis para um aplicativo na referência de token do Azure AD B2C.

Em um aplicativo Web, cada execução de uma política executa estas etapas de alto nível:

  1. O usuário navega até o aplicativo Web.
  2. O aplicativo Web redireciona o usuário para o Azure AD B2C indicando a política a ser executada.
  3. O usuário conclui a política.
  4. O Azure AD B2C retorna um id_token para o navegador.
  5. O id_token é postado para o URI de redirecionamento.
  6. O id_token é validado e um cookie de sessão é definido.
  7. Uma página segura é retornada ao usuário.

A validação de id_token por meio de uma chave de assinatura pública recebida do Microsoft Entra ID é suficiente para verificar a identidade do usuário. Esse processo também define um cookie de sessão que pode ser usado para identificar o usuário em solicitações de página subsequentes.

Para ver esse cenário em ação, experimente um dos exemplos de código de entrada do aplicativo Web em nossa seção Introdução.

Além de facilitar a entrada simples, um aplicativo Web também pode precisar acessar um serviço Web de back-end. Nesse caso, o aplicativo Web pode executar um fluxo do OpenID Connect ligeiramente diferente e adquirir tokens usando códigos de autorização e tokens de atualização. Esse cenário é descrito na seção de APIs Web a seguir.

Aplicativos de página única

Muitos aplicativos Web modernos são criados como aplicativos de página única do lado do cliente ("SPAs"). Os desenvolvedores os gravam usando JavaScript ou uma estrutura SPA, como Angular, Vue ou React. Esses aplicativos são executados em um navegador da Web e têm características de autenticação diferentes dos aplicativos Web do lado do servidor tradicionais.

O Azure AD B2C fornece duas opções para habilitar aplicativos de página única para conectar usuários e obter tokens para acessar serviços de back-end ou APIs Web:

Fluxo do código de autorização (com PKCE)

O fluxo de código de autorização do OAuth 2.0 (com PKCE) permite que o aplicativo troque um código de autorização por tokens de ID para representar o usuário autenticado e os tokens do Access necessários para chamar APIs protegidas. Além disso, ele retorna tokens de atualização que fornecem acesso de longo prazo aos recursos em nome dos usuários sem a necessidade de interação com esses usuários.

Recomendamos essa abordagem. Ter tokens de atualização com validade limitada ajuda seu aplicativo a se adaptar às limitações modernas de privacidade de cookie do navegador, como o Safari ITP.

Para aproveitar esse fluxo, seu aplicativo pode usar uma biblioteca de autenticação que dê suporte a ele, como MSAL.js 2.x.

Aplicativos de página única – autenticação

Fluxo de concessão implícita

Algumas bibliotecas, como MSAL.js 1.x, suportam apenas o fluxo de concessão implícito ou seu aplicativo é implementado para usar o fluxo implícito. Nesses casos, o Azure AD B2C dá suporte ao fluxo implícito do OAuth 2.0. O fluxo de concessão implícita permite que o aplicativo obtenha os tokens de ID e Acesso. Ao contrário do fluxo de código de autorização, o fluxo de concessão implícita não retorna um token de atualização.

Esse fluxo de autenticação não inclui cenários de aplicativo que usam estruturas JavaScript multiplataforma, como Electron e React-Native. Esses cenários exigem mais recursos para interação com as plataformas nativas.

Aviso

A Microsoft recomenda que você não use o fluxo de concessão implícita. A maneira recomendada de dar suporte a SPAs é o fluxo de código de autorização do OAuth 2.0 (com PKCE). Algumas configurações desse fluxo exigem um grau muito alto de confiança no aplicativo e traz riscos que não estão presentes em outros fluxos. Use-o somente 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.

APIs da Web

Você pode usar o Azure AD B2C para proteger serviços Web, como a API Web RESTful do aplicativo. As APIs Web podem usar o OAuth 2.0 para proteger seus dados, autenticando solicitações HTTP de entrada usando tokens. O chamador de uma API Web acrescenta um token no cabeçalho de autorização de uma solicitação HTTP:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

Em seguida, a API Web pode usar o token para verificar a identidade do chamador de API e extrair informações sobre o chamador de declarações codificadas no token. Saiba mais sobre os tipos de tokens e declarações disponíveis para um aplicativo na referência de tokens do Azure AD B2C.

Uma API Web pode receber tokens de vários tipos de clientes, incluindo aplicativos Web, aplicativos móveis e desktop, aplicativos de página única, daemons do lado do servidor e outras APIs Web. Aqui está um exemplo do fluxo completo para um aplicativo Web que chama uma API Web:

  1. O aplicativo Web executa uma política e o usuário conclui a experiência do usuário.
  2. O Azure AD B2C retorna um (OpenID Connect) id_token e um código de autorização para o navegador.
  3. O navegador envia o id_token e o código de autorização para o URI de redirecionamento.
  4. O servidor Web valida o id_token e define um cookie de sessão.
  5. O servidor Web solicita ao Azure AD B2C um access_token, fornecendo a ele o código de autorização, a ID de cliente do aplicativo e as credenciais do cliente.
  6. access_token E refresh_token são retornados para o servidor Web.
  7. A API Web é chamada com o access_token em um cabeçalho de autorização.
  8. A API Web valida o token.
  9. Os dados seguros são retornados para o aplicativo Web.

Para saber mais sobre códigos de autorização, tokens de atualização e as etapas para obter tokens, leia sobre o protocolo OAuth 2.0.

Para saber como proteger uma API Web usando o Azure AD B2C, confira os tutoriais da API Web em nossa seção Introdução.

Aplicativos nativos e móveis

Aplicativos instalados em dispositivos, como aplicativos móveis e desktop, geralmente precisam acessar serviços de back-end ou APIs Web em nome dos usuários. Você pode adicionar experiências personalizadas de gerenciamento de identidade aos seus aplicativos nativos e chamar serviços de back-end com segurança usando o Azure AD B2C e o fluxo de código de autorização do OAuth 2.0.

Nesse fluxo, o aplicativo executa políticas e recebe um authorization_code do Microsoft Entra ID após o usuário concluir a política. O authorization_code representa a permissão do aplicativo para chamar serviços back-end em nome do usuário conectado no momento. Em seguida, o aplicativo pode trocar, no segundo plano, o authorization_code por um access_token e um refresh_token. O aplicativo pode usar o access_token para autenticar em uma API Web de back-end em solicitações HTTP. Ele também pode usar o refresh_token para obter um novo access_token quando o antigo expira.

Daemons/aplicativos do lado do servidor

Aplicativos que contêm processos de execução longa ou que operam sem a presença de um usuário também precisam de uma maneira de acessar recursos protegidos, como APIs Web. Esses aplicativos podem autenticar e obter tokens usando suas identidades (em vez da identidade delegada de um usuário) e usando o fluxo de credenciais do cliente OAuth 2.0. O fluxo de credenciais do cliente não é o mesmo que o fluxo On-Behalf-Of e este não deve ser usado para a autenticação de servidor para servidor.

Para o Azure AD B2C, o fluxo de credenciais do cliente OAuth 2.0 está atualmente em versão prévia pública. No entanto, você pode configurar o fluxo de credenciais do cliente usando o Microsoft Entra ID e o ponto de extremidade /token da plataforma de identidade da Microsoft (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) para um aplicativo do Microsoft Graph ou para um aplicativo próprio. Para obter mais informações, confira o artigo de referência sobre o token do Microsoft Entra.

Tipos de aplicativo sem suporte

Cadeias de API Web (fluxo On-Behalf-Of)

Muitas arquiteturas incluem uma API Web que precisa chamar outra API Web downstream, em que ambas são protegidas pelo Azure AD B2C. Esse cenário é comum em clientes nativos que têm um back-end de API Web e chama um serviço online da Microsoft, como a API do Microsoft Graph.

Esse cenário de API Web encadeada pode ter suporte usando a concessão da credencial de portador JWT do OAuth 2.0, também conhecida como fluxo On-Behalf-Of. No entanto, o fluxo On-Behalf-Of não está implementado atualmente no Azure AD B2C.

Próximas etapas

Saiba mais sobre as políticas internas fornecidas pelos fluxos de usuário no Azure Active Directory B2C.