O que é OAuth 2.0? Delegação de acesso explicada

Toda vez que você clica em "Entrar com o Google" ou autoriza um app a acessar suas fotos sem digitar sua senha lá, você está usando OAuth 2.0. Esse protocolo resolveu um problema antigo e perigoso: como deixar um aplicativo agir em seu nome sem entregar a ele suas credenciais. Neste artigo você vai entender o que é o OAuth 2.0, seus papéis, seus principais fluxos, o papel do PKCE e por que ele é peça central da segurança em apps modernos.

O problema que o OAuth 2.0 resolve

Imagine que você quer usar um app de edição de fotos que precisa importar imagens do seu Google Fotos. Antes do OAuth, a "solução" era você entregar seu e-mail e senha do Google para esse app. Isso é desastroso: o app passa a ter acesso total à sua conta, indefinidamente, e você não tem como revogar só aquele acesso sem trocar a senha.

O OAuth 2.0, definido na RFC 6749 (Hardt, 2012), foi criado exatamente para eliminar esse antipadrão. Ele é um framework de autorização que permite a uma aplicação obter acesso limitado a recursos de um usuário, hospedados em outro serviço, sem nunca ver a senha desse usuário. Em vez de credenciais, o app recebe um token de acesso com escopo restrito e prazo de validade.

Note a palavra-chave: autorização. O OAuth 2.0 trata de o que um app pode fazer, e não diretamente de quem é o usuário. Essa distinção é tão importante que vale ler Autenticação vs autorização: qual a diferença? antes de seguir, para não confundir os conceitos.

Repare também que o OAuth se chama de framework, não de protocolo fechado. Isso é proposital: ele define papéis, fluxos e conceitos, mas deixa muitas decisões em aberto (formato do token, tempo de vida, regras de escopo). Essa flexibilidade é uma força — adapta-se a cenários muito diferentes — e também uma fonte de confusão, porque duas implementações "OAuth 2.0" podem diferir bastante nos detalhes.

Os quatro papéis do OAuth 2.0

A RFC 6749 define quatro papéis que conversam entre si. Entender quem é quem é metade do caminho:

O fluxo todo gira em torno de o cliente convencer o dono do recurso a autorizar, junto ao servidor de autorização, um acesso específico ao servidor de recursos.

Uma distinção que afeta a segurança é entre clientes confidenciais e clientes públicos. Um cliente confidencial roda em um ambiente que consegue guardar um segredo — um backend de servidor, por exemplo — e pode usar com segurança um client_secret. Um cliente público roda onde qualquer pessoa pode inspecionar o código: uma SPA no navegador, um app mobile. Ele não consegue guardar um segredo de verdade, e essa diferença é justamente o que torna o PKCE indispensável, como veremos.

Tokens, escopos e consentimento

Dois conceitos sustentam o modelo:

Quando você vê aquela tela de consentimento listando "este app quer acessar suas fotos e seu e-mail", é o escopo sendo apresentado para sua aprovação explícita. Isso dá ao usuário controle granular: você concede só o necessário e pode revogar depois.

Os tokens de acesso costumam ser implementados como JWTs, o que permite que o servidor de recursos valide o token e leia suas permissões sem precisar consultar um banco a cada requisição. Se você ainda não conhece esse formato, vale a leitura de O que é JWT (JSON Web Token)?, porque ele aparece o tempo todo dentro do OAuth.

Há ainda um terceiro token essencial: o refresh token. Como o access token tem vida curta (minutos a poucas horas) por segurança, seria péssimo pedir ao usuário para logar de novo o tempo todo. O refresh token resolve isso: ele tem vida longa, fica guardado com cuidado pelo cliente e serve para obter novos access tokens sem incomodar o usuário. Por valer muito mais — quem tem o refresh token pode renovar acesso por muito tempo — ele exige armazenamento seguro e pode ser revogado pelo servidor de autorização a qualquer momento.

Os principais fluxos (grant types)

O OAuth 2.0 oferece diferentes fluxos, chamados grant types, para cenários distintos. Os mais relevantes hoje:

Authorization Code

É o fluxo mais usado e mais seguro para aplicações web e mobile. O passo a passo:

POST /token HTTP/1.1
Host: auth.exemplo.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https://app.exemplo.com/callback
&client_id=app123
&client_secret=segredo

A separação entre código (que vai pelo navegador) e token (obtido por trás dos panos) reduz o risco de vazamento. Apps móveis e SPAs ainda adicionam o PKCE (Proof Key for Code Exchange) para se protegerem da interceptação do código.

Por que o PKCE é tão importante

O PKCE merece um olhar mais atento, porque hoje é recomendado para todos os clientes, não só os públicos. O problema que ele resolve é o seguinte: o código de autorização viaja pelo navegador ou pelo sistema operacional do celular, onde pode ser interceptado por um app malicioso registrado no mesmo esquema de redirecionamento. Se alguém rouba esse código, e o cliente é público (sem segredo), o atacante poderia trocá-lo por um token.

O PKCE fecha essa brecha com um truque criptográfico simples:

# Passo 1: requisição de autorização envia o challenge
GET /authorize?response_type=code
  &client_id=app123
  &redirect_uri=https://app.exemplo.com/callback
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

# Passo 4: troca do código envia o verifier original
POST /token
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https://app.exemplo.com/callback
&client_id=app123
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Como o atacante que interceptou o código não conhece o verifier (que nunca trafegou em claro), ele não consegue completar a troca. É elegante porque não depende de um segredo pré-compartilhado: o segredo é criado na hora, para aquele fluxo específico.

Client Credentials

Usado quando não há usuário envolvido — uma aplicação acessando outra em nome próprio, comum em integrações servidor a servidor. O cliente apresenta suas próprias credenciais e recebe um token. Aqui não há tela de consentimento nem dono de recurso humano: a "autorização" é a própria identidade da máquina cliente. É o fluxo típico para jobs em background, comunicação entre microsserviços e integrações de backend.

Device Authorization

Um fluxo desenhado para dispositivos sem teclado ou navegador decente — TVs, consoles, ferramentas de linha de comando. O dispositivo mostra um código curto e uma URL; você abre essa URL em outro aparelho (o celular), digita o código e autoriza. Enquanto isso, o dispositivo fica perguntando ao servidor se já foi autorizado. É a razão pela qual você "autoriza a TV pelo celular".

Outros fluxos

Existiram fluxos como Implicit e Resource Owner Password Credentials, mas eles caíram em desuso por motivos de segurança. O Implicit entregava o token direto na URL do navegador, exposto demais; o Password Credentials exigia que o usuário entregasse a senha ao cliente — exatamente o antipadrão que o OAuth veio combater. A recomendação atual, consolidada nas boas práticas de segurança do OAuth (OAuth 2.0 Security Best Current Practice), é usar Authorization Code com PKCE para a maioria dos casos.

OAuth 2.0 não é autenticação: entra o OpenID Connect

Aqui mora uma confusão frequente. O OAuth 2.0 cuida de autorização — ele diz que um app pode acessar certos recursos. Ele não foi projetado para provar quem é o usuário. Quando empresas usaram OAuth puro para "login social", surgiram brechas porque o protocolo não padroniza como entregar a identidade do usuário de forma segura.

A resposta foi o OpenID Connect (OIDC), uma camada de autenticação construída em cima do OAuth 2.0. O OIDC adiciona um ID token (um JWT com claims sobre o usuário, como nome e e-mail) e padroniza endpoints para descobrir a identidade. Em resumo:

Quando você clica em "Entrar com o Google", está usando OIDC sobre OAuth 2.0.

Um detalhe que evita bugs sutis: o ID token é destinado ao cliente, para que ele saiba quem fez login, enquanto o access token é destinado ao resource server. Confundir os dois é um erro comum. Usar o ID token para chamar uma API, ou tratar o access token como prova de identidade, leva a falhas de segurança. Cada token tem uma audiência (aud) e um propósito; respeitá-los é parte da implementação correta.

Onde a criptografia entra

Todo o modelo depende de canais seguros e de tokens que não possam ser forjados. As trocas de código e token devem ocorrer sobre HTTPS, e as assinaturas dos tokens dependem de algoritmos criptográficos. Para entender as bases que sustentam essa confiança, vale revisar O que é criptografia? Simétrica, assimétrica e hashing, já que conceitos como assinatura assimétrica aparecem na validação dos JWTs emitidos pelo servidor de autorização.

Na prática, o servidor de autorização publica suas chaves públicas em um endpoint conhecido (o JWKS), e o servidor de recursos usa essas chaves para verificar a assinatura do token. Assim, ninguém precisa compartilhar chaves privadas: o token é assinado uma vez e validado por quem quiser, desde que confie no emissor.

OAuth 2.0 do ponto de vista de quem constrói APIs

Se você está do lado do servidor de recursos, implementar OAuth significa: validar o access token em cada requisição, conferir os escopos exigidos pelo endpoint e rejeitar tokens expirados ou de audiência errada. Como o OAuth é a porta de entrada de muitos ataques quando mal configurado, ele deve ser tratado dentro de uma estratégia ampla, como a descrita em Segurança de APIs: protegendo seus endpoints.

Em termos concretos, a validação de um access token JWT no resource server costuma checar, na ordem:

Pular qualquer um desses passos abre uma brecha. Aceitar um token sem checar aud, por exemplo, permite que um token emitido para outra API seja reutilizado na sua — uma falha clássica de confused deputy.

E não custa lembrar: por trás de tudo isso existe uma API expondo recursos de forma estruturada. Se a própria noção de API ainda é nova para você, comece por O que é uma API? Definição clara para iniciantes e depois volte ao OAuth com a base firme.

Boas práticas ao usar OAuth 2.0

Perguntas frequentes

OAuth 2.0 serve para login? Não diretamente. OAuth cuida de autorização. Para login (autenticação), use OpenID Connect, que é construído sobre o OAuth. "Entrar com o Google" é OIDC, não OAuth puro.

Qual a diferença entre access token e refresh token? O access token é a credencial de vida curta usada para acessar a API. O refresh token tem vida longa e serve apenas para obter novos access tokens sem novo login. O refresh token é mais sensível e exige guarda mais cuidadosa.

SPAs ainda podem usar o fluxo Implicit? Não é recomendado. O Implicit foi depreciado por expor tokens na URL. A orientação atual é Authorization Code com PKCE, mesmo para aplicações que rodam inteiramente no navegador.

Preciso de client_secret numa SPA? Não — e você não deve. SPAs são clientes públicos e não conseguem guardar segredos. O PKCE substitui a necessidade do segredo, provando a posse do fluxo sem expor nada inspecionável.

OAuth 2.0 e OAuth 1.0 são compatíveis? Não. São protocolos diferentes. O 1.0 usava assinaturas em cada requisição; o 2.0 simplificou apoiando-se em HTTPS e tokens portadores (bearer). Hoje praticamente todo mundo usa 2.0.

Conclusão

O OAuth 2.0 é o framework que tornou seguro deixar aplicativos agirem em seu nome sem entregar sua senha, trocando credenciais por tokens de escopo limitado. Entender seus quatro papéis, o fluxo Authorization Code com PKCE, o papel dos refresh tokens e a diferença entre OAuth (autorização) e OpenID Connect (autenticação) é o que separa uma integração robusta de uma porta aberta para ataques. Quando bem aplicado — com validação rigorosa de tokens, escopos mínimos e redirecionamentos fixos — ele entrega controle granular ao usuário e simplicidade ao desenvolvedor, uma combinação que explica por que virou padrão da web moderna.

Referências