The SSO session associated with this profile has expired or is otherwise invalid

TL;DR — Ton token d'accès IAM Identity Center (AWS SSO) a expiré, donc le profil ne peut pas générer d'identifiants pour l'appel DynamoDB. Lance aws sso login --profile <profile> pour te réauthentifier. Si l'erreur persiste juste après la connexion, c'est que tu te connectes à un profil/une session différent de celui qu'utilise le code, ou que le token en cache sous ~/.aws/sso/cache est périmé — vide-le et reconnecte-toi.

Ce que ça signifie

UnauthorizedSSOTokenError: The SSO session associated with this profile has
expired or is otherwise invalid. To refresh this SSO session run aws sso login
with the corresponding profile.

Les profils basés sur SSO ne stockent pas de clés à longue durée de vie. aws sso login met en cache un token d'accès localement, et la CLI/le SDK l'échange contre des identifiants de rôle à courte durée de vie à la demande. Les deux couches expirent : les identifiants de rôle après quelques minutes à quelques heures, et le token SSO après la durée de session configurée par ton organisation. Quand le token est expiré (ou que le rafraîchissement échoue), chaque appel signé — y compris les lectures et écritures DynamoDB — échoue avec cette erreur avant d'atteindre AWS.

Pourquoi ça arrive

La session SSO a simplement expiré — la durée de session est fixée par ton administrateur Identity Center ; une expiration du jour au lendemain est typique.
Tu t'es connecté à un profil différent — aws sso login s'est exécuté sur un profil pendant que ton application/outil en résout un autre (incohérence de AWS_PROFILE, ou deux profils pointant vers des configs sso_session différentes).
Cache de token périmé ou corrompu — les fichiers JSON sous ~/.aws/sso/cache ne correspondent plus à la configuration SSO du profil (région/URL de démarrage modifiée), donc les outils continuent de voir une session « invalide » même après connexion.
Des outils tiers qui résolvent les identifiants eux-mêmes — les SDK et outils qui lisent directement le cache SSO peuvent être en désaccord avec la CLI sur la validité (certains considèrent les tokens comme expirés légèrement avant leur expiration réelle).

Comment le corriger

Réauthentifie le bon profil :

aws sso login --profile my-profile
aws sts get-caller-identity --profile my-profile   # confirm it worked

Assure-toi que ton code utilise ce même profil — définis AWS_PROFILE=my-profile pour le processus qui parle à DynamoDB, et vérifie ~/.aws/config pour d'éventuelles définitions de profil dupliquées/legacy.
Toujours « expired » après la connexion ? Vide le cache de token et reconnecte-toi à neuf — aws sso logout est la méthode documentée pour supprimer les identifiants en cache (ils se trouvent sous ~/.aws/sso/cache) :
```
aws sso logout
rm -rf ~/.aws/sso/cache   # only if a stale cache file still lingers
aws sso login --profile my-profile
```
Pour les charges de travail longues ou sans interface, n'utilise pas de profils SSO — une connexion interactive via navigateur ne peut pas se rafraîchir sans surveillance. Utilise plutôt un rôle IAM attaché au compute (rôle d'instance/de tâche/d'exécution) ou un rôle OIDC de CI.
Sessions qui expirent trop vite au point d'être agaçant ? La durée de session est un paramètre Identity Center — demande à ton administrateur de l'étendre.

Les outils de bureau héritent de la même solution : une fois aws sso login réussi, l'application de bureau DynoTable récupère ton profil SSO rafraîchi et se reconnecte à tes tables. Tant que la session est active, le DynamoDB Expression Builder t'aide à transformer ce que tu veux interroger en une requête correcte.

Erreurs liées

The security token included in the request is expired — des identifiants de rôle expirés plutôt que la session SSO.
The security token included in the request is invalid
Unable to locate credentials (boto3)

Références

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