APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Autenticar um chamador não lhe concede acesso a todos os objetos. A autorização precisa de relacionar identidade, ação, recurso e contexto do tenant. Um identificador difícil de adivinhar reduz descoberta casual, mas não substitui a decisão de acesso. Valida também funções: uma pessoa com acesso de leitura a um pedido não recebe automaticamente permissão para o aprovar ou exportar toda a carteira. O nome do caminho e um botão escondido na interface não impõem essa restrição no servidor. Define testes com sujeitos e objetos de âmbitos diferentes, usando dados fictícios e ambientes próprios para validação.
Aplicação guiada
Num exemplo fictício de APS, um token é válido para relatórios mas chega ao serviço de alterações. Confirmar assinatura não basta se a audiência pretendida não corresponde ao recurso. Mesmo um token adequado continua sujeito às permissões da operação e do objeto. No browser, CORS determina quando uma resposta pode ser partilhada com código de outra origem; não substitui autorização da API. Um pedido com credenciais não pode usar wildcard como origem autorizada nesse fluxo. Se o browser falha e um cliente de backend funciona, investiga origem, preflight, headers e credenciais antes de concluir que a API está indisponível. Mantém o diagnóstico sem imprimir tokens.
Ler um objeto e aprová-lo exigem decisões de autorização próprias, mesmo com o mesmo token.
Armadilhas comuns
UUID como autorização; assinatura como audiência correta; CORS como controlo de acesso universal; interface como enforcement.
Tópicos relacionados: Recursos e contratos de API · Pedidos e resultados · Concorrência e repetição
Aplica a política no servidor e distingue-a dos controlos do browser.
Referência: API1:2023 Broken Object Level Authorization · HTTP semantics RFC9110; OpenAPI3.2.1; selected primary standards and provider contracts consulted2026-09-30