O que é OAuth 2.0? Fluxos, exemplo e o que testar

OAuth 2.0

Também chamado de: OAuth, OAuth2, OAuth 2, client credentials

Definição

Framework de autorização que permite a uma aplicação obter um access token limitado para chamar uma API em nome de um usuário ou de si mesma, sem lidar com senhas.

O OAuth 2.0 é um framework de autorização delegada. Em vez de entregar sua senha a um app, você aprova uma solicitação em um servidor de autorização, que emite para o app um access token (token de acesso) limitado por escopo (por exemplo, orders:read) e por tempo. O app envia esse token para a API, normalmente como Authorization: Bearer <token>. Os quatro papéis são o resource owner (o usuário), o client (o app), o authorization server (que emite os tokens) e o resource server (a API).

Autenticação versus autorização

Autenticação responde “quem é você?”. Autorização responde “o que você tem permissão para fazer?”. O OAuth 2.0, sozinho, trata de autorização: um access token diz o que o portador pode acessar, e não quem o usuário é de forma confiável. Fazer o login de usuários é tarefa do OpenID Connect, uma camada sobre o OAuth 2.0 que adiciona um ID token (um JWT) descrevendo o usuário. Os botões “Entrar com…” usam OpenID Connect.

Tipos de grant mais comuns

Authorization code com PKCE: para apps que agem em nome de um usuário, inclusive apps de navegador e mobile. O usuário faz login no servidor de autorização, o app recebe um código de curta duração e o troca por tokens.
Client credentials: para chamadas serviço a serviço, sem usuário. É o fluxo mais usado por suítes de testes de API.
Refresh token: troca um refresh token de longa duração por um novo access token.

Os grants implicit e resource owner password são desaconselhados pelas orientações de segurança atuais do OAuth e foram removidos do rascunho do OAuth 2.1.

Exemplo: client credentials

curl -X POST https://auth.example.com/oauth/token \
  -d grant_type=client_credentials \
  -d client_id="$CLIENT_ID" \
  -d client_secret="$CLIENT_SECRET" \
  -d scope=orders:read

A resposta contém um access_token, um token_type igual a Bearer e um expires_in em segundos. Obtenha o token uma vez em uma fixture, guarde-o em cache até perto de expirar e mantenha os client secrets nos secrets do CI, e não no repositório.

O que testar

Um token ausente, expirado ou malformado retorna 401.
Um token válido sem o escopo necessário retorna 403.
Tokens emitidos para outra audience ou outro client são rejeitados.
No fluxo authorization code, o parâmetro state é verificado e a redirect URI precisa corresponder exatamente a um valor registrado.
Respostas de token e redirecionamentos nunca expõem tokens em logs ou URLs.