AWS STS GetCallerIdentity Token Verifier

Threat/Impact Level: HIGH | Exploitability/Downtime Risk: HIGH | Time to Fix: 5–15 mins

TL;DR

• What broke: sts:GetCallerIdentity rejected your temporary credentials because the X-Amz-Security-Token is expired, malformed, revoked, or the system clock is skewed beyond AWS's 5-minute tolerance.
• How to fix it: Reissue the temporary credentials via sts:AssumeRole or refresh the instance/ECS/EKS metadata endpoint; verify NTP sync; confirm the session token is passed as the third credential parameter, not omitted.
• Shortcut: Use our Client-Side Sandbox above to auto-refactor your credential initialization code — no data leaves your browser.

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation:
The request was rejected because the security token is invalid.

botocore.exceptions.ClientError: An error occurred (InvalidClientTokenId):
The security token included in the request is invalid.

How to Fix It (The Solution)

Root Cause Checklist (run in this order)

1. Check token expiry — STS temporary credentials expire between 15 minutes and 36 hours depending on DurationSeconds at assume-role time.
2. Verify clock sync — timedatectl status or chronyc tracking. Offset must be <5 minutes.
3. Confirm session token is present — Temporary credentials require three components: AccessKeyId, SecretAccessKey, AND SessionToken. Omitting the session token is the #1 cause of this error.
4. Check partition/region — A token issued in aws-cn or aws-us-gov is invalid in the standard aws partition.
5. Check CloudTrail for revocation — RevokeSession, DeleteRole, DetachRolePolicy events in the last hour.

Basic Fix — Boto3 (Python)

import boto3

- # WRONG: Omitting session token for temporary credentials
- client = boto3.client(
-     'sts',
-     aws_access_key_id='ASIA....',
-     aws_secret_access_key='wJalrXUtn....',
- )

+ # CORRECT: All three components required for temporary credentials
+ client = boto3.client(
+     'sts',
+     aws_access_key_id='ASIA....',
+     aws_secret_access_key='wJalrXUtn....',
+     aws_session_token='IQoJb3JpZ2lu...',  # Required for STS-issued creds
+ )

response = client.get_caller_identity()

Basic Fix — AWS CLI credential refresh

- # Stale assume-role output hardcoded in ~/.aws/credentials
- [default]
- aws_access_key_id = ASIA...OLD
- aws_secret_access_key = oldSecret
- # aws_session_token line missing entirely

+ # Re-issue via CLI and export fresh credentials
+ export $(aws sts assume-role \
+   --role-arn arn:aws:iam::123456789012:role/MyRole \
+   --role-session-name debug-session \
+   --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
+   --output text | awk '{print "AWS_ACCESS_KEY_ID="$1" AWS_SECRET_ACCESS_KEY="$2" AWS_SESSION_TOKEN="$3}')

Enterprise Best Practice — Auto-Refresh with SDK Credential Providers

Never hardcode or manually manage temporary credentials in production. Use the SDK's built-in provider chain, which handles refresh automatically.

- # ANTI-PATTERN: Manually managing short-lived credentials in application code
- creds = get_creds_from_vault()  # Fetched once at startup, never refreshed
- client = boto3.client('sts',
-     aws_access_key_id=creds['AccessKeyId'],
-     aws_secret_access_key=creds['SecretAccessKey'],
-     aws_session_token=creds['SessionToken']
- )

+ # BEST PRACTICE: Use AssumeRoleProvider via botocore RefreshableCredentials
+ from botocore.credentials import RefreshableCredentials
+ from botocore.session import get_session
+ from datetime import datetime, timezone
+
+ def refresh_credentials():
+     sts = boto3.client('sts')
+     response = sts.assume_role(
+         RoleArn='arn:aws:iam::123456789012:role/MyRole',
+         RoleSessionName='auto-refresh-session',
+         DurationSeconds=3600
+     )
+     c = response['Credentials']
+     return {
+         'access_key': c['AccessKeyId'],
+         'secret_key': c['SecretAccessKey'],
+         'token': c['SessionToken'],
+         'expiry_time': c['Expiration'].isoformat()
+     }
+
+ refreshable = RefreshableCredentials.create_from_metadata(
+     metadata=refresh_credentials(),
+     refresh_using=refresh_credentials,
+     method='sts-assume-role'
+ )

For EKS/IRSA: Ensure AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN env vars are injected by the pod identity webhook. The SDK handles the rest.

For EC2/ECS: Do not set AWS_ACCESS_KEY_ID manually. Delete the env var and let the IMDSv2 metadata provider serve auto-rotating credentials.

💡 Tired of pasting proprietary infrastructure configs into public LLMs? Generic AI interfaces log your company's ARNs, connection strings, and private keys. StackEngine enforces client-side zero-trust boundaries—the sandbox above executes 100% locally in your browser. Drop your broken manifest above to redact secrets locally and synthesize deterministic patch drafts with your own API key.

(For CI/CD pipeline automation, install via npm i -g stackengine).

# .checkov.yml — flag any hardcoded AWS credential patterns
checks:
  - CKV_AWS_46  # Ensure no hardcoded credentials in Lambda env vars
  - CKV_SECRET_2 # AWS Secret Access Key in source

package aws.ecs

deny[msg] {
  container := input.containerDefinitions[_]
  env := container.environment[_]
  regex.match(`^AWS_(ACCESS_KEY|SECRET|SESSION_TOKEN)`, env.name)
  msg := sprintf("Container '%v' hardcodes AWS credentials. Use task IAM role instead.", [container.name])
}

- # WRONG: Storing long-lived or manually-refreshed STS tokens in GitHub Secrets
- env:
-   AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
-   AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
-   AWS_SESSION_TOKEN: ${{ secrets.AWS_SESSION_TOKEN }}  # Expires, breaks pipeline

+ # CORRECT: GitHub OIDC federation — zero stored secrets, auto-rotating
+ permissions:
+   id-token: write
+   contents: read
+ steps:
+   - uses: aws-actions/configure-aws-credentials@v4
+     with:
+       role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
+       aws-region: us-east-1

# Terraform — CloudWatch alarm for NTP drift
resource "aws_cloudwatch_metric_alarm" "ntp_drift" {
  alarm_name          = "ntp-offset-critical"
  metric_name         = "chrony_tracking_system_time_offset"
  namespace           = "CWAgent"
  statistic           = "Maximum"
  period              = 60
  evaluation_periods  = 2
  threshold           = 240
  comparison_operator = "GreaterThanThreshold"
  alarm_actions       = [aws_sns_topic.ops_alerts.arn]
}