aws configure sso Profile Not Working? Fix "Error Loading SSO Token", "Profile Could Not Be Found", "Missing Required Configuration", invalid_grant and Expired Sessions (CLI, boto3, Terraform)

aws configure sso sets up an AWS CLI profile that signs in through IAM Identity Center (the service AWS used to call AWS SSO) instead of using a long-lived access key. When the profile "does not work", the cause is almost always one of five things: you never ran aws sso login after the wizard, the command is not using the profile (no --profile and no AWS_PROFILE), one line in ~/.aws/config is wrong or missing, the sso_region is not the Region where your Identity Center lives, or the sign-in session has ended. Each one prints a different message, and this page lists all of them with the fix. The thing that surprises most people: invalid_grant has nothing to do with your password. It means the AWS login service refused a one-time code or a refresh token it no longer accepts: a code that expired or was already used, a session your administrator ended, or a session that reached its time limit (8 hours by default). Clearing the token cache and signing in again fixes it; changing your password does not.

Jake's shop website runs on AWS, and for two years he deployed it with an access key saved on his laptop. After reading about leaked keys, his developer friend Ethan moved him to IAM Identity Center: one sign-in page, short-lived credentials, nothing secret on disk. Jake ran the wizard, answered every question, and his first command failed with "Error loading SSO Token: Token for my-sso does not exist". "I did everything it asked," Jake said. "It never asked you to log in," Ethan said. "That is the next command." This page is the setup Ethan wrote down for him, and every error they met after it.

New to the vocabulary? IAM Identity Center is the company login for AWS, and IAM is the permission system behind it. You need the AWS CLI version 2 (version 1 has no aws configure sso wizard), a user in Identity Center, and at least one account and permission set assigned to you.

Set up aws configure sso the right way

Before you start, collect two values from your AWS access portal (the page you sign in to): open it, choose the account and permission set you work with, click Access keys, and pick the IAM Identity Center credentials option in the dialog. It shows your SSO start URL (it looks like https://your-company.awsapps.com/start) and your SSO Region, the Region where your Identity Center lives. That Region is often not the Region where you run your servers, and mixing the two up causes the strangest errors on this page. Since AWS CLI 2.22.0 you can use the Issuer URL from the Identity Center console instead of the start URL.

1. Check your CLI version: aws --version should print aws-cli/2. something. On Windows, our AWS CLI install guide for Windows 11 covers the installer; on Kali Linux and other Linux, use AWS's official zip installer (the awscli package from apt can be an older version 1); on a Mac, AWS's .pkg installer.
2. Run the wizard and answer the four questions:

   $ aws configure sso
   SSO session name (Recommended): my-sso
   SSO start URL [None]: https://your-company.awsapps.com/start
   SSO region [None]: us-east-1
   SSO registration scopes [None]: sso:account:access

3. Approve the sign-in in your browser. The CLI opens it for you. The approval screen names an app starting with botocore-client-; that is the AWS CLI itself, and approving it is expected.
4. Pick the account and the role from the lists (if you have only one of each, the wizard picks them for you), then answer the last three prompts: default Region for your commands, output format, and a profile name. Choose a short name such as dev; you will type it a lot.
5. Sign in and test:

   aws sso login --profile dev
   aws sts get-caller-identity --profile dev

   The second command prints your account number and an ARN containing AWSReservedSSO_ and your role name. If you see that, the profile works.

Two details save you trouble later. First, always fill in the session name at the first prompt. Leaving it empty creates the old "legacy" style of profile, which cannot refresh its sign-in by itself and expires sooner. Second, the wizard finishes by logging you in once, but that sign-in does not last forever; every later day starts with aws sso login --profile dev (or aws sso login --sso-session my-sso, which signs in every profile that shares the session).

Tired of typing --profile dev? Set it once for your terminal session: export AWS_PROFILE=dev on Kali, Linux and macOS, or $env:AWS_PROFILE = "dev" in PowerShell. If you name the profile default, every command uses it with no flag at all.

What the wizard writes to ~/.aws/config, line by line

The wizard is only a typing aid; the result is a few lines in a text file, ~/.aws/config (on Windows, C:\Users\YOU\.aws\config). Knowing what each line does turns most SSO errors into a one-line fix. A correct, modern setup:

[profile dev]
sso_session = my-sso
sso_account_id = 111122223333
sso_role_name = ReadOnly
region = us-west-2
output = json

[sso-session my-sso]
sso_start_url = https://your-company.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

One sso-session can serve many profiles, which is how you work in several accounts with a single sign-in. Add a profile per account or role, all pointing at sso_session = my-sso, and aws sso login --sso-session my-sso signs them all in at once:

[profile dev]
sso_session = my-sso
sso_account_id = 111122223333
sso_role_name = PowerUserAccess

[profile prod-readonly]
sso_session = my-sso
sso_account_id = 444455556666
sso_role_name = ReadOnly

The legacy style puts sso_start_url and sso_region directly in the profile and has no sso-session block. It still works, but it cannot refresh the sign-in automatically, so it fails more often. If your file has it, rerun aws configure sso with a session name, or move the two lines into an [sso-session] block by hand.

Every aws configure sso and aws sso login error, with the fix

These are the exact messages for each mistake, as produced by botocore (the Python library the AWS CLI is built on, and the same one boto3 uses), against deliberately broken copies of the config above. The CLI prints the same text after aws: or an error prefix.

Notice that the expired-token message differs by profile style: the same expiry prints "Token has expired and refresh failed" for an sso-session profile and "The SSO session associated with this profile has expired or is otherwise invalid" for a legacy one. If you search for one and find answers about the other, both have the same first fix. Older CLI versions printed a third wording, "Error loading SSO Token: The SSO access token has either expired or is otherwise invalid", which also means "sign in again".

"Profile could not be found" and "Unable to locate credentials": the CLI is not using your profile

A working SSO profile does nothing unless the command uses it. The AWS CLI looks for credentials in a fixed order: command-line options, environment variables (including AWS_ACCESS_KEY_ID and AWS_PROFILE), then the default profile. If your SSO profile is called dev and you type aws s3 ls with nothing else, the CLI goes looking for a default profile, finds none, and says "Unable to locate credentials".

Three commands show you what is going on:

aws configure list-profiles          # every profile name the CLI can see
aws configure list --profile dev     # where each value comes from
aws sts get-caller-identity --profile dev

Two traps catch people here. Old access keys in environment variables win over everything: if AWS_ACCESS_KEY_ID is set in your shell, commands run as that key, not as your SSO role, which produces "access denied" errors that make no sense. Clear them (unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN, or Remove-Item Env:AWS_ACCESS_KEY_ID in PowerShell). And the config file must be the one you edited: AWS_CONFIG_FILE can point the CLI elsewhere, and on Windows, running a command as a different user (an elevated prompt with another account, a service, a scheduled task) reads that user's .aws folder, not yours.

invalid_grant: what it really means and the five causes

"invalid_grant" is the error code the AWS sign-in service (the SSO OIDC service behind aws sso login) returns when it is handed a code or token it will not accept. Calling that service with a made-up code returns exactly this:

An error occurred (InvalidGrantException) when calling the CreateToken operation: Invalid device code provided
An error occurred (InvalidGrantException) when calling the CreateToken operation: Invalid refresh token provided

Your password is never part of that exchange; you type it into the web page, not the CLI. So the causes are all about codes and sessions:

1. The one-time code expired or was already used. With device sign-in (--use-device-code), the code shown in the terminal is valid for a short time and only once. Approving it late, or in a second tab after the first already worked, gives invalid_grant. Run aws sso login again and approve promptly.
2. Your session reached its time limit. Identity Center sessions last 8 hours by default; an administrator can set anything from 15 minutes to 90 days (Settings, Authentication, Session duration). When it ends, the stored refresh token dies with it, and the next automatic refresh fails.
3. An administrator ended your session, or you were removed from the account or permission set. The refresh token stops working immediately.
4. The wrong sso_region. The sign-in service is per Region. A code issued by one Region is "invalid" in another; calling the eu-west-1 service with a us-east-1 sign-in returns the same "Invalid device code provided". Make sso_region the Region shown in your access portal's credential dialog.
5. Stale files in the token cache, for example after changing the start URL or Region. The cached client registration the CLI creates lasts 90 days, and a cache mixing old and new settings confuses the refresh.

The fix that clears all five, in order:

aws sso logout
rm -rf ~/.aws/sso/cache            # PowerShell: Remove-Item -Recurse ~\.aws\sso\cache
aws sso login --profile dev
aws sts get-caller-identity --profile dev

Deleting the cache only removes sign-in tokens and the CLI's registration; your profiles and the config file are untouched, and the next login rebuilds everything. If invalid_grant comes back every few hours, the cause is the session length, and the person to ask is your Identity Center administrator, not the CLI.

Ethan hit cause four on the first day. Jake's company had set up Identity Center in US East (N. Virginia), while the shop's website ran in Mumbai, and Jake had typed ap-south-1 at the SSO Region prompt because "that is where my stuff is". "Two Regions," Ethan said, writing them on a sticky note. "One for the login, one for the shop."

Signing in over SSH, in WSL or on a server without a browser

Since AWS CLI 2.22.0, aws sso login uses PKCE sign-in by default: the CLI opens a browser on the same machine, and the sign-in returns to a small local listener. That works on your laptop and fails on a remote server, in an SSH session or in a container, because the browser and the CLI are on different machines. The answer is the device-code flow:

aws sso login --profile dev --use-device-code

The CLI prints a URL (such as https://device.sso.us-east-1.amazonaws.com/) and a short code. Open the URL on any device, your phone included, enter the code and approve. The same flag works for the wizard: aws configure sso --use-device-code. In WSL, the default flow tries to open a Linux browser; device code avoids the question.

For machines that should never involve a person at all (a CI pipeline, a server running every night), SSO is the wrong tool: use an IAM role attached to the server, or OpenID Connect from your CI system. SSO sign-ins are built for humans and end when the session does.

Using the SSO profile from boto3, Terraform and the SDKs

The profile you made works everywhere that reads ~/.aws/config, as long as you have signed in with aws sso login first. None of these tools can do the browser sign-in for you.

• Python and boto3: boto3.Session(profile_name="dev").client("s3"), or set AWS_PROFILE=dev and create clients normally. Current boto3 refreshes sso-session profiles by itself during the session's lifetime.
• Terraform: set profile = "dev" in the provider "aws" block (or AWS_PROFILE=dev), sign in, then run terraform plan. If it still says "No valid credential sources found", our Terraform credentials guide walks through the provider's own lookup order.
• JavaScript (SDK v3) and Java: both read SSO profiles; their own error wording is in our guides to "Could not load credentials from any providers" and "Unable to load credentials".
• Older tools that only understand access keys: print temporary keys from your SSO profile and hand them over as environment variables:

  aws configure export-credentials --profile dev --format env

  The keys it prints are temporary and expire with the role session, which is the point.

Where the SSO tokens live, and signing out

After you sign in, the CLI stores the token in ~/.aws/sso/cache as a JSON file. For an sso-session profile, the file name is a SHA-1 hash of the session name; for a legacy profile, a hash of the start URL. That is why renaming your session or changing the URL makes the CLI behave as if you had never signed in: it is looking for a different file. The cache also holds the CLI's own client registration with the sign-in service, which expires after 90 days and is renewed automatically.

aws sso logout deletes your cached tokens and ends the CLI's sign-in ("Successfully signed out of all SSO profiles."). Use it on shared computers, before you hand in a laptop, and as the first step of fixing invalid_grant. It does not change your config file.

Jake now starts each day with one command and has nothing secret saved on the laptop. "So if someone steals it," he asked, "what do they get?" "A sign-in that expires by tonight," Ethan said, "and a config file with your account number in it." If the shop's old access key is still active, our leaked-key guide shows how to switch it off once SSO works.

aws configure sso not working? Troubleshooting by symptom

aws: error: argument command: Invalid choice: 'sso' or 'configure sso'

You are running AWS CLI version 1, which has no SSO wizard. Check with aws --version, uninstall version 1 (often installed with pip or apt) and install version 2 from AWS's official installer.

The browser opens but the CLI waits forever

With the default PKCE flow, the browser must return to the CLI on the same machine. Over SSH, in a container, or with a browser on another device, use --use-device-code. A strict local firewall that blocks the CLI's local listener can cause the same wait.

"Error loading SSO Token: Token for my-sso does not exist"

No cached sign-in for that session on this machine. Run aws sso login --profile dev. If it keeps coming back right after a login, check that sso_session in the profile names the session you logged in to.

"The specified sso-session does not exist"

The profile's sso_session value does not match any [sso-session NAME] header. The names are case-sensitive and cannot contain spaces.

"is configured to use SSO but is missing required configuration"

The message ends with the missing key. Account ID and role name belong in the profile; start URL and SSO Region belong in the sso-session block. Rerunning aws configure sso rewrites the profile correctly.

invalid_grant during aws sso login

A code or refresh token the sign-in service no longer accepts. Run aws sso logout, delete ~/.aws/sso/cache, sign in again and approve promptly, and confirm sso_region is your Identity Center Region.

"Token has expired and refresh failed"

Your session ended and could not be renewed. Sign in again; if it happens every few hours, your organization's session duration is short. The full guide covers the stubborn cases.

"ForbiddenException: No access" from GetRoleCredentials

You signed in, but the account and role in your profile are not assigned to you. Check sso_account_id and sso_role_name against what the access portal shows for your user; the role name is the permission set name, such as ReadOnly, not the long AWSReservedSSO_ name.

"Unable to locate credentials" after a successful login

The command is not using the SSO profile. Add --profile dev or set AWS_PROFILE, or name the profile default.

Commands run as the wrong account or role

Access keys in environment variables override profiles. Run aws sts get-caller-identity to see who you are, and unset AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN.

"InvalidClientTokenId: The security token included in the request is invalid"

This is not an SSO sign-in error: the credentials reached the service but were rejected, usually old keys in environment variables or a disabled Region. Our InvalidClientTokenId guide has the checklist.

It worked yesterday and fails today

Expected: the sign-in lasts for your organization's session duration (8 hours by default). Run aws sso login each morning; for longer sessions, ask your administrator, who can set up to 90 days.

aws configure sso: frequently asked questions

A week later Jake's morning routine was one line, typed from memory, and the old access key had been deactivated for six days without anything breaking. The sticky note with two Regions on it was still on his monitor. "Leave it there," Ethan said. "It has saved you twice."

Revision note. Written October 22, 2026, with every error message on this page reproduced against broken copies of a real config file and the SSO sign-in service itself. "A stitch in time saves nine," the proverb says; one correct sso_region line saves a morning.