Partilhar via


OAuth 2.0 e OpenID Connect (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

Quatro partes geralmente estão envolvidas em uma troca 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.

Diagrama mostrando as funções do OAuth 2.0

  • 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.

Tokens

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 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 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 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 registro do seu aplicativo também contém informações sobre os pontos de extremidade de autenticação e autorização que você usará em seu código para obter tokens de ID e 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 compatíveis com 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 para seu aplicativo são gerados automaticamente quando você registra ou configura seu aplicativo. Os pontos de extremidade que você usa no código do seu aplicativo dependem do tipo do aplicativo e das identidades (tipos de conta) que ele deve suportar.

Dois pontos de extremidade comumente usados são o ponto de extremidade de autorização e o ponto de extremidade de token. Aqui estão exemplos dos pontos de authorize extremidade 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 centro de administração do Microsoft Entra, navegue para:

Aplicativos>de identidade>Registos de><aplicações Pontos finais YOUR-APPLICATION>>

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:

  • Fluxo de concessão de código de autorização - Aplicativos de página única (SPA), aplicativos móveis, aplicativos nativos (desktop)
  • Fluxo de credenciais do cliente - Processos do lado do servidor, scripts, daemons
  • Fluxo em nome de (OBO) - APIs da Web que chamam outra API da Web em nome de um usuário
  • OpenID Connect - Entrada, saída e logon único (SSO) do usuário