Missing Authentication Token

En bref — "Missing Authentication Token" signifie que la requête ne portait aucune information d'identification ou a atteint un endpoint/méthode qu'AWS ne reconnaît pas — une requête vers un chemin inexistant ou une méthode HTTP non prise en charge renvoie ceci plutôt qu'un 404. Pour DynamoDB, c'est presque toujours une mauvaise URL d'endpoint ou une requête qui n'a jamais été signée.

Ce que ça signifie

{"message":"Missing Authentication Token"}

Le guide de dépannage SigV4 d'AWS est direct sur la première cause : si la requête API n'est pas signée, tu peux recevoir Missing Authentication Token. De façon contre-intuitive, le même message revient aussi des endpoints de type API Gateway (HTTP 403) lorsque le chemin ou la méthode HTTP ne correspond à aucune route — AWS cherche une authentification sur une requête qu'il ne peut pas router et signale le token manquant au lieu d'un « non trouvé ». Lorsque DynamoDB lui-même rejette une requête dont l'en-tête d'autorisation est absent ou malformé, l'exception est MissingAuthenticationTokenException — HTTP 400, non réessayable, avec le message « Request must contain a valid (registered) AWS Access Key ID. »

Pourquoi ça arrive

• Mauvaise URL d'endpoint — atteindre https://dynamodb.<region>.amazonaws.com/some/path dans un navigateur ou avec un simple GET, au lieu d'un appel SDK correctement signé vers la racine du service.
• Requête non signée — un curl/fetch brut sans en-tête Authorization SigV4 (le SDK l'ajoute normalement).
• Mauvaise méthode HTTP — l'API de DynamoDB attend un POST sur / avec un en-tête X-Amz-Target nommant l'opération ; les autres formes ne sont pas reconnues comme des opérations signées.
• Un endpoint personnalisé mal saisi — pointer vers une URL qui ne correspond pas au service DynamoDB.
• DynamoDB Local sans clé d'accès configurée — les SDK exigent qu'une clé d'accès et une valeur de région soient définies même en local (n'importe quelles valeurs conviennent ; Local ne s'en sert que pour nommer son fichier de base de données).

Comment le corriger

1. Utilise le SDK AWS, pas un appel HTTP brut. Laisse le SDK construire le POST signé avec le bon X-Amz-Target — ne fabrique pas les URL à la main.
2. Pointe vers la racine du service (https://dynamodb.<region>.amazonaws.com), pas un chemin, et règle la région du client pour qu'elle corresponde.
3. Vérifie que les informations d'identification sont configurées pour que le SDK signe réellement la requête (variables d'environnement, profil ou rôle).
4. Pour DynamoDB Local, règle l'endpoint sur http://localhost:8000 et configure une clé d'accès/un secret factices (lettres et chiffres uniquement) pour que le SDK signe normalement — Local ne les valide pas.

Erreurs liées

• Unable to locate credentials — aucune information d'identification trouvée par le SDK.
• The security token included in the request is invalid — informations d'identification présentes mais rejetées.
• Could not connect to the endpoint URL — un endpoint malformé ou inaccessible.
• Apprends : Se connecter à DynamoDB Local et LocalStack

Références

• Troubleshoot Signature Version 4 signing for AWS API requests — IAM User Guide
• Error handling with DynamoDB — Amazon DynamoDB Developer Guide
• Create a signed AWS API request — IAM User Guide
• DynamoDB local usage notes — Amazon DynamoDB Developer Guide

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.