OAuth 2.0.

O OAuth 2.0 (RFC 6749) separa quatro papéis: o dono do recurso (utilizador), o cliente (aplicação), o servidor de autorização que emite os tokens e o servidor de recursos que aloja a API. O cliente obtém um token de acesso através de um fluxo (grant) definido — authorization code com PKCE (RFC 7636) para aplicações interativas, client credentials para chamadas serviço-a-serviço, device code (RFC 8628) para dispositivos com entrada limitada — e depois invoca a API com esse token como credencial bearer. Os scopes e as audiences delimitam o que o token pode fazer.

Recomendações de segurança e armadilhas

O RFC 9700 (BCP 240, publicado em janeiro de 2025) consolida as boas práticas de segurança do OAuth: descontinua o implicit grant e o resource owner password credentials grant, obriga ao uso de PKCE em todos os clientes de authorization code e exige a correspondência exata do redirect URI para derrotar ataques de interceção de código e de redirecionamento aberto. Como os tokens de acesso são credenciais bearer, restringi-los ao remetente com DPoP ou mutual-TLS limita a reutilização após roubo.

O abuso mais comum no mundo real é o phishing de consentimento OAuth (concessão ilícita de consentimento): em vez de roubar palavras-passe, os atacantes registam uma aplicação maliciosa e enganam os utilizadores para que aprovem scopes amplos. O worm "Google Docs" de maio de 2017 propagou-se assim em cerca de uma hora, e o APT29/Nobelium abusou repetidamente de concessões de consentimento no Microsoft 365 para persistir mesmo com MFA. As defesas incluem fluxos de consentimento administrativo, verificação do publicador, tokens de curta duração e a revogação de concessões não utilizadas.

flowchart LR
  U[Dono do recurso] -->|1 autoriza + code_challenge| AS[Servidor de autorização]
  AS -->|2 código de autorização via redirect| C[Aplicação cliente]
  C -->|3 código + code_verifier| AS
  AS -->|4 token de acesso| C
  C -->|5 token bearer| RS[Servidor de recursos / API]
  RS -->|6 dados protegidos| C