Compartilhar via


Azure AD B2C: protocolos de autenticação

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) fornece identidade como serviço para seus aplicativos, dando suporte a dois protocolos padrão do setor: OpenID Connect e OAuth 2.0. O serviço é compatível com padrões, mas qualquer duas implementações desses protocolos podem ter diferenças sutis.

As informações neste guia serão úteis se você escrever seu código enviando e tratando diretamente solicitações HTTP, em vez de usar uma biblioteca de software livre. Recomendamos que você leia esta página antes de se aprofundar nos detalhes de cada protocolo específico. Porém, se você já estiver familiarizado com o Azure AD B2C, poderá ir direto para os guias de referência de protocolo.

Noções básicas

Cada aplicativo que usa o Azure AD B2C precisa ser registrado no diretório B2C no portal do Azure. O processo de registro do aplicativo coleta e atribui alguns valores ao seu aplicativo:

  • Uma ID do aplicativo que identifica exclusivamente seu aplicativo.

  • Um URI de redirecionamento ou identificador de pacote que pode ser usado para direcionar respostas de volta ao seu aplicativo.

  • Alguns outros valores específicos do cenário. Para obter mais informações, saiba como registrar seu aplicativo.

Depois de registrar seu aplicativo, ele se comunica com o Azure AD B2C enviando solicitações para o endpoint:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token

Se você estiver usando um domínio personalizado, substitua {tenant}.b2clogin.com pelo domínio personalizado, como contoso.com, nos pontos de extremidade.

Em quase todos os fluxos do OAuth e do OpenID Connect, quatro partes estão envolvidas na troca:

Diagrama mostrando as quatro funções OAuth 2.0.

  • O servidor de autorização é o endpoint do Azure AD B2C. Ele manipula com segurança qualquer coisa relacionada às informações e ao acesso do usuário. Ele também lida com as relações de confiança entre as partes em um fluxo. Ele é responsável por verificar a identidade do usuário, conceder e revogar o acesso aos recursos e emitir tokens. Ele também é conhecido como provedor de identidade.

  • O proprietário do recurso normalmente é o usuário final. É a parte que possui os dados e tem o poder de permitir que terceiros acessem esses dados ou recurso.

  • O cliente OAuth é seu aplicativo. Ele é identificado pela ID do aplicativo. Geralmente é a parte com a qual os usuários finais interagem. Ele também solicita tokens do servidor de autorização. O proprietário do recurso deve conceder permissão ao cliente para acessar o recurso.

  • O servidor de recursos é onde o recurso ou os dados residem. Ele confia no servidor de autorização para autenticar e autorizar com segurança o cliente OAuth. Ele também usa os tokens de acesso de portador para garantir a concessão a um recurso.

Políticas e fluxos de usuário

O Azure AD B2C estende os protocolos padrão OAuth 2.0 e OpenID Connect introduzindo políticas. Isso permite que o Azure AD B2C execute muito mais do que autenticação e autorização simples.

Para ajudá-lo a configurar as tarefas de identidade mais comuns, o portal do Azure AD B2C inclui políticas predefinidas e configuráveis chamadas fluxos de usuário. Os fluxos de usuário descrevem completamente as experiências de identidade do consumidor, incluindo inscrição, entrada e edição de perfil. Os fluxos de usuário podem ser definidos em uma interface do usuário administrativa. Eles podem ser executados usando um parâmetro de consulta especial em solicitações de autenticação HTTP.

As políticas e os fluxos de usuário não são recursos padrão do OAuth 2.0 e do OpenID Connect, portanto, você deve ter tempo para entendê-los. Para obter mais informações, consulte o guia de referência de fluxo de usuário do Azure AD B2C.

Tokens

A implementação do Azure AD B2C do OAuth 2.0 e do OpenID Connect faz amplo uso de tokens de portador, incluindo os tokens de portador representados como JWTs (tokens Web JSON). Um token de portador é um token de segurança leve que concede ao "portador" acesso a um recurso protegido.

O portador é qualquer parte que possa apresentar o token. O Azure AD B2C deve primeiro autenticar uma parte antes de poder receber um token de portador. No entanto, se as etapas necessárias não forem tomadas para proteger o token na transmissão e no armazenamento, ele poderá ser interceptado e usado por uma parte não intencional.

Alguns tokens de segurança têm mecanismos internos que impedem as partes não autorizadas de usá-los, mas os tokens de portador não têm esse mecanismo. Eles devem ser transportados em um canal seguro, como um HTTPS (segurança de camada de transporte).

Se um token de portador for transmitido fora de um canal seguro, uma parte mal-intencionada poderá usar um ataque man-in-the-middle para adquirir o token e usá-lo para obter acesso não autorizado a um recurso protegido. Os mesmos princípios de segurança se aplicam quando tokens de autenticação são armazenados ou colocados em cache para uso posterior. Sempre certifique-se de que seu aplicativo transmita e armazene tokens de portador de maneira segura.

Para obter considerações adicionais de segurança de token de portador, consulte a Seção 5 do RFC 6750.

Mais informações sobre os diferentes tipos de tokens usados no Azure AD B2C estão disponíveis na referência de token do Azure AD B2C.

Protocolos

Quando estiver pronto para examinar algumas solicitações de exemplo, você pode começar com um dos tutoriais a seguir. Cada um corresponde a um cenário de autenticação específico. Se você precisar de ajuda para determinar qual fluxo é o ideal para você, confira os tipos de aplicativos que você pode criar usando o Azure AD B2C.