Fluxos do OAuth 2.0 e Tipos de Tokens

O OAuth 2.0 define quatro funções. O proprietário do recurso é o usuário que possui os dados, como seus arquivos do Google Drive. O cliente é o aplicativo que solicita acesso. O servidor de autorização emite tokens de acesso, como o servidor OAuth do Google. O servidor de recursos hospeda os dados protegidos, como a API do Google Drive. Compreender essas funções esclarece o propósito de cada fluxo.

O fluxo do código de autorização é o fluxo correto para aplicativos da web no lado do servidor. O usuário se autentica no servidor de autorização, que redireciona para o cliente com um código de autorização de curta duração. O servidor do cliente troca esse código por tokens por meio de uma solicitação em um canal secundário. Os tokens nunca passam pelo navegador, o que os protege contra vazamentos no histórico do navegador e no referenciador.

O fluxo implícito foi criado para aplicativos JavaScript executados somente no navegador que não podiam armazenar segredos do cliente com segurança. Os tokens eram retornados diretamente no fragmento da URL, ignorando o canal secundário. O fluxo implícito está obsoleto no OAuth 2.1 porque o PKCE (RFC 7636) permite que clientes públicos usem o fluxo do código de autorização com segurança, sem um segredo do cliente.

O fluxo ROPC permite que os clientes coletem diretamente o nome de usuário e a senha do usuário e os troquem por tokens. Ele foi concebido para clientes próprios altamente confiáveis, mas contradiz fundamentalmente o objetivo do OAuth de impedir que os aplicativos vejam as credenciais dos usuários. Ele está obsoleto no OAuth 2.1 e não deve ser usado em nenhum aplicativo novo.

O fluxo de credenciais do cliente é destinado à autenticação máquina a máquina (M2M), quando nenhum usuário está envolvido. O cliente se autentica diretamente no servidor de autorização usando o ID e o segredo do cliente e recebe um token de acesso para uso próprio. Casos de uso comuns: tarefas em segundo plano, comunicação entre microsserviços e gateways de API acessando serviços de backend.

O fluxo de autorização do dispositivo (RFC 8628) permite usar OAuth em dispositivos com capacidades de entrada limitadas: televisores inteligentes, consoles de jogos, impressoras e dispositivos de IoT. O dispositivo exibe um código curto e uma URL. O usuário acessa a URL em um telefone ou computador para autorizar. O dispositivo consulta repetidamente o servidor de autorização até que o usuário conclua a autorização.

O OAuth 2.0 define dois tipos de tokens de acesso. Tokens opacos são sequências aleatórias que o servidor de recursos valida chamando o ponto de acesso de introspecção do servidor de autorização. Tokens de acesso JWT são autocontidos: o servidor de recursos pode validá-los localmente verificando a assinatura, reduzindo as chamadas à API de introspecção, mas exigindo gerenciamento de chaves.

Tokens de atualização são credenciais de longa duração usadas para obter novos tokens de acesso depois que o token de acesso expira. A rotação de tokens de atualização, obrigatória no OAuth 2.1 para clientes públicos, emite um novo token de atualização a cada uso e invalida o anterior. Se um token de atualização roubado for usado, o cliente legítimo detectará a invalidação, permitindo detectar o roubo do token.

O RFC 7662 define o ponto de acesso de introspecção de tokens, que permite que os servidores de recursos consultem o servidor de autorização sobre o estado atual de um token de acesso opaco — ativo ou inativo —, seu escopo, sujeito e expiração. A introspecção permite a revogação de tokens em tempo real: assim que um token é revogado no servidor de autorização, as chamadas de introspecção retornam imediatamente active: false.

O RFC 7009 define o ponto de acesso de revogação de tokens, permitindo que os clientes notifiquem o servidor de autorização de que um token, de acesso ou de atualização, deve ser invalidado. Isso é usado durante o encerramento da sessão ou quando um cliente detecta atividade suspeita. Não é possível revogar completamente tokens de acesso JWT sem uma lista de revogação, pois os servidores de recursos os validam localmente sem contatar o servidor de autorização.

Os escopos do OAuth 2.0 definem as permissões específicas solicitadas pelo cliente. O servidor de autorização apresenta os escopos solicitados ao usuário para aprovação. Os servidores de recursos impõem os requisitos de escopo por ponto de acesso. Aplica-se o princípio do menor privilégio: os clientes devem solicitar apenas os escopos mínimos necessários, e os servidores de recursos devem rejeitar solicitações com escopo insuficiente.

Qual fluxo do OAuth 2.0 é apropriado para uma ferramenta CLI ou um dispositivo de IoT que precisa autenticar um usuário, mas não tem navegador nem teclado?

O fluxo do código de autorização é o correto para aplicativos no lado do servidor. O fluxo implícito está obsoleto — use PKCE. O fluxo ROPC está obsoleto, pois elimina o objetivo do OAuth. As credenciais do cliente atendem à comunicação M2M. A autorização do dispositivo atende a dispositivos com entrada limitada. Os tokens de acesso podem ser opacos ou JWT. Os tokens de atualização devem ser rotacionados. A introspecção (RFC 7662) e a revogação (RFC 7009) completam o gerenciamento de tokens.