Conceito e mecanismo
A Lambda usa um execution role para obter permissões de acesso a serviços AWS. Define ações e recursos necessários, evitando chaves permanentes no pacote. Essa identidade técnica é diferente do utilizador que chama a aplicação. Um JWT Cognito precisa de validação antes de confiar nas claims: assinatura, emissor, validade, uso esperado e cliente ou audiência aplicável. Descodificar Base64 apenas torna o conteúdo legível. Mesmo um token válido não prova acesso a todos os relatórios. A aplicação deve relacionar identidade, contexto autorizado e recurso pedido. O tenant enviado pelo browser não é uma fonte de autoridade se não for validado contra essa identidade.
Aplicação guiada
Num portal de fundos fictício, testa que uma conta A não consegue listar, abrir nem descarregar relatórios B. O controlo deve estar no servidor, incluindo caminhos que a interface não apresenta. Se uma chamada AWS é recusada, regista a ação, recurso e identidade efetiva e investiga as políticas aplicáveis. Um Deny explícito não é ultrapassado por acrescentar outro Allow. Para partilha temporária de um objeto S3, um URL pré-assinado transporta capacidade de acesso enquanto válido e autorizado. Limita o prazo e a operação, evita logs com o URL completo e explica que a posse do link pode permitir acesso.
Uma API com JWT válido e acesso cruzado entre clientes precisa de autorização por objeto. Reduzir a validade do token pode limitar exposição temporal, mas não corrige a regra de acesso em falta.
Armadilhas comuns
Confundir autenticação com autorização; confiar em UUIDs como barreira; permissões amplas para esconder AccessDenied; URLs pré-assinados em tickets partilhados.
Tópicos relacionados: Segredos, chaves e logs úteis · Artefactos, testes e ambientes
Valida quem pede e decide a que recurso essa identidade pode aceder.
Referência: Cognito JWT verification · DVA-C02; exam guide 2.1