DynoTable

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

TL;DR — Your IAM Identity Center (AWS SSO) access token has lapsed, so the profile can't mint credentials for the DynamoDB call. Run aws sso login --profile <profile> to re-authenticate. If the error persists right after logging in, you're logging into a different profile/session than the code is using, or the cached token under ~/.aws/sso/cache is stale — clear it and log in again.

What it means

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.

This is a botocore ClientError, not a DynamoDB service Exception — it fires while the SDK resolves credentials, before any signed request leaves your machine. The cached token under ~/.aws/sso/cache is expired, corrupt, or belongs to a different sso_session than the profile resolves. Every AWS call through that profile fails before it reaches a service endpoint.

Why it happens

  • The SSO session simply timed out — session duration is set by your Identity Center administrator; overnight expiry is typical.
  • You logged into a different profile — aws sso login ran against one profile while your app/tool resolves another (AWS_PROFILE mismatch, or two profiles pointing at different sso_session configs).
  • Stale or corrupted token cache — the JSON files under ~/.aws/sso/cache no longer match the profile's SSO configuration (region/start URL changed), so tools keep seeing an "invalid" session even after login.
  • Third-party tools resolving credentials themselves — SDKs and tools that read the SSO cache directly can disagree with the CLI about validity (some treat tokens as expired slightly ahead of their actual expiry).

How to fix it

  1. Re-authenticate the right profile:

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

  2. Make sure your code uses that same profile — set AWS_PROFILE=my-profile for the process that talks to DynamoDB, and check ~/.aws/config for duplicate/legacy profile definitions.

  3. Still "expired" after login? Clear the token cache and log in fresh — aws sso logout is the documented way to delete the cached credentials (they live under ~/.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

  4. For long-running or headless workloads, don't use SSO profiles — an interactive browser login can't refresh unattended. Use an IAM role attached to the compute (instance/task/execution role) or a CI OIDC role instead.

  5. Sessions expiring annoyingly fast? Session duration is an Identity Center setting — ask your administrator to extend it.

Check it in DynoTable

DynoTable runs the same IAM Identity Center device flow as the CLI — in-process, no separate aws binary required (Connect an AWS account). Once aws sso login succeeds, the app reads the refreshed token from ~/.aws/sso/cache on the next connection. When the SSO session lapses, the profile chip shows a red dot with Sign in; click it to reopen the browser flow without restarting DynoTable. Press ⌘P to verify the profile name matches the one you logged into in the terminal. After refresh, open a table to confirm DynamoDB calls succeed — the visual query builder derives Query-vs-Scan from your filter pills once credentials are live again.

Sources

Work with DynamoDB without the Console

A fast DynamoDB desktop client that runs the real SQL DynamoDB can’t — JOINs, GROUP BY, aggregates — with visual editing and an AI agent on your own Bedrock keys.

DownloadSee pricing

Free 30-day trial, no credit card — then the Free plan with no time limit.