OAuth 2.0

OAuth 2.0 é o protocolo padrão para autorização delegada — permitir que um aplicativo de terceiros acesse recursos que você controla em outro serviço sem entregar sua senha. “Entrar com o Google,” “Conectar sua conta GitHub,” “Conceder acesso do Zapier ao seu Gmail” — todos usam OAuth.

Os quatro papéis: proprietário do recurso (o usuário), cliente (o aplicativo de terceiros), servidor de autorização (o serviço emissor de OAuth, por exemplo, accounts.google.com), servidor de recursos (a API que o cliente quer chamar, por exemplo, gmail.googleapis.com).

O fluxo mais comum (código de autorização com PKCE):

1. O cliente redireciona o usuário para o servidor de autenticação.
2. O usuário faz login e aprova os escopos solicitados.
3. O servidor de autenticação redireciona de volta com um código de autorização de uso único.
4. O cliente troca o código (mais o verificador PKCE) por um token de acesso.
5. O cliente chama o servidor de recursos com o token de acesso.

OAuth 2.0 é apenas autorização. OpenID Connect (OIDC) é a camada de autenticação sobre ele — adiciona um token de ID (um JWT com claims sobre quem é o usuário) para que o cliente saiba quem fez login, não apenas “algum usuário autorizado.” A maioria dos fluxos modernos “Entrar com X” são OIDC, não OAuth puro.

Por que o PKCE é agora obrigatório para clientes públicos: o fluxo original de código de autorização do OAuth 2.0 presumia que o cliente poderia guardar um segredo. Aplicativos móveis e aplicativos de página única não podem — qualquer pessoa pode desmontar o aplicativo e extrair o segredo embutido. PKCE (Proof Key for Code Exchange, RFC 7636) substitui o segredo estático do cliente por um verificador aleatório por fluxo com hash via SHA-256: o cliente envia o hash antecipadamente e revela o texto simples somente ao trocar o código, provando que é o mesmo cliente que iniciou o fluxo. PKCE agora é exigido para todos os clientes públicos (OAuth 2.1, RFC 9700 BCP) e recomendado para clientes confidenciais também como defesa em profundidade.

Os quatro fluxos que você deve conhecer e os dois que deve evitar: use Código de Autorização + PKCE para quase tudo (web, mobile, SPA). Use Client Credentials para chamadas de API máquina a máquina onde não há usuário presente. O fluxo Implícito (retorna tokens de acesso diretamente em fragmentos de URL) e o fluxo Resource Owner Password Credentials (o cliente coleta a senha diretamente) estão ambos obsoletos no OAuth 2.1 — nenhum protege adequadamente contra ataques modernos. Qualquer nova integração OAuth deve rejeitar esses fluxos mesmo que um fornecedor os ofereça. Relacionado: JWT, SAML. Referência: RFC 6749 — OAuth 2.0, RFC 7636 — PKCE.

Exemplo prático

Um botão “Conectar Slack” em seu SaaS aciona um redirecionamento para https://slack.com/oauth/v2/authorize?client_id=...&scope=chat:write,channels:read&redirect_uri=https://app.example.com/oauth/callback&state=xyz&code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256. O usuário aprova; o Slack redireciona para https://app.example.com/oauth/callback?code=ONE_TIME_CODE&state=xyz. Seu backend faz um POST para https://slack.com/api/oauth.v2.access com o código, o verificador PKCE original e o ID do cliente. O Slack retorna {"access_token": "xoxb-...", "scope": "chat:write,channels:read", "team": {"id": "T123"}}. Você armazena o token de acesso no lado do servidor (nunca no armazenamento local do navegador) e o usa como Authorization: Bearer xoxb-... nas chamadas subsequentes à API do Slack. Toda a troca leva algumas centenas de milissegundos; o usuário vê uma tela de consentimento e nunca digita uma senha do Slack em seu aplicativo.

Quando e por que isso importa

As configurações incorretas do OAuth são uma das categorias mais exploradas na segurança web moderna. Modos de falha comuns: não validar o parâmetro state (habilita CSRF no callback), permitir curingas no registro do redirect_uri (habilita roubo de token via redirecionamento aberto), armazenar tokens de acesso em armazenamento acessível ao navegador (exfiltração via XSS) e tratar tokens de atualização como tokens de portador de longa duração em vez de rotacioná-los a cada uso. A OAuth 2.0 Security Best Current Practice (RFC 9700, publicada em 2025) codifica os padrões modernos: PKCE em todos os lugares, URIs de redirecionamento com correspondência exata, tokens vinculados ao remetente (DPoP ou mTLS) para APIs de alto valor, e rotação de token de atualização com detecção de reutilização. Seguir essas práticas transforma a maioria das descobertas de pentest em OAuth em não-problemas. Referência: RFC 9700 — OAuth 2.0 Security BCP.