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

Você não precisa conhecer o OAuth e OIDC (OpenID Connect) no nível do protocolo para usar o plataforma de identidade da Microsoft. No entanto, você encontrará esses e outros termos e conceitos de protocolo ao usar a plataforma de identidade para adicionar funcionalidade de autenticação aos seus aplicativos.

Ao trabalhar com o portal do Azure, nossa documentação e nossas bibliotecas de autenticação, conhecer alguns conceitos básicos como esses pode facilitar suas tarefas de integração e depuração.

Funções no OAuth 2.0

Normalmente, a troca de autenticação e autorização do OAuth 2.0 e do OpenID Connect envolve quatro partes. Essas trocas geralmente são chamadas de fluxos de autenticação ou fluxos de auth.

Diagram showing the OAuth 2.0 roles

  • Servidor de autorização – A própria 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 normalmente é o usuário do aplicativo ou o usuário final na terminologia do OAuth. O usuário final "possui" o recurso protegido – os dados – o aplicativo acessa em nome dele. 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 da Microsoft 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 opacos, pois 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 essa confiança é registrar o aplicativo com a plataforma de identidade no Azure AD (Azure Active Directory).

Quando você registra o aplicativo no Azure AD, a plataforma de identidade da Microsoft 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, esse valor é atribuído ao aplicativo pela plataforma de identidade da Microsoft. 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 da Microsoft, fornecem um conjunto de pontos de extremidade HTTP para que as partes usem em um fluxo de autenticação para executar o fluxo.

Os URIs de ponto de extremidade do aplicativo são gerados quando você registra ou configura o aplicativo no Azure AD. 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 encontrar os pontos de extremidade de um aplicativo que você registrou, no portal do Azure navegue até:

Azure Active Directory>Registros de aplicativo><YOUR APPLICATION>>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, temos uma referência de protocolo: