Tipos de aplicações que podem ser utilizados no Active Directory B2C

  • Artigo

O Azure Active Directory B2C (Azure AD B2C) suporta a autenticação para várias arquiteturas de aplicações modernas. Todos elas baseiam-se nos protocolos padrão da indústria OAuth 2.0 ou OpenID Connect. Este artigo descreve os tipos de aplicações que pode criar, independentemente da linguagem ou plataforma que preferir. Também ajuda-o a compreender os cenários de alto nível antes de começar a construir aplicações.

Todas as aplicações que utilizam Azure AD B2C têm de ser registadas no inquilino do Azure AD B2C através da portal do Azure. O processo de registo de aplicações recolhe e atribui valores, tais como:

  • Um ID da Aplicação que identifica exclusivamente a sua aplicação.
  • Um URL de Resposta que pode ser utilizado para direcionar as respostas de volta para a sua aplicação.

Cada pedido enviado para Azure AD B2C especifica um fluxo de utilizador (uma política incorporada) ou uma política personalizada que controla o comportamento do Azure AD B2C. Ambos os tipos de política permitem-lhe criar um conjunto altamente personalizável de experiências de utilizador.

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

  1. A aplicação direciona o utilizador para o ponto final v2.0 para executar uma política.
  2. O utilizador conclui a política de acordo com a sua definição.
  3. A aplicação recebe um token de segurança do ponto final v2.0.
  4. A aplicação utiliza o token de segurança para aceder a informações protegidas ou a um recurso protegido.
  5. O servidor de recurso valida o token de segurança para verificar que o acesso pode ser concedido.
  6. A aplicação atualiza periodicamente o token de segurança.

Estes passos podem diferir ligeiramente com base no tipo de aplicação que está a criar.

Aplicações Web

Para aplicações Web (incluindo .NET, PHP, Java, Ruby, Python e Node.js) alojadas num servidor Web e acedidas através de um browser, o Azure AD B2C suporta o OpenID Connect para todas as experiências de utilizador. No Azure AD implementação B2C do OpenID Connect, a sua aplicação Web inicia experiências de utilizador ao emitir pedidos de autenticação para Microsoft Entra ID. O resultado do pedido é um id_token. Este token de segurança representa a identidade do utilizador. Também fornece informações sobre o utilizador na forma de afirmações:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

Saiba mais sobre os tipos de tokens e afirmações disponíveis para uma aplicação no Azure AD referência do token B2C.

Numa aplicação Web, cada execução de uma política executa estes passos de alto nível:

  1. O utilizador navega para a aplicação Web.
  2. A aplicação Web redireciona o utilizador para Azure AD B2C, indicando a política a executar.
  3. O utilizador conclui a política.
  4. Azure AD B2C devolve um id_token para o browser.
  5. O id_token é publicado no URI de redirecionamento.
  6. O id_token é validado e é definido um cookie de sessão.
  7. É devolvida uma página segura ao utilizador.

A validação do id_token ao utilizar uma chave de assinatura pública recebida do Microsoft Entra ID é suficiente para verificar a identidade do utilizador. Este processo também define um cookie de sessão que pode ser utilizado para identificar o utilizador em pedidos de página subsequentes.

Para ver este cenário em ação, experimente um dos exemplos de código de início de sessão da aplicação Web na nossa secção Introdução.

Além de facilitar o início de sessão simples, uma aplicação Web também poderá ter de aceder a um serviço Web de back-end. Neste caso, a aplicação Web pode executar um fluxo do OpenID Connect ligeiramente diferente e adquirir tokens com códigos de autorização e tokens de atualização. Este cenário é descrito na seguinte secção APIs da Web.

Aplicações de página única

Muitas aplicações Web modernas são criadas como aplicações de página única do lado do cliente ("SPAs"). Os programadores escrevem-nos com JavaScript ou uma arquitetura SPA, como Angular, Vue ou React. Estas aplicações são executadas num browser e têm características de autenticação diferentes das aplicações Web tradicionais do lado do servidor.

Azure AD B2C fornece duas opções para permitir que as aplicações de página única iniciem sessão de utilizadores e obtenham tokens para aceder a serviços de back-end ou APIs Web:

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

O fluxo de código de autorização OAuth 2.0 (com PKCE) permite que a aplicação troque um código de autorização para tokens de ID para representar o utilizador autenticado e os tokens de Acesso necessários para chamar APIs protegidas. Além disso, devolve tokens de Atualização que fornecem acesso a longo prazo aos recursos em nome dos utilizadores sem necessidade de interação com esses utilizadores.

Recomendamos esta abordagem. Ter tokens de atualização de duração limitada ajuda a sua aplicação a adaptar-se a limitações modernas de privacidade de cookies do browser, como o ItP do Safari.

Para tirar partido deste fluxo, a sua aplicação pode utilizar uma biblioteca de autenticação que o suporte, como MSAL.js 2.x.

Applications-auth de página única

Fluxo de concessão implícito

Algumas bibliotecas, como MSAL.js 1.x, só suportam o fluxo de concessão implícita ou a sua aplicação é implementada para utilizar o fluxo implícito. Nestes casos, Azure AD B2C suporta o fluxo implícito OAuth 2.0. O fluxo de concessão implícita permite que a aplicação obtenha o ID e os tokens de Acesso . Ao contrário do fluxo de código de autorização, o fluxo de concessão implícita não devolve um token atualizar.

Não recomendamos esta abordagem.

Este fluxo de autenticação não inclui cenários de aplicações que utilizam arquiteturas JavaScript de várias plataformas, como Electron e React-Native. Esses cenários requerem mais capacidades de interação com as plataformas nativas.

APIs da Web

Pode utilizar Azure AD B2C para proteger serviços Web, como a API Web RESTful da sua aplicação. As APIs Web podem utilizar o OAuth 2.0 para proteger os seus dados, ao autenticar pedidos HTTP recebidos utilizando tokens. O autor da chamada de uma API web acrescenta um token no cabeçalho de autorização de um pedido HTTP:

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

A API web pode utilizar o token para verificar a identidade do autor da chamada da API e extrair informações sobre o autor da chamada com base nas afirmações codificadas no token. Saiba mais sobre os tipos de tokens e afirmações disponíveis para uma aplicação na referência de token do Azure AD B2C.

Uma API Web pode receber tokens de vários tipos de clientes, incluindo aplicações Web, aplicações móveis e de ambiente de trabalho, aplicações de página única, daemons do lado do servidor e outras APIs Web. Eis um exemplo do fluxo completo de uma aplicação Web que chama uma API Web:

  1. A aplicação Web executa uma política e o utilizador conclui a experiência de utilizador.
  2. Azure AD B2C devolve um (OpenID Connect) id_token e um código de autorização ao browser.
  3. O browser publica o id_token código de autorização e no URI de redirecionamento.
  4. O servidor Web valida e id_token define um cookie de sessão.
  5. O servidor Web pede Azure AD B2C para umaccess_token, fornecendo-lhe o código de autorização, o ID de cliente da aplicação e as credenciais de cliente.
  6. Os access_token e refresh_token são devolvidos ao servidor Web.
  7. A API Web é chamada com o access_token num cabeçalho de autorização.
  8. A API Web valida o token.
  9. Os dados seguros são devolvidos à aplicação Web.

Para obter mais informações sobre códigos de autorização, tokens de atualização e os passos para obter os tokens, leia sobre o protocolo OAuth 2.0.

Para saber como proteger uma API web utilizando o Azure AD B2C, consulte os tutoriais sobre web API na nossa secção Introdução.

Aplicações móveis e nativas

Muitas vezes, as aplicações instaladas em dispositivos, como aplicações móveis e de ambiente de trabalho, precisam de aceder aos serviços de back-end ou às APIs Web em nome dos utilizadores. Pode adicionar experiências personalizadas de gestão de identidades às suas aplicações nativas e chamar de forma segura os serviços de back-end com Azure AD B2C e o fluxo de código de autorização do OAuth 2.0.

Neste fluxo, a aplicação executa políticas e recebe um authorization_code de Microsoft Entra ID após o utilizador concluir a política. O authorization_code representa a permissão da aplicação para chamar serviços de back-end em nome do utilizador que tem sessão iniciada atualmente. Em seguida, a aplicação pode trocar o authorization_code em segundo plano por um access_token e um refresh_token. A aplicação pode utilizar o access_token para autenticar numa API Web de back-end em pedidos HTTP. Também pode utilizar o refresh_token para obter um novo access_token quando o antigo expira.

Daemons/aplicações do lado do servidor

As aplicações que contêm processos de execução prolongada ou que funcionam sem a presença de um utilizador também precisam de uma forma de aceder a recursos protegidos, como APIs Web. Estas aplicações podem autenticar e obter tokens com as respetivas identidades (em vez da identidade delegada de um utilizador) e com o fluxo de credenciais de cliente OAuth 2.0. O fluxo de credenciais do cliente não é o mesmo que no fluxo em nome e o fluxo em nome não deve ser utilizado para autenticação servidor a servidor.

Para Azure AD B2C, o fluxo de credenciais de cliente OAuth 2.0 está atualmente em pré-visualização pública. No entanto, pode configurar o fluxo de credenciais do cliente com Microsoft Entra ID e o ponto final plataforma de identidades da Microsoft /token (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 de tokens de Microsoft Entra.

Tipos de aplicações não suportadas

Cadeias de API Web (fluxo em-nome-de)

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

Este cenário de API web em cadeia pode ser suportado utilizando a concessão de credencial de portador do OAuth 2.0 JWT, também conhecido como fluxo em-nome-de. No entanto, o fluxo em nome de não está atualmente implementado no Azure AD B2C.

Passos seguintes

Saiba mais sobre as políticas incorporadas fornecidas pelos fluxos de utilizador no Azure Active Directory B2C.