Como você protege uma REST API (autenticação, autorização, transporte)?

Question

IT Interview Practice · Accepted Answer

Proteger uma REST API significa responder três perguntas em todo request: **quem é você** (autenticação), **o que você tem permissão de fazer** (autorização), e **o canal é privado** (transporte). Como o REST é **stateless**, as credenciais precisam viajar com cada request em vez de residir em uma sessão no server.

## Transporte: sempre HTTPS

Tudo abaixo assume **TLS/HTTPS**. Sem ele, tokens e API keys viajam em texto puro (plaintext) e podem ser interceptados. Isso é inegociável — um bearer token sobre HTTP é um token vazado.

## Opções de autenticação

**API keys** — um segredo estático em um header. Simples; bom para server-to-server e para identificar uma *aplicação*, não um usuário. Fracas por si só (sem expiração, sem scope) a menos que combinadas com mais.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — o padrão para acesso **delegado** ("deixe o App X ler meus dados sem minha senha"). O app obtém um **access token** via um flow (ex. Authorization Code) e o envia como um bearer token. É assim que o "Sign in with Google" e as integrações de terceiros funcionam.

**JWT (JSON Web Token)** — um *formato* comum de token: um token assinado e autocontido que carrega claims (user id, roles, expiração). O server verifica a assinatura — sem necessidade de consultar o banco de dados, o que combina com o REST stateless.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Autorização: scopes e roles

A autenticação prova a identidade; a **autorização** decide o acesso. Os tokens carregam **scopes** (`orders:read`, `orders:write`) ou roles; o server os checa por endpoint e retorna `403 Forbidden` quando são insuficientes (vs `401` para auth ausente/inválida).

```text
Token ausente/inválido      → 401 Unauthorized
Token válido, sem scope     → 403 Forbidden
```

## Outros itens essenciais

```text
✓ Access tokens de vida curta + refresh tokens (limita o raio de dano se vazar)
✓ Rate limiting (429) para conter brute-force e abuso
✓ Valide/sanitize todo input; nunca confie no client
✓ Princípio do menor privilégio nos scopes
```

## Por que isso importa

Segurança é onde um pequeno erro vira uma brecha, então os entrevistadores usam isto para ver se você raciocina sobre ela estruturalmente em vez de recitar buzzwords. O sinal que procuram é que você **separe as três camadas** — transporte (HTTPS, sempre), autenticação (provar identidade, de forma stateless, via bearer tokens/JWT/OAuth), e autorização (scopes e menor privilégio) — e que você não as confunda, ex. usando corretamente `401` para "não autenticado" versus `403` para "autenticado mas sem permissão". Respostas fortes mostram consciência dos trade-offs práticos: JWTs são convenientes e stateless mas difíceis de revogar antes de expirarem (por isso vidas curtas mais refresh tokens), API keys identificam apps e não usuários, e o OAuth existe especificamente para que os usuários não entreguem sua senha a terceiros. Amarrar isso à statelessness do REST — credenciais em todo request, sem sessão no server — mostra que você entende *por que* a segurança de API tem a forma que tem.

Transporte: sempre HTTPS

Opções de autenticação

Autorização: scopes e roles

Outros itens essenciais

Por que isso importa

Perguntas relacionadas