Logo Logo
GitHub Designed by Logto

O que é OAuth 2.0?

OAuth 2.0 é o padrão de facto para autorização e é amplamente utilizado na web. Permite que uma aplicação obtenha de forma segura acesso limitado a recursos protegidos em outra aplicação, como o perfil ou dados de um utilizador, sem expor credenciais como senhas.

Vamos ver um exemplo do mundo real para entender melhor. Tens uma aplicação web MyApp que quer aceder ao Google Drive do utilizador. Em vez de pedir ao utilizador para partilhar as suas credenciais do Google Drive, a MyApp pode usar OAuth 2.0 para solicitar acesso ao Google Drive em nome do utilizador. Aqui está um fluxo simplificado:

Neste fluxo, a MyApp nunca vê as credenciais do Google Drive do utilizador. Em vez disso, recebe um Token de acesso (Access token) do Google que lhe permite aceder ao Google Drive em nome do utilizador.

Componentes chave do OAuth 2.0

Para o exemplo acima, a MyApp é o Cliente , o Google é tanto o Servidor de autorização quanto o Servidor de recursos , e o utilizador é o Proprietário do recurso (Resource owner) . O fluxo envolve todos os componentes chave do OAuth 2.0:

  • Client: A aplicação que quer aceder aos recursos protegidos. “Client” e “aplicação” são frequentemente usados de forma intercambiável.
  • Resource owner: O utilizador que possui os recursos protegidos. O resource owner pode conceder (autorizar) ou negar acesso ao client.
  • Authorization server: O servidor que realiza a autorização (geralmente com autenticação) e emite access tokens para o client.
  • Resource server: O servidor que hospeda os recursos protegidos. Verifica o access token e serve os recursos protegidos para o client.

Concessões (fluxos) do OAuth 2.0

Grant constrói a base do OAuth 2.0 e define como o client pode obter um access token do authorization server. A especificação básica do OAuth 2.0 define quatro concessões:

Sem entrar nos detalhes de cada concessão, podemos esperar que estas concessões se dividam em duas categorias:

  • Concessões de autorização: Usadas quando o client precisa aceder a recursos em nome de um utilizador, ou seja, é necessária autorização do utilizador.
  • Concessão de credenciais do client: Usada quando o client precisa aceder a recursos em seu próprio nome. Esta concessão é adequada para comunicação Comunicação máquina a máquina .

Concessões de autorização

Independentemente do tipo de concessão, as concessões de autorização têm os seguintes passos comuns:

  1. O client inicia um Pedido de autorização (Authorization request) para o authorization server.
  2. O authorization server autentica o utilizador (resource owner) e pede permissão para aceder aos recursos.
  3. O utilizador concede permissão ao client.
  4. O authorization server emite um access token para o client.
  5. O client usa o access token para aceder aos recursos protegidos no Servidor de recursos .

Note que os passos e parâmetros exatos podem variar dependendo do tipo de concessão. Por exemplo, a concessão de código de autorização envolve mais passos como geração e troca de código.

Concessão de credenciais do client

A concessão de credenciais do client é muito mais simples e não envolve autorização do utilizador. Aqui está um fluxo simplificado:

  1. O client envia um Pedido de token (Token request) para o authorization server.
  2. O authorization server autentica o client e emite um access token.
  3. O client usa o access token para aceder aos recursos protegidos no Servidor de recursos .

Para discussões aprofundadas sobre concessões do OAuth 2.0, veja Concessão OAuth 2.0 (OAuth 2.0 grant) e os artigos específicos sobre concessões.

Controlo de acesso com OAuth 2.0

OAuth 2.0 define o parâmetro Scope (Scope) para especificar as permissões que o client está a solicitar. O authorization server pode ignorar total ou parcialmente os scopes solicitados e conceder acesso com base nas suas próprias políticas de controlo de acesso.

No entanto, o OAuth 2.0 deixa ao critério do authorization server como aplicar o Controlo de acesso . Isso significa que o authorization server pode decidir quais recursos o sujeito (utilizador ou client) pode aceder e quais ações podem realizar nesses recursos.

Vamos ainda usar o exemplo do Google Drive. A MyApp pode iniciar um pedido de autorização para aceder ao Google Drive de outro utilizador por engano. Neste caso, o authorization server do Google deve negar o pedido porque o utilizador não tem as permissões necessárias para aceder ao Google Drive de outro utilizador.

Outro caso é quando a MyApp recebe um access token do Google que lhe permite ler ficheiros do Google Drive do utilizador. No entanto, a MyApp tenta apagar um ficheiro em vez de lê-lo. O resource server (Google) deve negar o pedido.

Ambos os casos demonstram por que o Controlo de acesso é necessário ao implementar o OAuth 2.0. O Servidor de autorização e o Servidor de recursos devem trabalhar juntos para aplicar políticas de controlo de acesso e proteger os recursos.

Modelos de controlo de acesso

Para lidar adequadamente com o controlo de acesso, é recomendado usar os modelos padrão de controlo de acesso como Controlo de acesso baseado em funções (RBAC) e Controlo de acesso baseado em atributos (ABAC) . Estes modelos têm-se mostrado eficazes na indústria e fornecem a escalabilidade para requisitos futuros.

OAuth 2.1

OAuth 2.1 é uma atualização proposta para a especificação OAuth 2.0 que visa melhorar a segurança e a usabilidade de acordo com a experiência da indústria ao longo dos anos. Embora o OAuth 2.1 ainda não esteja finalizado, podemos aprender sobre as mudanças propostas e entender como podem afetar as implementações atuais do OAuth 2.0. O OAuth 2.1 pode ser tratado como uma formalização das melhores práticas e recomendações de segurança que foram amplamente adotadas na indústria.

OAuth 2.0 e OpenID Connect (OIDC)

OAuth 2.0 apenas define o processo de autorização e não cobre a autenticação ou identidade do utilizador. Por esta razão, o OpenID Connect (OIDC) foi introduzido como uma camada de identidade sobre o OAuth 2.0. O OIDC estende o OAuth 2.0 para fornecer autenticação do utilizador e informações de identidade na forma de Token de ID (ID token) .

O OpenID Connect estende duas concessões do OAuth 2.0 (código de autorização e implícita) para incluir ID tokens, e introduz uma nova concessão chamada fluxo híbrido que combina ambos.

Ou seja, todo o teu conhecimento e práticas de OAuth 2.0 podem ser aplicados diretamente ao OIDC; todas as extensões do OAuth 2.0, como Prova de Chave para Troca de Código (PKCE) e Indicador de recurso (Resource indicator) , podem ser usadas no OIDC também.

Veja também