Missing Authentication Token

TL;DR — "Missing Authentication Token" bedeutet, dass die Anfrage entweder keine Credentials trug oder einen Endpoint/eine Methode traf, die AWS nicht erkennt — eine Anfrage an einen nicht existierenden Pfad oder mit einer nicht unterstützten HTTP-Methode gibt dies zurück statt einer 404. Bei DynamoDB ist es fast immer eine falsche Endpoint-URL oder eine Anfrage, die nie signiert wurde.

Was es bedeutet

{"message":"Missing Authentication Token"}

AWS' SigV4-Troubleshooting-Guide ist zur ersten Ursache unverblümt: wenn die API-Anfrage nicht signiert ist, bekommst du möglicherweise Missing Authentication Token. Kontraintuitiv kommt dieselbe Meldung auch von Endpoints im API-Gateway-Stil zurück (HTTP 403), wenn der Pfad oder die HTTP-Methode zu keiner Route passt — AWS sucht bei einer Anfrage, die es nicht routen kann, nach Auth und meldet den fehlenden Token statt eines "not found". Wenn DynamoDB selbst eine Anfrage ablehnt, deren Authorization-Header fehlt oder fehlerhaft ist, lautet die Exception MissingAuthenticationTokenException — HTTP 400, nicht wiederholbar, mit der Meldung "Request must contain a valid (registered) AWS Access Key ID."

Warum es passiert

• Falsche Endpoint-URL — https://dynamodb.<region>.amazonaws.com/some/path im Browser oder mit einem einfachen GET treffen, statt eines ordnungsgemäß signierten SDK-Aufrufs an die Service-Root.
• Unsignierte Anfrage — ein rohes curl/fetch ohne SigV4-Authorization-Header (das SDK fügt ihn normalerweise hinzu).
• Falsche HTTP-Methode — die API von DynamoDB erwartet POST an / mit einem X-Amz-Target-Header, der die Operation benennt; andere Formen werden nicht als signierte Operationen erkannt.
• Ein vertippter benutzerdefinierter Endpoint — auf eine URL zeigen, die nicht dem DynamoDB-Dienst entspricht.
• DynamoDB Local ohne konfigurierten Access Key — die SDKs verlangen, dass ein Access Key und ein Region-Wert gesetzt sind, sogar lokal (beliebige Werte funktionieren; Local verwendet sie nur, um seine Datenbankdatei zu benennen).

Wie du es behebst

1. Verwende das AWS SDK, nicht einen rohen HTTP-Aufruf. Lass das SDK den signierten POST mit dem korrekten X-Amz-Target bauen — bastle keine URLs von Hand.
2. Zeige auf die Service-Root (https://dynamodb.<region>.amazonaws.com), nicht auf einen Pfad, und setze die Region des Clients passend.
3. Bestätige, dass Credentials konfiguriert sind, damit das SDK die Anfrage tatsächlich signiert (Env-Variablen, Profil oder Rolle).
4. Für DynamoDB Local setze den Endpoint auf http://localhost:8000 und konfiguriere einen Dummy-Access-Key/-Secret (nur Buchstaben und Zahlen), damit das SDK normal signiert — Local validiert sie nicht.

Verwandte Fehler

• Unable to locate credentials — das SDK hat überhaupt keine Credentials gefunden.
• The security token included in the request is invalid — Credentials vorhanden, aber abgelehnt.
• Could not connect to the endpoint URL — ein fehlerhafter oder nicht erreichbarer Endpoint.
• Learn: Mit DynamoDB Local & LocalStack verbinden

References

• 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

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.