The security token included in the request is expired

TL;DR — Tes identifiants AWS temporaires ont expiré. Cela n'arrive qu'avec des identifiants STS/SSO/rôle assumé (pas les clés d'utilisateur IAM à longue durée de vie). Rafraîchis la session — relance aws sso login ou réassume le rôle — assure-toi que AWS_SESSION_TOKEN est le nouveau, et efface tout token périmé laissé dans l'environnement.

Ce que ça signifie

ExpiredTokenException: The security token included in the request is expired

AWS a rejeté ta requête parce que les identifiants de sécurité temporaires avec lesquels elle a été signée ont expiré. Les identifiants temporaires de STS (AssumeRole, SSO, GetSessionToken, rôles d'instance EC2/ECS) vivent pendant une fenêtre bornée — les sessions de rôle vont de 15 minutes jusqu'au réglage de durée de session maximale du rôle (entre 1 et 12 heures ; 1 heure par défaut), et les identifiants GetSessionToken pour un utilisateur IAM durent par défaut 12 heures et peuvent s'étendre jusqu'à 36. Une fois cette fenêtre passée, chaque requête signée avec eux échoue avec ExpiredTokenException. Renvoyer avec le même token expiré échoue à nouveau — cela ne vaut la peine de réessayer qu'après avoir rafraîchi.

Pourquoi ça arrive

La session STS/SSO a simplement expiré — les identifiants de rôle assumé expirent à la durée de session du rôle (par défaut 1 heure, configurable jusqu'à 12) ; une session SSO expire de même.
Un AWS_SESSION_TOKEN périmé dans l'environnement — un ancien token de session exporté dans ton shell (ou un .env) continue d'être utilisé après son expiration ; les variables d'environnement ne se rafraîchissent pas automatiquement.
Un processus de longue durée qui a récupéré les identifiants une fois au démarrage et ne les a jamais rafraîchis.
Des identifiants en cache dans ~/.aws/cli/cache ou un cache d'identifiants du SDK qui a survécu à leur expiration.
Un décalage d'horloge — une horloge machine suffisamment décalée peut faire paraître expirés des identifiants valides.

Comment le corriger

Rafraîchis la session. Relance aws sso login (pour SSO) ou réassume le rôle (aws sts assume-role …) pour obtenir une nouvelle clé d'accès, un secret et un token de session.
Mets à jour les trois valeurs — access key id, secret access key, et le token de session ensemble. Une nouvelle clé avec un token périmé échoue quand même.
Efface les variables d'environnement périmées — unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN, puis re-source les nouveaux identifiants ou bascule vers un profil que le SDK peut rafraîchir tout seul.
Laisse le SDK gérer le cycle de vie — configure un profil / fournisseur d'identifiants (SSO, assume_role, rôle d'instance) pour que le SDK se rafraîchisse automatiquement avant l'expiration au lieu d'épingler un seul token.
Vérifie avec aws sts get-caller-identity — si ça réussit, tes identifiants sont à jour.
Vérifie l'horloge (NTP) si tout paraît frais mais que les requêtes signalent quand même une expiration.

Connecte-toi depuis DynoTable

DynoTable résout ton profil à neuf à chaque connexion — sessions SSO et assume-role protégé par MFA compris — donc une fois la session renouvelée, tes tables reviennent sans redémarrage. La pastille de statut du profil passe au rouge avec Sign in (SSO) ou Reconnect quand les identifiants temporaires expirent ; clique dessus ou relance une requête pour déclencher le rafraîchissement dans l'app. Appuie sur ⌘P pour confirmer que tu es bien sur le profil que tu as rafraîchi dans le terminal. Le query builder est une vérification rapide que les lectures signées passent après le rafraîchissement.

FAQ

Comment corriger « the security token included in the request is expired » ? Tes identifiants temporaires ont expiré. Rafraîchis-les — relance aws sso login ou réassume le rôle — et mets à jour la clé d'accès, le secret et AWS_SESSION_TOKEN ensemble. Efface tout token périmé laissé dans ton shell pour que l'ancien ne soit pas réutilisé, et préfère un fournisseur d'identifiants du SDK qui se rafraîchit automatiquement.

Pourquoi je n'obtiens ça qu'avec des identifiants temporaires ? ExpiredTokenException s'applique aux identifiants STS/SSO/rôle assumé à durée bornée, qui portent une expiration. Les clés d'accès d'utilisateur IAM à longue durée de vie n'expirent pas d'elles-mêmes, donc elles lèvent des erreurs d'identifiants pour d'autres raisons (invalides/désactivées), pas celle-ci.

DynoTable résout ton profil à neuf à chaque connexion — sessions SSO et rôles assumés protégés par MFA compris — donc une fois la session renouvelée, tes tables reviennent directement, sans redémarrage.

Erreurs liées

The security token included in the request is invalid — identifiants rejetés comme erronés, pas expirés.
IncompleteSignatureException — une signature de requête mal formée.
AccessDeniedException — identifiants valides, permission manquante.

Sources

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