An error occurred (InvalidClientTokenId) when calling the AssumeRole operation: The security token included in the request is invalid

Question

I'm constantly getting this error:

An error occurred (InvalidClientTokenId) when calling the AssumeRole operation: The security token included in the request is invalid.

when I run this Assume Role command:

aws sts assume-role --role-arn <arn role i want to assume> --role-session-name dev --serial-number <my arn> --token-code <keyed in token code>

This was working previously so I'm not sure what could have changed. And at a loss at how to debug this.

Any suggestions?

Answer 1

I had the same problem. You may need to unset your AWS env variables before running the sts command:

unset AWS_SECRET_ACCESS_KEY
unset AWS_SECRET_KEY
unset AWS_SESSION_TOKEN

and then your command:

aws sts assume-role --role-arn <arn role i want to assume> --role-session-name dev --serial-number <my arn> --token-code <keyed in token code>

Here you'll get new credentials. Then run the exports again:

export AWS_ACCESS_KEY_ID=<access key>
export AWS_SECRET_ACCESS_KEY=<secret access key>
export AWS_SESSION_TOKEN=<session token>

I hope it helps!

Answer 2

Old post, but might still be useful.

Can you try setting the following in the env and retry:

export AWS_ACCESS_KEY_ID='your access key id here';
export AWS_SECRET_KEY='your secret key here'

Answer 3

Here you need to reset your aws secret key and ID like -

export AWS_ACCESS_KEY_ID='ACCESS_KEYID';
export AWS_SECRET_KEY='SECRET_KEY'

in my case I use command aws configure in terminal for cli and it asks for access key id, secret key, region and output format.

Answer 4

You need to do an aws configure and set the AWS access key and secret key on the environment where you are running the STS command if its the first time you are running. The STS command verifies the identity using that data and checks if you have permissions to perform STS assume-role.

If you already have an existing access key and secret key configured, it could be possible that those have also been expired. So you might need to generate new keys for the user in IAM and configure it in the environment you are running.

Answer 5

I noticed that when I had to change my AWS IAM password, my access keys were also erased.

I had to generate a new access key and replace the aws_access_key_id and aws_secret_access_key stored in the ~/.aws/credentials (on mac) file.

This cleared the error

Answer 6

Fixed this issue by re-activating my access keys in iam user credentials section of your user. It was in-active when I got this issue.

Answer 7

Check your aws_access_key_id and aws_secret_access_key are correct in the ~/.aws/credentials file.

If they are then if the ~/.aws/credentials file contains a aws_session_token delete only that line in the file, save your changes and re-run your command.

Worked for me.

Answer 8

TLDR; The IAM user's key/secret key is one set of credentials. The session token + session's key/secret key are a different set of credentials, with different values.

--

I did not know the aws sts command created a session token, and new a AWS key/secret key. These keys are not the same as your IAM user key and secret key.

I generated a new key, secret key, and token. I updated my credentials file to use the new values. When my token expired the next day, I re-ran the aws sts command. However, the key and secret key in the credentials file were now wrong. I replaced the key and secret key values my IAM user keys in my credentials file. I also delete the session token in my credentials file.

Then the aws sts command worked.

Answer 9

I have tried to create on fly ~/.aws/config file with multi-profile to give my code build multi-account access. I made a mistake when I first create the file ~/.aws/config with an empty default profile and then tried to assume the role.

When you put the file ~/.aws/config in a place with a default profile, it is the profile that determines the identity and not the one that comes with the CodeBuild.

Answer 10

July 2022 Update!

Make sure the target AWS region is enabled . Here is how you can enable a region.

Answer 11

---

AUGUST 2022 Update!

---

Let's not forget the simplest of things. I got this same exact error message when I did not have a default region set. You can set it by running aws configure. Or, you can pass the region on sts command like so.

aws sts assume-role --role-arn "your_role_arn" --role-session-name MySessionName --region us-gov-west-1

Answer 12

I've got this error when I was trying to connect to my localstack instance.

The cause was the missing --endpoint-url http://localhost:4566 argument for aws cli.

Answer 13

Same error, but with a very specific situation and solution. In my case I have a profile that assumes a role in my .aws/credentials like the following:

[name]
role_arn = arn:aws:iam::ACCOUNT:role/ROLE_NAME
source_profile = default

I was working on the role, and while doing so deleted and recreated it. AWS CLI caches the token when using this profile method. The cached token was for the old role not the recreated one. This can be seen by adding --debug to the CLI command:

2023-01-27 16:22:03,055 - MainThread - botocore.credentials - DEBUG - Credentials for role retrieved from cache.
2023-01-27 16:22:03,055 - MainThread - botocore.credentials - DEBUG - Retrieved credentials will expire at: 2023-01-27 21:46:59+00:00

The cache can be wiped by removing the ~/.aws/cli/cache directory or the specific JSON file for this session found inside that directory.