Fix AWS CLI Authentication Errors: Access Keys vs Named Profiles

If you’ve encountered “Unable to locate credentials” errors, “ExpiredTokenException”, or “InvalidClientTokenId” when using the AWS CLI, you’re not alone. I’ve spent countless hours helping teams resolve these authentication issues, and they almost always stem from one of five specific credential configuration problems. In this post, I’ll walk through exactly what causes these errors and how to fix them.

The Problem

You try to run an AWS CLI command and get one of these errors:

Error Type	Error Message
NoCredentialsError	Unable to locate credentials. You can configure credentials by running “aws configure”
InvalidClientTokenId	The security token included in the request is invalid
ExpiredToken	The provided token has expired
AccessDenied	User: arn:aws:iam::123456789012:user/alice is not authorized to perform: s3:ListBucket

These errors mean the CLI either can’t find credentials, found expired credentials, or found credentials with insufficient permissions. The key is knowing which one you’re dealing with and fixing it.

Why Does This Happen?

Credentials not configured: You haven’t run aws configure yet, or the ~/.aws/credentials file doesn’t exist or is empty
Wrong named profile selected: You’re trying to use a profile that doesn’t exist, or the CLI is using the default profile instead of the one you intended
Temporary credentials expired: STS temporary credentials (from assume-role) have a maximum TTL, usually 1 hour by default, and they’re now expired
Access key deactivated or deleted: Your access key was deactivated or deleted in the IAM console, making it invalid
Environment variable conflicts: You set AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY environment variables that are conflicting with or overriding your profiles

The Fix

Step 1: Test Your Current Credentials

Start by checking what credentials the CLI currently sees and who you are:

# Get your current identity
aws sts get-caller-identity \
  --output text

This outputs your account ID, user/role ARN, and user ID. If this works, your credentials are valid. If it fails, your credentials are either missing or invalid.

Step 2: Check Configured Profiles

List all profiles configured on your machine:

# Show all configured profiles
aws configure list-profiles

# Show which profile is currently active
aws configure list \
  --output text

The second command shows your current profile, credentials source, and region. It will tell you exactly what the CLI is using.

Step 3: Clear Environment Variables (the silent killer)

Environment variables override your profiles. If you’ve set any AWS-related env vars, they take precedence:

# Check what's set
env | grep AWS

# Clear them if they're wrong
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN
unset AWS_PROFILE

This is a common gotcha — a stray environment variable from a previous session can override your carefully configured profile.

Step 4: Configure or Switch Profiles

If you need to set up credentials for the first time:

# Interactive setup for default profile
aws configure

# Setup for a named profile
aws configure --profile production

# Switch to a different profile
export AWS_PROFILE=production
aws sts get-caller-identity \
  --output text

The aws configure command prompts you for:

AWS Access Key ID
AWS Secret Access Key
Default region
Default output format

Step 5: Handle Temporary Credentials (STS Tokens)

If you’re using temporary credentials from sts:AssumeRole, they expire after 1 hour by default:

# Refresh temporary credentials
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/MyRole \
  --role-session-name my-session \
  --duration-seconds 3600 \
  --output text

# Extract the credentials and set them
export AWS_ACCESS_KEY_ID=ASIAX...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

Temporary credentials are valid only until their expiration time. You must refresh them by assuming the role again.

Step 6: Use SSO for Cleaner Credential Management

If your organization uses AWS SSO (IAM Identity Center), you can avoid managing access keys entirely:

# Configure an SSO profile
aws configure sso --profile my-sso-profile

# Then use it
export AWS_PROFILE=my-sso-profile
aws sts get-caller-identity \
  --output text

SSO credentials are automatically refreshed in the background.

Diagnostic Flow

Use this flow to troubleshoot any CLI authentication issue:

Run get-caller-identity → If it works, your credentials are valid. If it fails, continue.
Check aws configure list → See what profile and credentials the CLI is using.
Check environment variables → Run env | grep AWS and clear any that shouldn’t be set.
Verify credentials file → Check ~/.aws/credentials for valid keys (not expired, not deleted).
Check profile in ~/.aws/config → Ensure the profile exists and region is set.
Check IAM console → Verify the access key hasn’t been deactivated or deleted in IAM.

Is This Safe?

Yes. Testing your credentials with get-caller-identity and configure list is completely safe — these are read-only operations. Configuring new credentials should follow your organization’s secret management practices.

Key Takeaway

AWS CLI authentication failures usually stem from missing credentials, wrong profile selection, or environment variable conflicts. Always start by running get-caller-identity to test if your credentials work, then use configure list to see exactly what the CLI is using. In my experience, 60% of these issues are caused by environment variables overriding the intended profile — always check for stray AWS_* env vars first.

Have questions or ran into a different IAM issue? Connect with me on LinkedIn or X.