O Que É OAuth? Funções, Fluxos, Tokens e Noções Básicas de Segurança

A API de Scrapeless Scraping usa uma chave API de conta no cabeçalho x-api-token, fornecendo um contraste concreto com o modelo de autorização delegado do OAuth.

O que é OAuth?

OAuth é uma estrutura para autorização delegada. Permite que um aplicativo solicite acesso limitado a recursos protegidos sem pedir ao usuário a senha do serviço que possui esses recursos. O usuário interage com o servidor de autorização, aprova o acesso solicitado e o cliente recebe um token em vez das credenciais primárias do usuário.

RFC 6749 define o framework de autorização OAuth 2.0. Ele descreve papéis, pontos de extremidade de protocolo, concessões de autorização, tokens de acesso e tokens de atualização. Documentos posteriores atualizam a estrutura e fornecem orientações de segurança para implementações atuais.

O OAuth também pode autorizar clientes de máquina agindo em seu próprio nome. A concessão de credenciais do cliente é projetada para um cliente confidencial acessando recursos sob uma relação de serviço estabelecida. Esse fluxo é diferente de um usuário aprovando um aplicativo de terceiros.

Os Quatro Papéis do OAuth

Uma organização pode operar tanto o servidor de autorização quanto o servidor de recursos, mas eles permanecem papéis de protocolo separados. Manter os papéis claros ajuda as equipes a colocar a validação e a política na fronteira correta.

Como Funciona o Fluxo de Código de Autorização

1. O cliente cria um pedido de autorização. Ele envia o navegador para o endpoint de autorização com um identificador de cliente, escopo solicitado, URI de redirecionamento, estado e desafio PKCE.
2. O servidor de autorização lida com a interação do usuário. Ele autentica o usuário quando necessário e exibe o acesso que está sendo solicitado.
3. O proprietário do recurso concede ou nega acesso. O consentimento e a política determinam se um código de autorização é emitido.
4. O navegador retorna ao URI de redirecionamento registrado. A resposta inclui o código de autorização e o valor do estado.
5. O cliente valida a resposta. Ele compara o estado com o valor vinculado à sessão do navegador que iniciou.
6. O cliente troca o código. Ele chama o endpoint do token com o código e o verificador PKCE; um cliente confidencial também utiliza seu método de autenticação aprovado.
7. O servidor de autorização emite tokens. A resposta geralmente inclui um token de acesso e pode incluir um token de atualização de acordo com a política do servidor.
8. O cliente chama o servidor de recursos. O servidor de recursos valida o token e aplica a política de escopo, público e nível de recurso.

O código de autorização é uma credencial intermediária, não o token final da API. Enviar o token de acesso diretamente pela resposta de autorização voltada para o navegador o expõe a mais superfícies de canal frontal. A prática atual mantém a troca do token de acesso no endpoint do token e o protege com PKCE e autenticação do cliente, quando aplicável.

O que é PKCE?

PKCE significa Proof Key for Code Exchange. O cliente gera um verificador de alta entropia para uma tentativa de autorização e envia um desafio derivado com a solicitação de autorização. Durante a troca de código, o cliente apresenta o verificador. O servidor de autorização recalcula o desafio e aceita o código somente quando os valores coincidem.

RFC 7636 define o PKCE.Foi criado para proteger os códigos de autorização interceptados de redirecionamentos de clientes públicos, e as orientações de segurança atuais aplicam amplamente a fluxos de código de autorização. Use o método de desafio seguro apoiado pelo perfil padrão em vez de uma transformação simples de verificador.

PKCE não substitui o estado. O PKCE vincula a troca de código à instância do cliente que iniciou. O estado vincula a resposta de autorização à interação do navegador e ajuda a proteger contra falsificação de solicitação entre sites e confusões no manuseio da sessão do cliente.

Tokens de Acesso e Tokens de Atualização

Um token de acesso representa a autoridade concedida a um cliente. O servidor de recursos o usa para decidir se uma solicitação pode acessar o recurso e a operação solicitados. O token pode ser opaco, exigindo introspecção ou pesquisa do lado do servidor, ou autônomo sob um perfil de token assinado definido.

Um token de atualização permite que um cliente solicite um novo token de acesso sem outra interação do usuário. Normalmente, ele é enviado apenas ao servidor de autorização, não ao servidor de recursos. Tokens de atualização são credenciais valiosas de longa duração e precisam de armazenamento protegido, vinculação ao cliente, rotação ou controles de reprodução definidos pelo servidor e suporte à revocação.

O formato do token é separado do fluxo OAuth. O OAuth não exige Tokens Web JSON. Um token de acesso opaco pode ser preferível quando a política central imediata e a revocação são importantes. Um token autônomo pode reduzir as necessidades de pesquisa, mas requer validação cuidadosa do emissor, público, assinatura, reivindicações de tempo e os algoritmos permitidos pelo perfil.

Escopos, Público e Consentimento

Um escopo é uma string definida pelo servidor de autorização que representa uma permissão ou categoria de acesso. Um cliente solicita escopos, mas o servidor pode emitir menos autoridade com base em consentimento e política. Os nomes dos escopos devem descrever capacidades significativas, em vez de refletir cada endpoint interno.

O público identifica o servidor de recursos ou conjunto de recursos pretendidos. Um token emitido para uma API não deve ser aceito por uma API não relacionada apenas porque sua assinatura é válida. Servidores de recursos devem validar o público e o emissor que esperam.

O consentimento não é um substituto para a política. Um usuário não deve ser capaz de conceder autoridade que não possui. O servidor de autorização e o servidor de recursos ainda aplicam restrições de inquilinos, função, propriedade, risco e nível de recurso.

Clientes Públicos e Confidenciais

Um cliente confidencial pode proteger credenciais por meio de um ambiente controlado por seu operador, como um serviço de backend. Um cliente público opera onde um segredo não pode ser mantido, como um navegador ou aplicativo instalado distribuído para usuários. Enviar o mesmo segredo de cliente em cada cópia de um aplicativo público não torna essas cópias confidenciais.

Clientes públicos dependem do PKCE, manuseio exato de redirecionamentos, proteções de plataforma e autoridade de token limitada, em vez de um segredo embutido compartilhado. Clientes confidenciais usam um método de autenticação aprovado pelo servidor de autorização no endpoint do token e devem proteger essas credenciais através de um ciclo de vida de segredo.

OAuth vs Chaves de API

Uma chave de API geralmente identifica um cliente ou projeto diretamente. Funciona bem para um relacionamento controlado de servidor para servidor onde o proprietário da conta provisiona a credencial. O OAuth adiciona um protocolo para obtenção de tokens sob uma concessão, incluindo acesso delegado de usuário com consentimento e escopos.

Use uma chave de API quando um serviço de backend acessar sua própria conta e o modelo de chave do provedor oferecer restrições adequadas. Use OAuth quando clientes de terceiros precisarem de acesso delimitado em nome dos usuários, quando permissões precisarem de revocação independente ou quando um ecossistema exigir fluxos de autorização padronizados.

Nenhuma opção é automaticamente segura. Chaves de API precisam de armazenamento protegido e restrições. OAuth precisa de validação correta de endpoint, manuseio de redirecionamento, validação de token, design de escopo e decisões sobre o tipo de cliente.

OAuth vs OpenID Connect

O OAuth autoriza o acesso a recursos. Ele não define uma declaração padrão que o cliente possa tratar como a identidade de login do usuário. O OpenID Connect adiciona uma camada de autenticação em cima do OAuth e introduz o token ID, uma afirmação assinada sobre o evento de autenticação e sujeito.

Um cliente não deve tratar um token de acesso OAuth arbitrário como prova de login. Para entrar, use um fluxo OpenID Connect e valide o token ID de acordo com os metadados e perfil do provedor, incluindo emissor, público, assinatura, reivindicações de tempo, nonce quando usado e o vínculo da resposta de autorização.

Orientações de Segurança do OAuth Atuais

A RFC 9700 fornece as melhores práticas atuais de segurança do OAuth 2.0. Ele atualiza a orientação de implementação com base em ataques e experiências de implementação. Novos sistemas devem usar fluxos de código de autorização com PKCE, correspondência exata de URI de redirecionamento, interação segura com o navegador e transporte de token protegido.

A concessão implícita expõe tokens de acesso através da resposta de autorização e não é o design preferido para novos clientes. A concessão de credenciais de senha do proprietário do recurso pede a um cliente que manipule a senha do usuário e não deve ser usada. Esses padrões mais antigos podem aparecer em sistemas legados, mas copiá-los para uma nova implementação descarta limites mais fortes.

Erros comuns do OAuth

• Chamando a autenticação OAuth. OAuth autoriza o acesso à API; use OpenID Connect para uma camada de identidade de login padrão.
• Correspondência solta de URI de redirecionamento. Aceite apenas URIs de redirecionamento exatos registrados de acordo com as regras do perfil.
• Ignorando a validação do estado. Vincule a resposta à sessão do navegador que iniciou e rejeite incompatibilidades.
• Omitindo PKCE. Clientes de código de autorização devem usar um novo verificador e um desafio seguro para cada solicitação.
• Aceitando qualquer token assinado. Servidores de recursos devem validar emissor, público, tipo ou perfil, tempo, assinatura e reivindicações de autorização.
• Escopos excessivos. Solicite e emita a menor autoridade útil.
• Colocando tokens em URLs. Use cabeçalhos de autorização sobre HTTPS para reduzir o vazamento através de logs e superfícies do navegador.

Casos de Uso do OAuth

Lista de Verificação de Implementação

1. Escolha a concessão para o cliente e caso de uso. A delegação interativa do usuário e o acesso ao serviço têm diferentes limites de confiança.
2. Registre URIs de redirecionamento exatos. Separe ambientes e evite redirecionadores abertos.
3. Use código de autorização com PKCE. Gere um novo verificador e valor de estado para cada solicitação de autorização.
4. Valide cada resposta. Verifique o estado, metadados do emissor onde aplicável, ligação de código e campos de resposta do token.
5. Proteja tokens. Mantenha-os fora de URLs e logs, armazene-os pelo menor período necessário e use padrões de armazenamento seguro no navegador ou servidor.
6. Imponha no servidor de recursos. Valide o perfil do token, emissor, público, expiração, escopo e política em nível de recurso.
7. Planeje revogação e manuseio de incidentes. Usuários e administradores precisam de uma maneira de remover concessões e desabilitar credenciais comprometidas.

Conclusão

OAuth separa as credenciais primárias de um usuário ou serviço dos tokens limitados que um cliente usa em uma API. Seus papéis, concessões, escopos e pontos finais criam um limite de autorização padrão, mas o protocolo ainda depende de uma implementação precisa. Código de autorização com PKCE, redirecionamentos exatos, tokens emitidos de forma estrita, validação correta do servidor de recursos e OpenID Connect para login fornecem uma base sólida para sistemas atuais.