OAuth 2.0 e OpenID Connect (OIDC) na plataforma de identidade da Microsoft

  • Artigo

Não é necessário conhecer o OAuth ou OIDC (OpenID Connect) no nível do protocolo para usar a plataforma de identidade da Microsoft. No entanto, você encontrará termos e conceitos de protocolo ao usar a plataforma de identidade e adicionar autenticação aos aplicativos. Ao trabalhar com o Centro de administração do Microsoft Entra, nossa documentação e bibliotecas de autenticação, conhecer alguns conceitos básicos pode ajudar na integração e na experiência geral.

Funções no OAuth 2.0

Há quatro partes envolvidas em uma autenticação do OAuth 2.0 e do OpenID Connect e na troca de autorização. Essas trocas são frequentemente chamadas de fluxos de autenticação ou fluxos de auth.

Diagram showing the OAuth 2.0 roles

  • 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 controla com segurança 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 os aplicativos e as APIs usam para conceder, negar ou revogar o acesso a recursos (autorização), após a entrada do usuário (autenticação).

  • Cliente – O cliente em uma troca do 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 do usuário ou uma API Web que chama outra API Web. Muitas vezes, o cliente será referido como aplicativo cliente, aplicativo ou app.

  • 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 do OAuth. O usuário final "possui" o recurso protegido (seus dados) ao qual seu aplicativo acessa em nome deles. O proprietário do recurso pode conceder ou negar ao aplicativo (o cliente) o acesso aos recursos que ele possui. Por exemplo, o aplicativo pode chamar a API de um sistema externo para obter o endereço de email de um usuário do perfil dele 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 aplicativo para acessar os 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 Web voltada para um armazenamento de dados. O servidor de recursos depende do servidor de autorização para executar a autenticação e usa as informações dos tokens de portador emitidos pelo servidor de autorização para conceder ou negar acesso aos recursos.

Tokens

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

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

  • Tokens de acesso – Os tokens de acesso são emitidos pelo servidor de autorização para o aplicativo cliente. O cliente passa os 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 o aplicativo cliente. Os clientes usam tokens de ID para entrada de usuários e para obter informações básicas sobre eles.

  • Tokens de atualização – O cliente usa um token de atualização ou RT para solicitar novos tokens de acesso e de ID do servidor de autorização. O código deve tratar os tokens de atualização e seu conteúdo de cadeia de caracteres como dados confidenciais, pois eles são destinados ao uso exclusivo do servidor de autorização.

Registro do aplicativo

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

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

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

O registro do aplicativo também contém informações sobre os pontos de extremidade de autenticação e de autorização que você usará no código para obter tokens de ID e de acesso.

Pontos de extremidade

O plataforma de identidade da Microsoft oferece serviços de autenticação e autorização que usam implementações em conformidade com padrões do OAuth 2.0 e OIDC (OpenID Connect) 1.0. Os servidores de autorização em conformidade com os padrões, como a plataforma de identidade fornecem um conjunto de pontos de extremidade HTTP para uso pelas partes em um fluxo de autenticação para executar o fluxo.

Os URIs de ponto de extremidade do aplicativo são gerados automaticamente quando você registra ou configura seu aplicativo. Os pontos de extremidade que você usa no código do aplicativo dependem do tipo do aplicativo e das identidades (tipos de conta) compatíveis.

Dois pontos de extremidade comumente usados são o ponto de extremidade de autorização e o ponto de extremidade de token. Estes são exemplos dos pontos de extremidade 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 localizar os pontos de extremidade de um aplicativo que você registrou, no Centro de administração do Microsoft Entra, navegue até:

Identidade>Aplicativos>Registros de aplicativo><SEU-APLICATIVO>>Pontos de extremidade

Próximas etapas

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

É fortemente recomendável não 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 muito mais fácil. No entanto, se seu cenário impedir que você use nossas bibliotecas ou se desejar saber mais sobre a implementação da plataforma de identidade da Microsoft, temos uma referência de protocolo: