Azure AD B2C: Protocolos de autenticação
O Azure Active Directory B2C (Azure AD B2C) fornece identidade como serviço para as suas aplicações ao suportar dois protocolos padrão da indústria: OpenID Connect e OAuth 2.0. O serviço está em conformidade com as normas, mas quaisquer duas implementações destes protocolos podem ter diferenças subtis.
As informações neste guia são úteis se escrever o seu código ao enviar e processar diretamente pedidos HTTP, em vez de utilizar uma biblioteca de open source. Recomendamos que leia esta página antes de aprofundar os detalhes de cada protocolo específico. No entanto, se já estiver familiarizado com Azure AD B2C, pode aceder diretamente aos guias de referência do protocolo.
Noções básicas
Todas as aplicações que utilizam Azure AD B2C têm de ser registadas no diretório B2C no portal do Azure. O processo de registo de aplicação recolhe e atribui alguns valores à sua aplicação:
Uma ID de Aplicação que identifica de modo exclusivo a aplicação.
Um URI de redirecionamento ou identificador de pacote que pode ser utilizado para direcionar as respostas de volta para a sua aplicação.
Alguns outros valores específicos do cenário. Para obter mais informações, saiba como registar a sua aplicação.
Depois de registar a sua aplicação, esta comunica com Azure AD B2C ao enviar pedidos para o ponto final:
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token
Se estiver a utilizar um domínio personalizado, substitua {tenant}.b2clogin.com pelo domínio personalizado, como contoso.com, nos pontos finais.
Em quase todos os fluxos OAuth e OpenID Connect, quatro partes estão envolvidas na troca:
O servidor de autorização é o ponto final Azure AD B2C. Trata de forma segura tudo o que está relacionado com as informações e o acesso dos utilizadores. Também processa as relações de confiança entre as partes num fluxo. É responsável por verificar a identidade do utilizador, conceder e revogar o acesso aos recursos e emitir tokens. Também é conhecido como o fornecedor de identidade.
Normalmente, o proprietário do recurso é o utilizador final. É a parte proprietária dos dados e tem o poder de permitir que terceiros acedam a esses dados ou recursos.
O cliente OAuth é a sua aplicação. É identificado pelo ID da Aplicação. Normalmente, é a parte com a qual os utilizadores finais interagem. Também pede tokens do servidor de autorização. O proprietário do recurso tem de conceder permissão ao cliente para aceder ao recurso.
O servidor de recursos é onde reside o recurso ou os dados. Confia no servidor de autorização para autenticar e autorizar de forma segura o cliente OAuth. Também utiliza tokens de acesso de portador para garantir que o acesso a um recurso pode ser concedido.
Políticas e fluxos de utilizador
Azure AD B2C expande os protocolos OAuth 2.0 e OpenID Connect padrão através da introdução de políticas. Estes permitem que Azure AD B2C efetue muito mais do que a autenticação e autorização simples.
Para o ajudar a configurar as tarefas de identidade mais comuns, o portal Azure AD B2C inclui políticas predefinidas e configuráveis denominadas fluxos de utilizador. Os fluxos de utilizador descrevem totalmente as experiências de identidade do consumidor, incluindo a inscrição, o início de sessão e a edição de perfis. Os fluxos de utilizador podem ser definidos numa IU administrativa. Podem ser executados através de um parâmetro de consulta especial em pedidos de autenticação HTTP.
As políticas e os fluxos de utilizador não são funcionalidades padrão do OAuth 2.0 e do OpenID Connect, pelo que deve ter tempo para compreendê-los. Para obter mais informações, veja o guia de referência do fluxo de utilizador Azure AD B2C.
Tokens
O Azure AD implementação B2C do OAuth 2.0 e do OpenID Connect utiliza extensivamente tokens de portador, incluindo tokens de portador representados como tokens Web JSON (JWTs). 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. Azure AD B2C tem primeiro de autenticar uma parte antes de poder receber um token de portador. No entanto, se não forem tomadas as medidas necessárias para proteger o token em transmissão e armazenamento, pode ser intercetado e utilizado por uma parte não intencional.
Alguns tokens de segurança têm mecanismos incorporados que impedem as partes não autorizadas de os utilizar, mas os tokens de portador não têm este mecanismo. Têm de ser transportados num canal seguro, como um https (transport layer security).
Se um token de portador for transmitido fora de um canal seguro, uma parte maliciosa pode utilizar um ataque man-in-the-middle para adquirir o token e utilizá-lo para obter acesso não autorizado a um recurso protegido. Os mesmos princípios de segurança aplicam-se quando os tokens de portador são armazenados ou colocados em cache para utilização posterior. Certifique-se sempre de que a sua aplicação transmite e armazena tokens de portador de forma segura.
Para obter considerações de segurança de tokens de portador adicionais, consulte RFC 6750 Secção 5.
Estão disponíveis mais informações sobre os diferentes tipos de tokens utilizados no Azure AD B2C na referência de tokens Azure AD B2C.
Protocolos
Quando estiver pronto para rever alguns pedidos de exemplo, 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 o fluxo mais adequado para si, consulte os tipos de aplicações que pode criar com Azure AD B2C.