DynamoDB IncompleteSignatureException

TL;DR — A assinatura AWS Signature Versão 4 da solicitação estava incompleta ou não estava em conformidade com os padrões AWS, então DynamoDB a rejeitou antes de autenticar. Se você usar um SDK AWS, a assinatura será automática – isso quase sempre significa uma solicitação feita à mão ou um proxy/gateway que mutilou o cabeçalho Authorization após a assinatura. Deixe o SDK assinar e certifique-se de que nada reescreva a solicitação em trânsito.

O que significa

IncompleteSignatureException: The request signature does not conform to AWS standards.

AWS assina todas as solicitações com SigV4. Esta exceção significa que a assinatura estava presente, mas componentes necessários malformados ou ausentes — um cabeçalho Authorization inválido, um cabeçalho assinado ausente ou uma incompatibilidade de solicitação canônica. É um HTTP 400, do lado do cliente e não pode ser repetido no estado em que se encontra: a assinatura deve ser corrigida.

Por que isso acontece

Assinatura manual — você mesmo está construindo a assinatura SigV4 (não por meio de um SDK) e a solicitação canônica, a lista de cabeçalhos assinados ou o cabeçalho Authorization estão errados.
Um cabeçalho Authorization malformado — os gatilhos documentados são um cabeçalho vazio, um parâmetro Credential ou Signature ausente, um cabeçalho que não começa com o nome do algoritmo (AWS4-HMAC-SHA256) ou um par chave=valor sem sinal de igual.
Um proxy ou gateway API reescreveu a solicitação — a mutação do cabeçalho Authorization (ou outras partes assinadas) depois que o SDK o assinou faz com que o cabeçalho que o AWS recebe seja diferente daquele que você enviou.
Cabeçalhos editados manualmente — adicionar cabeçalhos /removing após a assinatura ou reordenar a string de consulta quebra a solicitação canônica.

Como corrigir

Use um SDK AWS oficial e deixe-o assinar a solicitação. Os SDKs implementam o SigV4 corretamente para você – a solução para quase todas as ocorrências é parar de assinar manualmente.
Não altere a solicitação após assinar — se um proxy/gateway estiver na frente, certifique-se de que ele não adicione, descarte ou reordene cabeçalhos ou altere o body/path. Assine na borda que realmente envia a solicitação.
Verifique se o cabeçalho Authorization foi alterado em trânsito — diagnóstico documentado do AWS: calcule um hash SHA-256 do cabeçalho que você enviou, codifique-o em Base64 e compare-o com o hash que algumas mensagens IncompleteSignatureException incluem. Se forem diferentes, algo entre o seu cliente e o AWS modificou o cabeçalho.
Se você precisar assinar manualmente, siga exatamente o processo de assinatura do AWS SigV4 - a solicitação canônica, a string para assinar, a derivação da chave de assinatura e o cabeçalho Authorization (algoritmo, Credential=, SignedHeaders=, Signature=) devem corresponder. Verifique em relação a uma solicitação de SDK em bom estado.

Uma chave secreta errada ou truncada é uma falha diferente: ela produz uma assinatura completa que não corresponde, aparecendo como "a assinatura que calculamos não corresponde" em vez deste erro. Da mesma forma, um relógio de máquina distorcido surge como Signature expired, e não como uma assinatura incompleta.

DynoTable + Local

O DynoTable usa o caminho de assinatura do SDK do AWS – sem SigV4 feito à mão – portanto, essa classe de erro não aparece em uso normal. Se o seu aplicativo acertar enquanto o DynoTable funciona, compare os perfis: Configurações → Perfis → Testar conexão com as mesmas teclas que seu aplicativo carrega.

Para locais, credenciais fictícias em um perfil com endpoint http://localhost:8000 ignoram totalmente a assinatura. Consulte Conectar ao AWS e Instalar. Depois que as credenciais forem resolvidas, execute uma consulta de teste de fumaça no Query Builder.

Fontes

Tratamento de erros com DynamoDB — IncompleteSignatureException (verificado em 13/07/2026)
Solucionar problemas de assinatura da versão 4 da assinatura (verificado em 13/07/2026)

FAQ

O que causa uma IncompleteSignatureException? A assinatura AWS SigV4 na solicitação estava malformada ou faltavam partes necessárias - um cabeçalho Authorization vazio ou malformado, um parâmetro Credential ou Signature ausente ou um par chave=valor sem sinal de igual. Com um SDK AWS, a assinatura é automática, então geralmente significa uma assinatura feita à mão ou um proxy que alterou a solicitação após a assinatura.

Qual a diferença entre isso e UnrecognizedClientException? IncompleteSignatureException significa que a própria assinatura estava malformada. UnrecognizedClientException ("o token de segurança é inválido") significa que a assinatura estava bem formada, mas as credenciais por trás dela não foram aceitas.

Reproduza

Envie um cabeçalho Authorization que esteja presente, mas não analisável como SigV4:

import requests
requests.post(
    'https://dynamodb.us-east-1.amazonaws.com',
    headers={
        'X-Amz-Target': 'DynamoDB_20120810.ListTables',
        'Content-Type': 'application/x-amz-json-1.0',
        'Authorization': 'AWS4-HMAC-SHA256 this-is-not-a-valid-credential-scope',
    },
    data='{}',
)

A string Base64 final é um hash do seu próprio cabeçalho, portanto, difere em cada solicitação - não corresponde a ela. O que a mensagem está dizendo é estrutural: AWS poderia ler o algoritmo, mas não os pares Credential=/SignedHeaders=/Signature= depois dele. Isso mostra como o cabeçalho foi montado, e é por isso que quase sempre vem da assinatura manual, e não de um SDK.

Erros relacionados

A assinatura da solicitação que calculamos não corresponde — uma assinatura completa, mas errada (chave secreta incorreta ou canonização).
O token de segurança incluído na solicitação é inválido — assinatura bem formada, credenciais incorretas.
O token de segurança incluído na solicitação expirou — as credenciais temporárias expiraram.
Região ausente na configuração

Referências

Última verificação em 13/07/2026 em relação à documentação oficial do AWS vinculada acima.

Reproduzido em 26/07/2026 no serviço DynamoDB ativo em us-east-1 - a saída acima é literal.

IncompleteSignatureException: Invalid key=value pair (missing equal-sign) in Authorization header (hashed with SHA-256 and encoded with Base64): 'nmoNS1XQjeE7XjC3Nzhi4KfIKrQZsBTlcf+/muyMgDs='.
HTTP 400