Fluxo de autenticação OAuth 2.0 e OIDC na plataforma de identidade da Microsoft

Saber sobre OAuth ou OpenID Connect (OIDC) no nível de protocolo não é necessário para usar a plataforma de identidade da Microsoft. No entanto, você encontrará termos e conceitos de protocolo ao usar a plataforma de identidade para adicionar autenticação aos seus aplicativos. À medida que você trabalha com o centro de administração do Microsoft Entra, nossa documentação e bibliotecas de autenticação, conhecer alguns fundamentos pode ajudar sua integração e experiência geral.

Funções no OAuth 2.0

Normalmente, quatro partes intervêm num processo de autenticação e autorização OAuth 2.0 e OpenID Connect. Essas trocas são frequentemente chamadas de fluxos de autenticação ou fluxos de autenticação.

Captura de tela de um diagrama mostrando as funções no OAuth 2.0, incluindo servidor de autorização, cliente, proprietário do recurso e servidor de recursos

  • Servidor de autorização - A plataforma de identidade da Microsoft é o servidor de autorização. Também chamado de provedor de identidade ou IdP, ele lida com segurança com as informações do usuário final, seu acesso e as relações de confiança entre as partes no fluxo de autenticação. O servidor de autorização emite os tokens de segurança que seus aplicativos e APIs usam para conceder, negar ou revogar o acesso a recursos (autorização) depois que o usuário entra (autenticado).

  • Cliente - O cliente em uma troca OAuth é o aplicativo que solicita acesso a um recurso protegido. O cliente pode ser um aplicativo Web em execução em um servidor, um aplicativo Web de página única em execução no navegador da Web de um usuário ou uma API da Web que chama outra API da Web. Muitas vezes, você verá o cliente referido como aplicativo cliente, aplicativo ou aplicativo.

  • Proprietário do recurso - O proprietário do recurso em um fluxo de autenticação geralmente é o usuário do aplicativo ou usuário final na terminologia OAuth. O usuário final "possui" o recurso protegido (seus dados) que seu aplicativo acessa em seu nome. Os proprietários dos recursos podem conceder ou negar ao seu aplicativo (o cliente) acesso aos recursos que possuem. Por exemplo, seu aplicativo pode chamar a API de um sistema externo para obter o endereço de e-mail de um usuário de seu perfil nesse sistema. Os dados de perfil são um recurso que o usuário final possui no sistema externo, e o usuário final pode consentir ou negar a solicitação do seu aplicativo para acessar seus dados.

  • Servidor de recursos - O servidor de recursos hospeda ou fornece acesso aos dados do proprietário de um recurso. Na maioria das vezes, o servidor de recursos é uma API da Web em frente a um armazenamento de dados. O servidor de recursos depende do servidor de autorização para executar a autenticação e usa informações em tokens de portador emitidos pelo servidor de autorização para conceder ou negar acesso aos recursos.

Símbolos

As partes em um fluxo de autenticação usam tokens de portador para garantir, verificar e autenticar uma entidade (usuário, host ou serviço) e para conceder ou negar acesso a recursos protegidos (autorização). Os tokens de portador na plataforma de identidade da Microsoft são formatados como JSON Web Tokens (JWT).

Três tipos de tokens ao portador são utilizados pela plataforma de identidade como tokens de segurança:

  • Testemunhos de acesso - Os testemunhos de acesso são emitidos pelo servidor de autorização à aplicação cliente. O cliente passa tokens de acesso para o servidor de recursos. Os tokens de acesso contêm as permissões que o cliente recebeu do servidor de autorização.

  • Tokens de ID - Os tokens de ID são emitidos pelo servidor de autorização para a aplicação cliente. Os clientes usam tokens de ID ao entrar em usuários e para obter informações básicas sobre eles.

  • Atualizar tokens - O cliente usa um token de atualização, ou RT, para solicitar novos tokens de acesso e ID do servidor de autorização. Seu código deve tratar os tokens de atualização e seu conteúdo de cadeia de caracteres como dados confidenciais porque eles se destinam a ser usados apenas pelo servidor de autorização.

Registo de aplicações

Seu aplicativo cliente precisa de uma maneira de confiar nos tokens de segurança emitidos para ele pela plataforma de identidade da Microsoft. A primeira etapa para estabelecer confiança é registrando seu aplicativo. Quando você registra seu aplicativo, a plataforma de identidade atribui automaticamente alguns valores, enquanto outros você configura com base no tipo do aplicativo.

Duas das configurações de registro de aplicativo mais comumente referenciadas são:

  • ID do aplicativo (cliente) - Também chamado de ID do aplicativo e ID do cliente, esse valor é atribuído ao seu aplicativo pela plataforma de identidade. O ID do cliente identifica exclusivamente seu aplicativo na plataforma de identidade e está incluído nos tokens de segurança que a plataforma emite.
  • URI de redirecionamento - O servidor de autorização usa um URI de redirecionamento para direcionar o agente de usuário do proprietário do recurso (navegador da Web, aplicativo móvel) para outro destino depois de concluir sua interação. Por exemplo, depois que o usuário final se autentica com o servidor de autorização. Nem todos os tipos de cliente usam URIs de redirecionamento.

O registo da sua aplicação também inclui informações sobre os pontos finais de autenticação e autorização que utilizará no seu código para obter tokens de ID e de acesso.

Pontos finais

A plataforma de identidade da Microsoft oferece serviços de autenticação e autorização usando implementações compatíveis com os padrões do OAuth 2.0 e OpenID Connect (OIDC) 1.0. Servidores de autorização em conformidade com as normas, como a plataforma de identidade, fornecem um conjunto de pontos finais HTTP para serem utilizados pelas partes intervenientes num fluxo de autenticação para o executarem.

Os URIs do ponto final da sua aplicação são gerados automaticamente ao registar ou configurar a sua aplicação. Os pontos finais que utiliza no código da sua aplicação dependem do tipo de aplicação e das identidades (tipos de conta) que esta deve suportar.

Dois endpoints normalmente utilizados são o endpoint de autorização e o endpoint de token. Aqui estão exemplos dos endpoints authorize e token:

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or domain name.

Para encontrar os pontos finais de uma aplicação que registou, no centro de administração do Microsoft Entra, navegue até:

Entra ID>Registos de Aplicações><> YOUR-APPLICATION>

Para uma referência consolidada de todos os endpoints OIDC (descoberta, autorização, token, UserInfo, JWKS, logout), consulte OpenID Connect na plataforma de identidades da Microsoft.

Próximos passos

Em seguida, saiba mais sobre os fluxos de autenticação OAuth 2.0 usados por cada tipo de aplicativo e as bibliotecas que você pode usar em seus aplicativos para executá-los:

É altamente desaconselhável criar sua própria biblioteca ou chamadas HTTP brutas para executar fluxos de autenticação. Uma Biblioteca de Autenticação da Microsoft é mais segura e fácil. No entanto, se o seu cenário o impedir de usar nossas bibliotecas ou se você quiser saber mais sobre a implementação da plataforma de identidade da Microsoft, temos referência de protocolo:

  • Last updated on