Azure AD B2C: Protocolos de autenticação

O Azure Ative Directory B2C (Azure AD B2C) fornece identidade como um 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 os padrões, mas quaisquer duas implementações desses protocolos podem ter diferenças sutis.

As informações neste guia são úteis se você escrever seu código enviando e manipulando solicitações HTTP diretamente, em vez de usar uma biblioteca de código aberto. Recomendamos que você leia esta página antes de mergulhar nos detalhes de cada protocolo específico. Mas 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

Todos os aplicativos que usam o Azure AD B2C precisam ser registrados em seu diretório B2C no portal do Azure. O processo de registro do aplicativo coleta e atribui alguns valores ao seu aplicativo:

• Uma ID de aplicativo que identifica exclusivamente seu aplicativo.

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

• Alguns outros valores específicos do cenário. Para mais informações, saiba como registar a sua candidatura.

Depois de registar a sua aplicação, ela comunica-se com o Azure AD B2C enviando solicitações para o ponto de extremidade:

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 OAuth e OpenID Connect, quatro partes estão envolvidas na troca:

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

• Normalmente, o proprietário do recurso é o usuário final. É a parte proprietária dos dados e tem o poder de permitir que terceiros acessem esses dados ou recursos.

• O cliente OAuth é o seu aplicativo. Ele é identificado por seu ID de aplicativo. Geralmente é com a entidade que os utilizadores 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 tokens de acesso ao portador para garantir que o acesso a um recurso possa ser concedido.

Políticas e fluxos de usuários

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 simples autenticação e autorização.

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, login 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.

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

Símbolos

A implementação do Azure AD B2C do OAuth 2.0 e do OpenID Connect faz uso extensivo de tokens de portador, incluindo tokens de portador representados como tokens JSON da Web (JWTs). Um token ao 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. Mas se as medidas necessárias não forem tomadas para proteger o token na transmissão e armazenamento, ele pode ser intercetado e usado por uma parte não intencional.

Alguns tokens de segurança têm mecanismos integrados que impedem que partes não autorizadas os utilizem, mas os tokens ao portador não têm esse mecanismo. Eles devem ser transportados em um canal seguro, como a segurança da camada de transporte (HTTPS).

Se um token de portador for transmitido fora de um canal seguro, uma parte mal-intencionada pode 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 os tokens de autenticação são armazenados ou em cache para uso posterior. Certifique-se sempre de que seu aplicativo transmita e armazene tokens de portador de maneira segura.

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

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 analisar alguns exemplos de pedidos, pode começar com um dos seguintes tutoriais. Cada um corresponde a um cenário de autenticação específico. Se precisar de ajuda para determinar qual fluxo é ideal para você, confira os tipos de aplicativos que você pode criar usando o Azure AD B2C.

• Crie aplicativos móveis e nativos usando o OAuth 2.0
• Crie aplicativos Web usando o OpenID Connect