The security token included in the request is invalid

TL;DR — Deine AWS-Anmeldedaten sind falsch, abgelaufen, oder das SDK liest einen anderen Satz, als du denkst. Erneuere und prüfe Access Key + Secret (und den Session-Token, falls du temporäre Anmeldedaten nutzt) und stell fest, welches Profil bzw. welche Quelle das SDK tatsächlich verwendet.

Was es bedeutet

UnrecognizedClientException: The security token included in the request is invalid.

AWS hat deine Anmeldedaten bei der Authentifizierung abgelehnt — bevor Berechtigungen geprüft wurden. Das unterscheidet sich von AccessDeniedException, was bedeutet, dass die Anmeldedaten gültig sind, aber keine Berechtigung haben. Hier werden die Anmeldedaten selbst nicht akzeptiert. Der Exception-Name variiert je nach Tool: Die AWS CLI zeigt dieselbe Meldung unter InvalidClientTokenId, und DynamoDBs Fehlerreferenz formuliert ihren UnrecognizedClientException-Eintrag als "The Access Key ID or security token is invalid." — sie alle bedeuten, dass die Authentifizierung fehlgeschlagen ist.

Warum es passiert

• Abgelaufene temporäre Anmeldedaten — eine STS-/SSO-Session oder ein assumed-role-Token ist abgelaufen, oder du hast einen Access Key ohne das erforderliche AWS_SESSION_TOKEN.
• Falsche oder unvollständige Schlüssel — ein Tippfehler, ein rotierter/gelöschter Access Key oder AWS_ACCESS_KEY_ID gesetzt ohne passendes AWS_SECRET_ACCESS_KEY.
• Ein veraltetes AWS_SESSION_TOKEN, das aus einer vorherigen Session in der Umgebung verblieben ist.
• Echte Anmeldedaten auf DynamoDB Local richten (oder umgekehrt) — Local akzeptiert beliebige Dummy-Schlüssel, aber ein echter Endpoint akzeptiert keine Platzhalter.
• Uhr-Abweichung auf dem Rechner, groß genug, um die Request-Signatur ungültig zu machen.

So behebst du es

1. Verifiziere, dass die Anmeldedaten funktionieren: aws sts get-caller-identity. Wenn das ebenfalls scheitert, liegt es an den Anmeldedaten, nicht an DynamoDB.
2. Aktualisiere temporäre Anmeldedaten — führe aws sso login erneut aus / nimm die Rolle erneut an, und stelle sicher, dass AWS_SESSION_TOKEN für temporäre Schlüssel gesetzt ist.
3. Lösche veraltete Umgebungsvariablen — ein altes AWS_SESSION_TOKEN/AWS_ACCESS_KEY_ID in deiner Shell überschreibt dein Profil. Unset sie oder setze das richtige Profil (aws configure list zeigt, welche Quelle gewinnt).
4. Für DynamoDB Local verwende Platzhalter-Anmeldedaten und richte auf den lokalen Endpoint:

   const client = new DynamoDBClient({
     region: 'local',
     endpoint: 'http://localhost:8000',
     credentials: {accessKeyId: 'local', secretAccessKey: 'local'}
   });

   KopierenKopiert
5. Prüfe, dass die Rechneruhr korrekt ist (NTP-synchronisiert), falls sonst alles richtig aussieht.

Durchsuchst du deine Daten in DynoTable? Es löst dein ~/.aws-Profil bei jeder Verbindung frisch auf, sodass ein erneuter Login oder eine Schlüsselrotation ohne Neustart übernommen wird.

Über DynoTable

DynoTable löst dein ~/.aws-Profil bei jeder Verbindung frisch auf, sodass ein erneuter Login, eine Schlüsselrotation oder eine geleerte Umgebungsvariable ohne Neustart der App greift. Drück ⌘P, um zu sehen, welches Profil aktiv ist und ob sein Credential-Punkt grün ist — ein roter Punkt bedeutet Sign in (SSO) oder Reconnect, bevor irgendein Tabellenaufruf durchgeht. Für DynamoDB Local legst du ein Profil mit dem Endpunkt http://localhost:8000 und alphanumerischen Platzhalterschlüsseln an (siehe DynamoDB Local betreiben); echte AWS-Schlüssel gegen Local lösen genau diesen Fehler aus.

FAQ

Was bedeutet "The security token included in the request is invalid"? AWS hat deine Anmeldedaten bei der Authentifizierung abgelehnt, bevor Berechtigungen geprüft wurden. Die Schlüssel sind falsch, rotiert oder unvollständig, ein temporärer Session-Token ist abgelaufen oder veraltet, oder das SDK liest eine andere Credential-Quelle als du denkst.

Wie debugge ich einen ungültigen Security-Token? Führe aws sts get-caller-identity aus — wenn das ebenfalls scheitert, liegt es an den Anmeldedaten, nicht an DynamoDB. Aktualisiere temporäre Anmeldedaten (aws sso login oder die Rolle erneut annehmen), stelle sicher, dass AWS_SESSION_TOKEN für temporäre Schlüssel gesetzt ist, und lösche veraltete Umgebungsvariablen, die dein Profil überschreiben.

So reproduzierst du es

Dafür braucht es weder gültige Anmeldedaten noch eine lokale Engine — die Authentifizierung scheitert vor der Autorisierung, also antwortet der echte DynamoDB-Service auf einen absichtlich erfundenen Schlüssel:

import boto3
boto3.client(
    'dynamodb',
    region_name='us-east-1',
    aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
    aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
).list_tables()

Echte Ausgabe:

UnrecognizedClientException: The security token included in the request is invalid. [HTTP 400]

A structurally malformed key (not-a-key) returns the identical message, which is the practical trap: the error tells you the credential was rejected, never why. A typo, a deleted access key, a key from the wrong account and a key that never existed all land here identically. Compare it with security token expired, which does distinguish itself, and note the pairing — the wire code is UnrecognizedClientException während the message talks about a "security token", so searching the message and grepping your handler for the class need different strings.

Verwandte Fehler

• AccessDeniedException — gültige Anmeldedaten, fehlende Berechtigung.
• Missing region in config
• Learn: DynamoDB Local betreiben — Platzhalter-Anmeldedaten gegen einen lokalen Endpoint.

Quellen

• Troubleshooting errors for the AWS CLI — AWS CLI User Guide (verified 2026-07-13)
• Error handling with DynamoDB — Amazon DynamoDB Developer Guide (verified 2026-07-13)
• DynamoDB local usage notes — Amazon DynamoDB Developer Guide (verified 2026-07-13)

Reproduziert am 26.07.2026 gegen den Live-DynamoDB-Service in us-east-1 mit boto3 1.43.56 — die Ausgabe oben ist wortwörtlich.