The security token included in the request is invalid

TL;DR — Tes identifiants AWS sont erronés, expirés, ou le SDK lit un jeu différent de ce que tu penses. Rafraîchis/vérifie la clé d'accès + le secret (et le token de session si tu utilises des identifiants temporaires), et confirme quel profil/source le SDK utilise réellement.

Ce que ça signifie

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

AWS a rejeté tes identifiants à l'authentification — avant de vérifier les permissions. C'est différent d'AccessDeniedException, qui signifie que les identifiants sont valides mais manquent de permission. Ici, les identifiants eux-mêmes ne sont pas acceptés. Le nom de l'exception varie selon l'outil : l'AWS CLI affiche le même message sous InvalidClientTokenId, et la référence d'erreurs de DynamoDB formule son entrée UnrecognizedClientException en « The Access Key ID or security token is invalid. » — elles signifient toutes que l'authentification a échoué.

Pourquoi ça arrive

Identifiants temporaires expirés — une session STS/SSO ou un token de rôle assumé a expiré, ou tu as une clé d'accès sans le AWS_SESSION_TOKEN requis.
Clés erronées ou partielles — une faute de frappe, une clé d'accès rotée/supprimée, ou AWS_ACCESS_KEY_ID défini sans AWS_SECRET_ACCESS_KEY correspondant.
Un AWS_SESSION_TOKEN périmé laissé dans l'environnement d'une session précédente.
Pointer de vrais identifiants vers DynamoDB Local (ou inversement) — Local accepte n'importe quelles clés factices mais un vrai endpoint n'acceptera pas de placeholders.
Un décalage d'horloge sur la machine suffisamment grand pour invalider la signature de la requête.

Comment le corriger

Vérifie que les identifiants fonctionnent : aws sts get-caller-identity. Si ça échoue aussi, ce sont les identifiants, pas DynamoDB.
Rafraîchis les identifiants temporaires — relance aws sso login / réassume le rôle, et assure-toi que AWS_SESSION_TOKEN est défini pour les clés temporaires.
Efface les variables d'environnement périmées — un ancien AWS_SESSION_TOKEN/AWS_ACCESS_KEY_ID dans ton shell prime sur ton profil. Fais-en un unset ou définis le bon profil (aws configure list montre quelle source l'emporte).

Pour DynamoDB Local, utilise des identifiants placeholder et pointe vers l'endpoint local :

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

Vérifie que l'horloge de la machine est exacte (synchronisée NTP) si tout le reste paraît correct.

Tu navigues dans DynoTable ? Il résout ton profil ~/.aws à neuf à chaque connexion, donc une reconnexion ou une rotation de clés est prise en compte sans redémarrage.

Depuis DynoTable

DynoTable résout ton profil ~/.aws à neuf à chaque connexion : une reconnexion, une rotation de clés ou une variable d'environnement effacée sont donc prises en compte sans redémarrer l'app. Appuie sur ⌘P pour voir quel profil est actif et si sa pastille d'identifiants est verte — une pastille rouge veut dire Sign in (SSO) ou Reconnect avant qu'un appel de table ne puisse réussir. Pour DynamoDB Local, ajoute un profil avec l'endpoint http://localhost:8000 et des clés factices alphanumériques (vois Running DynamoDB Local) ; de vraies clés AWS face à Local déclenchent cette même erreur.

FAQ

Que signifie « The security token included in the request is invalid » ? AWS a rejeté tes identifiants à l'authentification, avant de vérifier les permissions. Les clés sont erronées, rotées ou partielles, un token de session temporaire est expiré ou périmé, ou le SDK lit une source d'identifiants différente de ce que tu penses.

Comment déboguer un token de sécurité invalide ? Lance aws sts get-caller-identity — si ça échoue aussi, ce sont les identifiants, pas DynamoDB. Rafraîchis les identifiants temporaires (aws sso login ou réassume le rôle), assure-toi que AWS_SESSION_TOKEN est défini pour les clés temporaires, et efface les variables d'environnement périmées qui priment sur ton profil.

Reproduire l'erreur

Celle-ci ne demande ni identifiants valides ni moteur local — l'authentification échoue avant l'autorisation, c'est donc le service DynamoDB réel qui répond à une clé volontairement bidon :

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

Sortie réelle :

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

Une clé structurellement invalide (not-a-key) renvoie exactement le même message, et c'est là le piège pratique : l'erreur te dit que l'identifiant a été rejeté, jamais pourquoi. Une faute de frappe, une clé d'accès supprimée, une clé du mauvais compte et une clé qui n'a jamais existé atterrissent toutes ici à l'identique. Compare avec security token expired, qui, lui, se distingue — et note l'appariement : le code sur le fil est UnrecognizedClientException alors que le message parle d'un « security token », donc chercher le message et grepper la classe dans ton handler demandent deux chaînes différentes.

Erreurs liées

AccessDeniedException — identifiants valides, permission manquante.
Missing region in config
En savoir plus : Exécuter DynamoDB Local — identifiants placeholder contre un endpoint local.

Sources

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

Reproduit le 2026-07-26 sur le service DynamoDB réel dans us-east-1 via boto3 1.43.56 — la sortie ci-dessus est reproduite telle quelle.