Tipos de aplicativos que podem ser usados no Ative Directory B2C

O Azure Ative Directory B2C (Azure AD B2C) dá suporte à autenticação para várias arquiteturas de aplicativos modernos. Todos eles são baseados nos protocolos padrão da indústria OAuth 2.0 ou OpenID Connect. Este artigo descreve os tipos de aplicativos que você pode criar, independentemente da linguagem ou plataforma de sua preferência. 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 registo da candidatura recolhe e atribui valores, tais como:

• Uma ID de aplicativo que identifica exclusivamente seu aplicativo.
• Um URL de resposta que pode ser usado para direcionar as respostas de volta para o 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 criar 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. A aplicação direciona o utilizador para o ponto de extremidade v2.0 para executar uma política.
2. O usuário completa a política de acordo com a definição da política.
3. A aplicação recebe um token de segurança a partir do endpoint v2.0.
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 diferir ligeiramente com base no tipo de aplicativo que você está criando.

Aplicações Web

Para aplicativos Web (incluindo .NET, PHP, Java, Ruby, Python e Node.js) 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 experiências de usuário emitindo solicitações de autenticação para o Microsoft Entra ID. O resultado do pedido é 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 reivindicaçõ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 é enviado para o URI de redirecionamento.
6. O id_token é validado e um cookie de sessão é definido.
7. Uma página segura é devolvida ao usuário.

A validação do id_token usando uma chave de assinatura pública recebida da ID do Microsoft Entra é suficiente para verificar a identidade do usuário. Este 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 o login simples, um aplicativo Web também pode precisar acessar um serviço Web back-end. Nesse caso, o aplicativo Web pode executar um fluxo 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 APIs da 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 escrevem 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 tradicionais do lado do servidor.

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

Fluxo de 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 tokens de acesso necessários para chamar APIs protegidas. Além disso, ele retorna tokens de atualização que fornecem acesso de longo prazo a recursos em nome dos usuários sem exigir interação com esses usuários.

Recomendámos esta abordagem. Ter tokens de atualização com tempo de vida limitado ajuda o seu aplicativo a se adaptar às limitações modernas da privacidade dos cookies do navegador, como o Safari ITP.

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

Fluxo de subvenções implícito

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ícito permite que o aplicativo obtenha tokens de identificação (ID) e de 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 aplicativos que usam estruturas JavaScript de plataforma cruzada, como Electron e React-Native. Esses cenários exigem mais recursos para interação com as plataformas nativas.

Web APIs

Você pode usar o Azure AD B2C para proteger serviços Web, como a API Web RESTful do seu aplicativo. As APIs da Web podem usar o OAuth 2.0 para proteger seus dados, autenticando solicitações HTTP de entrada usando tokens. O chamador de uma API da 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
...

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

Uma API da Web pode receber tokens de muitos tipos de clientes, incluindo aplicativos da Web, aplicativos móveis e de desktop, aplicativos de página única, daemons do lado do servidor e outras APIs da Web. Aqui está um exemplo do fluxo completo para um aplicativo Web que chama uma API da 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 um access_token ao Azure AD B2C, fornecendo-lhe o código de autorização, a ID do cliente do aplicativo e as credenciais do cliente.
6. Os access_token e refresh_token são devolvidos ao servidor Web.
7. A API web é chamada com o access_token no cabeçalho de autorização.
8. A API da Web valida o token.
9. Os dados seguros são devolvidos à aplicação Web.

Para saber mais sobre códigos de autorização, atualizar tokens 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.

Aplicações móveis e nativas

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

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

Daemons/aplicativos do lado do servidor

Os aplicativos que contêm processos de longa execução ou que operam sem a presença de um usuário também precisam de uma maneira de acessar recursos seguros, como APIs da 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 de representação, e este último não deve ser usado para autenticação de servidor para servidor.

Para o Azure AD B2C, o fluxo de credenciais do cliente OAuth 2.0 está atualmente em visualização pública. No entanto, pode configurar o fluxo de credenciais do cliente usando Microsoft Entra ID e a plataforma de identidade da Microsoft /token endpoint (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) para uma aplicação do Microsoft Graph ou a sua própria aplicação. Para obter mais informações, consulte o artigo de referência do token Microsoft Entra .

Tipos de aplicativos não suportados

Cadeias de API da Web (em nome do fluxo)

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

Este cenário de API da Web encadeada pode ser suportado utilizando a concessão de credenciais de portador JWT OAuth 2.0, também conhecida como fluxo em nome de outro. No entanto, o fluxo em nome de não está atualmente implementado no Azure AD B2C.

Próximos passos

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