OAuth 2.0, que significa "Autorização Aberta", é um padrão projetado para permitir que um site ou aplicativo acesse recursos hospedados por outros aplicativos da web em nome de um usuário. Ele substituiu o OAuth 1.0 em 2012 e agora é o padrão de fato do setor para autorização online. O OAuth 2.0 fornece acesso consentido e restringe ações quanto ao que o aplicativo cliente pode executar em recursos em nome do usuário, sem nunca compartilhar as credenciais do usuário.
Embora a web seja a principal plataforma para o OAuth 2, a especificação também descreve como lidar com esse tipo de acesso delegado a outros tipos de clientes (aplicativos baseados em navegador, aplicativos da web do lado do servidor, aplicativos nativos/móveis, dispositivos conectados, etc.)
O OAuth 2.0 é um protocolo de autorização e NÃO um protocolo de autenticação. Como tal, ele foi projetado principalmente como um meio de conceder acesso a um conjunto de recursos, por exemplo, APIs remotas ou dados do usuário.
O Oauth 2.0 usa tokens de acesso. Um token de acesso é um dado que representa a autorização para acessar recursos em nome do usuário final. O OAuth 2.0 não define um formato específico para tokens de acesso. No entanto, em alguns contextos, o formato JSON Web Token (JWT) é frequentemente usado. Isso permite que os emissores de token incluam dados no próprio token. Além disso, por razões de segurança, os tokens de acesso podem ter uma data de validade.
A ideia de funções é parte da especificação central do framework de autorização do OAuth2.0. Elas definem os componentes essenciais de um sistema OAuth 2.0 e são:
Proprietário do recurso: o usuário ou sistema que possui os recursos protegidos e pode conceder acesso a eles.
Cliente: o cliente é o sistema que requer acesso aos recursos protegidos. Para acessar recursos, o Cliente deve ter o token de acesso apropriado.
Servidor de autorização: este servidor recebe solicitações do Cliente para tokens de acesso e os emite mediante autenticação e consentimento bem-sucedidos do proprietário do recurso. O servidor de autorização expõe dois endpoints: o endpoint de Autorização, que lida com a autenticação e o consentimento interativos do usuário, e o endpoint de Token, que está envolvido em uma interação máquina a máquina.
Servidor de recursos: um servidor que protege os recursos do usuário e recebe solicitações de acesso do Cliente. Ele aceita e valida um token de acesso do cliente e retorna os recursos apropriados para ele.
Os escopos são um conceito importante no OAuth 2.0. Eles são usados para especificar exatamente a razão pela qual o acesso aos recursos pode ser concedido. Valores de escopo aceitáveis e com quais recursos eles se relacionam dependem do servidor de recursos.
O servidor de autorização OAuth 2 não pode retornar diretamente um token de acesso após o proprietário do recurso ter autorizado o acesso. Em vez disso, e para melhor segurança, um código de autorização pode ser retornado, que é trocado por um token de acesso. Além disso, o servidor de autorização também pode emitir um token de atualização com o token de acesso. Ao contrário dos tokens de acesso, os tokens de atualização normalmente têm validade longa e podem ser trocados por novos tokens de acesso após a expiração. Como os tokens de atualização têm essas propriedades, eles devem ser armazenados com segurança pelos clientes.
No nível mais básico, antes que o OAuth 2.0 possa ser usado, o Cliente deve adquirir suas próprias credenciais, uma id do cliente e um client secret, do servidor de autorização para se identificar e autenticar ao solicitar um token de acesso.
Usando o OAuth 2.0, as solicitações de acesso são iniciadas pelo Cliente, por exemplo, um aplicativo móvel, site, aplicativo de TV inteligente, aplicativo de desktop, etc. A solicitação, a troca e a resposta do token seguem este fluxo geral:
O Cliente solicita autorização (solicitação de autorização) do servidor de Autorização, fornecendo a ID e o segredo do cliente como identificação; ele também fornece os escopos e um URI de endpoint (URI de redirecionamento) para enviar o token de acesso ou o código de autorização.
O servidor de Autorização autentica o Cliente e verifica se os escopos solicitados são permitidos.
O proprietário do recurso interage com o servidor de autorização para conceder acesso.
O servidor de autorização é redirecionado de volta para o cliente com um código de autorização ou token de acesso, dependendo do tipo de concessão, como será explicado na próxima seção. Um token de atualização também pode ser retornado.
Com o token de acesso, o cliente solicita acesso ao recurso a partir do servidor de recursos.
No OAuth 2.0, concessões são o conjunto de etapas que um Cliente deve executar para obter a autorização de acesso a recursos. A estrutura de autorização fornece vários tipos de concessão para abordar diferentes cenários:
Concessão de código de autorização: O servidor de autorização retorna um código de autorização de uso único para o cliente, que é trocado por um token de acesso. Esta é a melhor opção para aplicativos da web tradicionais onde a troca pode acontecer com segurança no lado do servidor. O fluxo do código de autorização pode ser usado por aplicativos de página única (SPA) e aplicativos móveis/nativos. No entanto, aqui, o client secret não pode ser armazenado de forma segura e, portanto, a autenticação, durante a troca, é limitada ao uso da id do cliente sozinha. Uma alternativa melhor é a concessão de código de autorização com PKCE, abaixo.
Concessão implícita: Um fluxo simplificado onde o token de acesso é devolvido diretamente para o Cliente. No fluxo implícito, o servidor de autorização pode retornar o token de acesso como um parâmetro no URI de retorno de chamada ou como uma resposta a uma publicação de formulário. A primeira opção agora está obsoleta devido a um possível vazamento de token.
Concessão de código de autorização com chave de prova para troca de código (PKCE): Esse fluxo de autorização é semelhante à concessão de código de autorização, mas com etapas adicionais que o tornam mais seguro para aplicativos e SPAs móveis/nativos.
Tipo de concessão de credenciais do proprietário de recursos: Essa concessão requer que o Cliente primeiro adquira as credenciais do proprietário do recurso, que são passadas para o servidor de Autorização. É, portanto, limitado a Clientes que são completamente confiáveis. Ele tem a vantagem de não envolver nenhum redirecionamento para o servidor de autorização; portanto, é aplicável nos casos de uso em que um redirecionamento é inviável.
Tipo de concessão de credenciais do cliente: Usado para aplicações não interativas, como processos automatizados, microsserviços, etc. Neste caso, o aplicativo é autenticado por si mesmo, usando a ID e o client secret.
Fluxo de autorização do dispositivo: Uma concessão que permite o uso por aplicativos em dispositivos com restrição de entrada, como TVs inteligentes.
Concessão de tokens de atualização: O fluxo que envolve a troca de um token de atualização por um novo token de acesso.
Continue lendo a Introdução ao IAM para conhecer outros tópicos sobre a Gestão de Identidades e Acesso.
Table of contents
Obtenha o guia para o Oauth 2.0
Faça download do guia do Oauth 2.0 e do OpenID Connect.
Download do ebookQuick assessment
No OAuth 2, qual tipo de fluxo/concessão de autorização é melhor para usar com um aplicativo da web tradicional?
Quick assessment
Em uma solicitação de autorização do OAuth2, além da ID do cliente, o que também é enviado para o servidor de autorização?