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:

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

2. O servidor de Autorização autentica o Cliente e verifica se os escopos solicitados são permitidos.

3. O proprietário do recurso interage com o servidor de autorização para conceder acesso.

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

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