InvalidClientTokenId
AWS InvalidClientTokenId (Invalid Client Token Id) means the access key ID or client token identifier in the request does not map to an active credential in the target AWS account or session chain. In AWS APIs, this error returns HTTP 403.
Last reviewed: April 15, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Invalid Client Token ID Mean?
AWS rejects the credential identity before it even evaluates permissions. The useful questions are which credential source won, which key ID was sent, and whether that key still exists in the account the runtime actually used.
Common Causes
- -Access key ID was deleted, deactivated, or never existed in the active account.
- -Runtime resolves credentials from an unexpected source such as env vars, a local profile, or the wrong role chain.
- -Secret-management rollout updated one credential component but not the matching key, secret, or session token together.
- -Automation caches old credentials after rotation and continues signing with invalid identity data.
- -Cross-account or partition drift points the workload at the wrong account while using seemingly valid credentials from another environment.
How to Fix Invalid Client Token ID
- 1Run
aws sts get-caller-identityfrom the same failing runtime to prove which principal and account are actually being used. - 2Inspect credential resolution order and pin an explicit source where ambiguity exists.
- 3Replace the failing workload with a known-good credential path, then roll restart dependent jobs and workers.
- 4Invalidate local, CI, container, and SDK credential caches that may keep reintroducing stale token IDs.
Step-by-Step Diagnosis for Invalid Client Token ID
- 1Capture request ID, credential source metadata, and the redacted key identifier from runtime logs or SDK debug output.
- 2Check IAM access key status, last-used data, and principal lifecycle history in the account you expect to be using.
- 3Compare working and failing environments for profile, env var, role, and region differences in the credential chain.
- 4Trace secret distribution timestamps to detect partial rollouts or stale mounts after key rotation.
- 5Confirm the workload is not silently falling back from role-based auth to static credentials or a local developer profile.
Seen in Production
- -ECS tasks continue using a revoked key ID from a stale secret mount even after the control plane shows the new key pair as active.
- -A CI runner inherits
AWS_PROFILEfrom the host and signs production calls with a sandbox profile that is unknown in the target account. - -One Kubernetes deployment still uses static credentials while the rest of the cluster has already moved to role-based auth, so only that shard returns InvalidClientTokenId.
Credential Source Precedence Audit
- -Inspect caller identity chain resolution across env vars, profiles, web identity, and role metadata (example:
AWS_PROFILEoverrides the intended runtime role). - -Correlate failing request IDs with credential last-used data (example: the expected key shows no recent use, proving the runtime loaded another provider).
Rotation and Cache Drift Checks
- -Trace secret rollout consistency for key and secret or token pairs (example: key ID updated in secret store but workload still uses the previous secret component).
- -Audit SDK, container, and runner cache behavior after rotation (example: worker process never refreshes credentials until restart).
Decision Shortcut: Deleted Key vs Wrong Credential Source
- -If the expected key shows recent use in IAM but the runtime still fails, suspect a different credential source is winning rather than a deleted key.
- -If
sts get-caller-identityfails everywhere with the same key ID and IAM shows it disabled or absent, treat the issue as a real credential lifecycle problem, not source precedence.
Wrong Fix to Avoid
- -Do not broaden IAM permissions if AWS never recognized the credential identity in the first place.
- -Do not rotate keys repeatedly without first proving which credential source the runtime is actually loading.
Implementation Examples
env | rg '^AWS_|^AWS_PROFILE'
aws configure list
aws sts get-caller-identity --debug 2>&1 | rg 'credential|InvalidClientTokenId'aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE
aws iam list-access-keys --user-name deploy-botenv | rg '^AWS_'
cat ~/.aws/config
curl -s 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI | jq '.RoleArn // .AccessKeyId'Incident Timeline
11:02 UTC
Credential rotation finishes in the control plane
Signal: Secrets or IAM metadata show the new key pair as active, so the team assumes the rollout is complete.
Why it matters: At this point the important question is whether the runtime actually reloaded the new source, not whether IAM knows about it.
11:05 UTC
One runtime path keeps signing with an old or unexpected source
Signal: A task, runner, or shell still resolves credentials from stale env vars, AWS_PROFILE, or a mounted secret containing the old key ID.
Why it matters: InvalidClientTokenId is often a provider-precedence problem before it is a true IAM lifecycle problem.
11:07 UTC
The failing shell proves the runtime identity is not what operators expected
Signal: aws sts get-caller-identity or SDK debug output shows the wrong account, wrong principal, or an access key unknown to the target environment.
Why it matters: Once the live source is known, the fix usually becomes mechanical: remove the winning stale provider or reload the correct one.
11:15 UTC
The stale provider is flushed and the intended source wins
Signal: After clearing the wrong env/profile/cache path and restarting the affected workload, the same API call succeeds with the expected account and principal.
Why it matters: That confirms the incident was about credential source drift or stale key material, not missing permissions.
Seen in Production
CI deploy updates secret store but running tasks keep old key ID
Frequency: common
Example: New credentials are valid in the control plane, but workers still use revoked key IDs from cached env vars and stale mounts.
Fix: Roll restart workloads after rotation and enforce credential cache invalidation at the SDK or process layer.
Local developer profile overrides workload role in one environment
Frequency: common
Example: Automation host inherits AWS_PROFILE and signs requests with sandbox credentials not valid for prod.
Fix: Pin explicit credential source and block profile fallback for production jobs.
Role-based auth rollout leaves one shard on static credentials
Frequency: medium
Example: Most pods use IRSA correctly, but one deployment manifest still mounts old static keys and only that path returns InvalidClientTokenId.
Fix: Remove legacy static credentials and add deployment-time checks that reject mixed auth modes.
Cross-account automation points at the wrong partition or account
Frequency: medium
Example: A deployment intended for commercial AWS accidentally loads credentials from another account path, so the key is valid somewhere but unknown to the target environment.
Fix: Assert account and partition identity at startup and fail fast when the runtime principal is not in the expected target.
Wrong Fix vs Better Fix
Rotate keys repeatedly vs identify the winning provider
Wrong fix: Keep issuing new keys because the old one must still be broken somehow.
Better fix: Prove which provider source won in the failing runtime, then remove or refresh that exact env var, profile, secret mount, or metadata path.
Why this is better: New keys do not help if the workload never loads them. Source precedence is usually the shortest path to the real fix.
Broaden IAM permissions vs fix identity selection
Wrong fix: Attach wider IAM policies because the API request is being rejected.
Better fix: Treat InvalidClientTokenId as an identity-selection problem first and fix the credential chain before reviewing authorization.
Why this is better: AWS has not even accepted the credential identity yet. Permission changes only add noise until the right principal is actually in use.
Test from a local shell vs replay in the production runtime
Wrong fix: Validate the fix from a local admin machine and assume the container, runner, or pod will behave the same way.
Better fix: Replay the request in the exact runtime that failed and confirm sts get-caller-identity shows the intended account and principal there.
Why this is better: Local success proves only that one credential source works somewhere. The production incident closes only when the original runtime uses it.
Debugging Tools
- -aws sts get-caller-identity
- -AWS CLI --debug
- -IAM access key last-used reports
- -Credential provider chain debug logs
- -Secret rollout and container mount timestamps
How to Verify the Fix
- -Replay the original request and confirm InvalidClientTokenId is resolved.
- -Verify STS identity checks return the expected account and principal in every environment that can call the target API.
- -Confirm credential-related auth failures decline after rollout and no stale cache path reintroduces the old key ID.
- -Validate that the intended role-based or federated credential source remains stable across pod restarts and deploys.
How to Prevent Recurrence
- -Prefer role-based temporary credentials over long-lived static keys.
- -Automate coordinated key and token rotation with atomic secret updates and forced cache refresh.
- -Add startup identity assertions that fail fast on unexpected principals.
Pro Tip
- -enforce a preflight
sts:GetCallerIdentitygate in deployment health checks so invalid token IDs are detected before traffic cutover.
Decision Support
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.