Autenticação e autorização são conceitos distintos que costumam ser confundidos. Essa confusão pode levar QA a descrever defeitos incorretamente e ignorar riscos reais de acesso.
- →A autenticação pergunta: “Quem é você?”
- →A autorização pergunta: “O que você tem permissão para fazer?”
Informar usuário e senha não concede acesso a todos os recursos ou ações. Por outro lado, alguns recursos podem estar disponíveis sem login, mas apenas em um modo limitado. Teste essas camadas separadamente.
Autenticação
A autenticação confirma a identidade de um usuário, serviço ou dispositivo. O sistema estabelece se o sujeito é quem afirma ser.
- →Nome de usuário e senha
- →Código de uso único
- →MFA
- →SSO
- →Token de acesso ou ID token
- →Certificado
- →Credenciais de comunicação entre máquinas
A autenticação vai além do login bem-sucedido e inclui um ciclo de vida:
- →Um usuário ou sistema apresenta uma credencial
- →O servidor a valida
- →Uma sessão é criada ou um token é emitido
- →A credencial tem um prazo de validade
- →Ela pode expirar, ser revogada, ser corrompida ou ser usada no contexto errado
Assim, as verificações de autenticação geralmente cobrem mais do que tentativas de login válidas e inválidas.
Autorização
Depois que o sistema identifica um sujeito, a autorização determina quais ações são permitidas.
- →Um usuário comum pode ver apenas os próprios pedidos
- →Um gerente pode ver os pedidos da equipe
- →Um administrador pode alterar os status dos usuários
- →Um serviço de integração pode ler dados, mas não pode excluí-los
- →Um usuário anônimo pode abrir uma página pública, mas não a área de conta pessoal
A autorização avalia permissões, papéis, políticas, propriedade e restrições de negócio, em vez da identidade.
Mesmo um usuário autenticado com sucesso pode não ter permissão para uma ação. Isso é uma camada separada de controle de acesso, não um erro de login.
Por que são confundidas
Suas falhas podem parecer semelhantes externamente.
- →O usuário não está conectado
- →Seu token expirou
- →Seu token é inválido
- →Ele está conectado, mas não tem o papel necessário
- →Ele tem o papel, mas tenta abrir um recurso de outra pessoa
- →O backend verifica o acesso incorretamente
A interface pode representar tudo isso como “acesso negado” ou “login necessário”. QA precisa distinguir os defeitos, as causas e as prioridades.
Verificações de autenticação para QA
- →Credenciais válidas permitem o login
- →Credenciais inválidas não permitem o login
- →Tokens e sessões expirados são tratados corretamente
- →O logout funciona corretamente
- →O logout invalida a sessão conforme exigido
- →O acesso não persiste por mais tempo do que o previsto
- →Lembrar de mim, refresh tokens, MFA e SSO funcionam corretamente
- →Credenciais não vazam por URLs, armazenamento local, logs ou rastros de rede
- →Logins repetidos em diferentes dispositivos ou abas se comportam corretamente
Teste todo o ciclo de vida das credenciais junto com o caminho feliz. Muitos defeitos ocorrem na renovação, expiração, revogação e reutilização de tokens ou sessões, em vez de no login inicial.
Verificações de autorização para QA
- →Usuários veem apenas os dados permitidos
- →Usuários executam apenas as ações permitidas
- →O acesso é controlado pelo backend e pela interface
- →O acesso direto por IDs não expõe recursos de outros usuários
- →Papéis não têm permissões excessivas
- →Ações de botões ocultos da interface não continuam acessíveis pela API
- →As regras são consistentes entre interfaces web, móveis e de API
- →Mudanças de papel, status ou estado do objeto não concedem permissões acidentalmente
Verificar a autorização apenas pela interface é uma armadilha comum. Um botão oculto não comprova proteção. Testes eficazes de autorização quase sempre incluem chamadas diretas à API ou, no mínimo, a inspeção das respostas do backend.
Falhas comuns
- →Substituir um ID na requisição expõe dados de outro usuário
- →O token de um usuário anterior continua funcionando após o logout
- →Uma alteração de papel na interface administrativa não entra em vigor prontamente
- →Um serviço verifica o papel, mas não a propriedade do objeto
- →O frontend mostra acesso proibido enquanto o backend executa a requisição
- →Um token de acesso permanece válido por mais tempo do que o esperado
- →Eventos críticos não revogam refresh tokens
- →Usuários anônimos recebem mais dados do que o permitido
Esses defeitos frequentemente afetam mais a qualidade e a segurança do produto do que problemas comuns de interface.
Exemplo prático
Considere um sistema de pedidos.
O usuário A faz login e abre o pedido #1001; depois, altera o ID em uma requisição de rede ou URL para #1002.
Se o sistema retorna o pedido de outro usuário, a autenticação já foi bem-sucedida. A autorização falhou porque o backend não verificou a propriedade.
Essa é uma verificação crucial para QA. O login e a emissão de tokens podem funcionar perfeitamente, mas um controle fraco de acesso aos recursos ainda deixa o produto vulnerável.
Principais conclusões para QA
- →Autenticação e autorização são camadas separadas.
- →A autenticação verifica a identidade; a autorização verifica o acesso.
- →Um login bem-sucedido não permite todas as ações.
- →Restrições da interface precisam ser aplicadas no backend para fornecer proteção confiável.
- →O acesso aos dados e às ações de outro usuário é uma área essencial de teste.
- →Teste os ciclos de vida de tokens, sessões e papéis com o mesmo cuidado dedicado ao login.
Leitura adicional
- →Nesta base de conhecimento: HTTP e HTTPS
- →Nesta base de conhecimento: JWT, OAuth 2.0 e chaves de API
- →Recurso externo: Guia de autorização da OWASP
Matriz de papéis e propriedade para um exercício local
Separe a identidade da permissão para acessar um objeto específico. No ambiente didático local, o registro 1 pertence ao usuário A e o registro 2 ao usuário B. Um usuário pode ler o próprio registro; um administrador pode ler ambos. As strings demo-user-a, demo-user-b e demo-admin são dados sintéticos de teste, não credenciais reais.
Identidade Requisição Esperado
Sem token GET /records/1 401 e WWW-Authenticate
Token desconhecido GET /records/1 401 e nenhum dado do registro
Usuário A GET /records/1 200, owner a
Usuário A GET /records/2 403, sem campos owner ou dados do registro
Usuário B GET /records/2 200, owner b
Administrador GET /records/2 200, owner b
Usuário A POST /items com corpo válido 403 e nenhum novo itemNo caso de objeto proibido, verifique o corpo da resposta e o status: um código de erro acompanhado de dados de outro usuário ainda é uma falha. Uma resposta 401 diz respeito às credenciais; uma resposta 403 significa que a operação foi recusada. Um produto real pode usar 404 para ocultar a existência do objeto; escolha as expectativas conforme seu contrato. Este ambiente usa 403 deliberadamente.
O ambiente não implementa login, verificação de JWT, expiração, revogação ou armazenamento de sessões. Teste esses mecanismos separadamente em um ambiente autorizado; rejeitar uma string desconhecida arbitrária não comprova que a expiração de tokens funciona.
Continuar aprendendo
Baixe o laboratório de prática local (ZIP)
Mecanismos de tokens e credenciais