Autenticação e autorização em testes de API: validações essenciais

Autenticação vs. autorização: o que validar em testes

Autenticação responde “quem é você?”: o cliente prova sua identidade (por exemplo, com uma chave, credenciais ou token). Autorização responde “o que você pode fazer?”: o servidor decide se aquele usuário/cliente tem permissão para acessar um recurso ou executar uma ação (por perfil, papel, escopo, tenant, etc.).

Em testes de API, isso vira um conjunto de validações essenciais: (1) o mecanismo de autenticação aceita credenciais válidas e rejeita inválidas; (2) as permissões são aplicadas corretamente por endpoint e por operação; (3) falhas retornam códigos e mensagens consistentes; (4) segredos não vazam em logs.

Mapa rápido de respostas esperadas (401 vs 403)

• 401 Unauthorized: a requisição não está autenticada (credencial ausente, inválida, expirada, token malformado, assinatura inválida, etc.). Normalmente inclui desafio (ex.: WWW-Authenticate) quando aplicável.
• 403 Forbidden: o cliente está autenticado, mas não tem permissão para aquela ação/recurso (escopo insuficiente, papel inadequado, política de acesso negou).

Mecanismos comuns de autenticação e como testá-los

1) API Key

Uma API key é um segredo (ou identificador secreto) enviado pelo cliente para autenticar o consumo. Pode ser enviada em header (recomendado) ou query string (evitar por exposição em logs e caches).

Exemplos comuns:

• Header dedicado: X-API-Key: <chave>
• Header custom: Authorization: ApiKey <chave> (menos comum)

Passo a passo prático: casos de teste para API Key

1. Chave válida: enviar a key correta e validar sucesso (status e corpo conforme contrato).
2. Chave ausente: omitir o header e validar 401 e payload de erro padronizado.
3. Chave inválida: enviar valor aleatório e validar 401.
4. Chave revogada: usar uma key previamente revogada (ou marcar como revogada em ambiente de teste) e validar 401.
5. Chave com escopo limitado (quando existir): key válida, mas sem permissão para endpoint sensível → validar 403.

# Exemplo (curl) com API Key em header dedicado (ajuste ao seu contrato) curl -i https://api.exemplo.com/v1/relatorios -H "X-API-Key: ${API_KEY}"

2) Basic Auth

Basic Auth envia usuário e senha codificados em Base64 no header Authorization. Importante: Base64 não é criptografia; por isso, Basic Auth deve ser usado apenas com TLS (HTTPS) e, em geral, é mais comum em integrações internas ou para obter tokens.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Formato:

Authorization: Basic base64(usuario:senha)

Passo a passo prático: casos de teste para Basic Auth

1. Credenciais válidas: validar sucesso e que o endpoint retorna o esperado.
2. Usuário/senha inválidos: validar 401.
3. Header ausente: validar 401.
4. Header malformado: por exemplo, Authorization: Basic sem credenciais → validar 401 (ou 400 se o contrato definir erro de formato; padronize e teste).
5. Proteção de endpoint sensível: garantir que endpoints administrativos não aceitam Basic Auth se a política exigir token (ou aceitam apenas para perfis específicos). Se autenticado mas sem permissão → 403.

# Exemplo (curl) com Basic Auth curl -i https://api.exemplo.com/v1/conta -u "usuario:senha"

3) Bearer Token (com noções de JWT)

Bearer token é um token enviado no header Authorization com o esquema Bearer. Quem possui o token (“bearer”) consegue acessar conforme as permissões associadas, então o token deve ser protegido.

Authorization: Bearer <token>

Um formato comum é o JWT (JSON Web Token), que geralmente tem três partes separadas por ponto: header.payload.signature. Em testes, você não precisa aprofundar criptografia; foque em validar comportamentos: expiração (exp), emissor/audiência (quando aplicável), e principalmente escopos/roles presentes no token.

Passo a passo prático: fluxo típico para obter e usar token

1. Obter token: chamar o endpoint de autenticação (ex.: /auth/token) com credenciais válidas.
2. Extrair token: do JSON de resposta (ex.: access_token).
3. Usar token: enviar em Authorization: Bearer para endpoints protegidos.
4. Validar claims relevantes (quando expostas/decodificáveis no ambiente de teste): expiração, escopos, roles, tenant.

# Exemplo (pseudo) 1) obter token POST /auth/token { "username": "ana", "password": "***" } => 200 { "access_token": "eyJ...", "expires_in": 3600 } 2) usar token GET /v1/pedidos Authorization: Bearer eyJ...

Testando autorização: permissões por perfil, papel e escopo

Autorização costuma ser expressa como:

• Roles/papéis: ex.: admin, manager, user.
• Scopes/escopos: ex.: orders:read, orders:write.
• Políticas por recurso: ex.: “usuário só acessa pedidos do próprio customerId”.
• Contexto multi-tenant: ex.: tenantId no token deve bater com o recurso.

Matriz de permissões (modelo para planejar testes)

Monte uma tabela com endpoints sensíveis e quais perfis/escopos podem executar cada operação. Isso evita lacunas e ajuda a automatizar.

Casos de teste essenciais para autorização

• Escopo insuficiente: token válido com orders:read tentando POST /orders → 403.
• Papel inadequado: usuário autenticado com role user acessando endpoint administrativo → 403.
• Isolamento por recurso: usuário A tenta acessar recurso do usuário B (IDOR) → 403 (ou 404 se a política for “não revelar existência”; defina e teste o contrato).
• Multi-tenant: token do tenant X tenta acessar recurso do tenant Y → 403/404
• Operações parciais: permitir leitura mas negar escrita no mesmo recurso (GET 200, PUT 403).

Validações do header Authorization (ausência, formato e robustez)

Grande parte dos bugs de segurança e de experiência do integrador aparece em bordas de parsing do header. Teste explicitamente:

Casos de teste: ausência e malformação

• Sem header Authorization: endpoint protegido deve retornar 401.
• Esquema errado: Authorization: Token abc quando o esperado é Bearer → 401.
• Bearer sem token: Authorization: Bearer → 401.
• Espaços extras: Authorization: Bearer <token> → deve aceitar ou rejeitar de forma consistente (defina comportamento e teste).
• Token malformado: string curta, caracteres inválidos, ou (se JWT) sem três partes → 401.
• Header duplicado: duas entradas de Authorization (quando o cliente/infra permitir) → comportamento deve ser definido (rejeitar com 400 ou escolher a primeira/última). Ideal: rejeitar para evitar ambiguidades.

# Exemplos (curl) de cenários negativos curl -i https://api.exemplo.com/v1/pedidos  # sem Authorization curl -i https://api.exemplo.com/v1/pedidos -H "Authorization: Bearer" curl -i https://api.exemplo.com/v1/pedidos -H "Authorization: Token abc"

Expiração e revogação de token: como testar

Dois comportamentos diferentes:

• Expiração: o token deixa de ser válido após um tempo (ex.: claim exp no JWT ou TTL no servidor).
• Revogação: o token é invalidado antes do tempo (logout, rotação de credenciais, comprometimento, bloqueio de usuário).

Passo a passo prático: expiração

1. Obtenha um token com curto tempo de vida (ambiente de teste pode ter TTL reduzido).
2. Use o token e valide sucesso.
3. Aguarde passar o TTL (ou avance o relógio em ambiente controlado).
4. Reenvie a mesma requisição com o token expirado.
5. Valide 401 e um erro que indique expiração (sem expor detalhes sensíveis).

Passo a passo prático: revogação

1. Obtenha um token.
2. Use o token e valide sucesso.
3. Revogue o token (endpoint de logout/revoke, rotação de segredo, desativação do usuário, ou ação administrativa no ambiente de teste).
4. Reenvie a requisição com o token revogado.
5. Valide 401 (ou o comportamento definido no contrato) e que o acesso não é permitido.

Dica de teste de regressão: se a API usa refresh tokens, valide que o access token expirado pode ser renovado apenas com refresh token válido; refresh token revogado deve falhar.

Proteção de endpoints sensíveis: o que não pode passar

Endpoints sensíveis incluem: administração de usuários, permissões, relatórios financeiros, exportações, chaves/segredos, operações destrutivas (delete), e qualquer endpoint que exponha dados pessoais.

Checklist de testes para endpoints sensíveis

• Sem autenticação → 401.
• Autenticado com perfil comum → 403.
• Autenticado com perfil correto → sucesso.
• Validação de “owner”: usuário só acessa o que é dele (ou do seu tenant).
• Operações destrutivas: exigir escopo/papel explícito (não herdar permissões amplas indevidamente).
• Evitar escalonamento: um token com permissão de leitura não deve conseguir escrever por endpoints alternativos.

Contratos de erro e segurança: o que validar na resposta

Além do status code, valide o contrato do erro:

• Corpo consistente: campos como code, message, details, traceId (se existir) devem seguir padrão.
• Sem vazamento de informação: não retornar stack trace, detalhes de validação interna de token, ou indicar se “usuário existe” em cenários de login (evitar enumeração).
• Headers esperados: quando aplicável, validar WWW-Authenticate em 401 (por exemplo, em Basic Auth) e ausência de dados sensíveis em headers.

Mascaramento de segredos em logs de teste

Automação de testes costuma registrar requests/responses para depuração. Isso é útil, mas perigoso se tokens e chaves forem logados em texto puro. A regra é: logar o suficiente para diagnosticar, mas nunca segredos.

O que deve ser mascarado

• Headers: Authorization, X-API-Key, Cookie, Set-Cookie.
• Campos de payload: password, client_secret, refresh_token, access_token.
• Parâmetros de URL (se existirem): api_key, token.

Estratégias práticas de mascaramento

• Redação total: substituir o valor por *** (mais seguro).
• Redação parcial: manter prefixo/sufixo para correlação (ex.: abcd...wxyz), útil para identificar qual credencial foi usada sem expor o segredo.
• Separar logs: logs detalhados apenas localmente; em CI, logs reduzidos.
• Evitar persistência: não salvar fixtures com tokens reais; use variáveis de ambiente e segredos do pipeline.

// Exemplo de regra de mascaramento (pseudo) function sanitize(headers, body) { redact(headers, ["authorization", "x-api-key", "cookie", "set-cookie"]) redactJsonFields(body, ["password", "client_secret", "access_token", "refresh_token"]) return { headers, body } } // Exemplo de log seguro Authorization: Bearer ***

Roteiro de suíte mínima de testes (autenticação + autorização)

Uma suíte enxuta, mas efetiva, costuma incluir:

• Autenticação: credencial válida → sucesso; ausente → 401; inválida → 401; malformada → 401/400 conforme contrato.
• Token: expirado → 401; revogado → 401; refresh (se houver) → sucesso/erro conforme cenário.
• Autorização: perfil/escopo correto → sucesso; perfil/escopo insuficiente → 403; acesso a recurso de outro usuário/tenant → 403/404 conforme política.
• Endpoints sensíveis: sempre cobertos por testes negativos (sem auth e sem permissão).
• Logs: validação indireta via revisão/checagem automatizada de que segredos não aparecem (por exemplo, varrer logs por padrões como Bearer seguido de token).