Invalid security token error when using SSO-sourced profiles (regression since 3.47.0)

[jreslock]

Problem

UPDATE: I have narrowed this down to a problem introduced between versions 3.46.0 and 3.47.0 of the extension. Version 3.46.0 behaves as expected. 3.47.0 behaves as described in this issue.

AWS Toolkit fails to authenticate profiles sourced from an authenticated SSO profile. AWS CLI and boto3 both function as expected and authenticate correctly.

There is no ~/.aws/credentials file in play.

get_aws_credentials.txt

aws_toolkit_sso_auth_debug.log

Sample ~/.aws/config to reproduce the issue:

[default]
sso_account_id  = <REDACTED>
sso_role_name  = admin
sso_region = us-east-1
sso_registration_scopes = sso:account:access
sso_start_url  = https://d-<REDACTED>.awsapps.com/start
region = us-east-1
output = json
cli_pager =

[profile test]
source_profile  = default
role_arn            = arn:aws:iam::<REDACTED>:role/<role_name>
region               = us-east-1

Steps to reproduce the issue

Use the sample ~/.aws/config file above, replacing redacted values with valid account ids and sso start url.

Open VSCode, extensions, AWS Explorer, and see that it is "Connected with profile:default".

Attempt to switch connections to the test profile and receive the following error:

Unable to authenticate connection: The security token included in the request is invalid.

I have enabled debug level logging for the extension and captured the logs while reproducing the issue locally. Profile names in the debug log have not been redacted but you can see I have a number of available profiles. All of them use source_profile = default and [default] is a valid SSO profile with valid, working credentials.

I have attached a sample python script (with a .txt extension because I can't attach .py files to an issue) that uses boto3 to print the current assumed role information when run with AWS_PROFILE set to help demonstrate the difference in behavior between the extension and the boto3 python module. This code works as expected with profiles sourced from my default SSO profile.

I have confirmed this issue is present for other users on my team and is not isolated to my individual system.

This behavior appears to have changed recently. I am not sure when exactly but using "sourced" profiles was working correctly until recently. Possibly within the last 2-3 weeks.

What else can I do to help troubleshoot/debug this behavior?

Expected behavior

All AWS profiles that are sourced from default should authenticate correctly as long as the SSO session is valid. The AWS CLI and boto3 both properly authenticate using profiles that "source" from an SSO profile.

System details (run AWS: About and/or Amazon Q: About)

• OS: MacOS Sequoia 15.3.2
• Visual Studio Code version:

Version: 1.98.1 (Universal)
Commit: 2fc07b811f760549dab9be9d2bedd06c51dfcb9a
Date: 2025-03-10T15:38:08.854Z
Electron: 34.2.0
ElectronBuildId: 11160463
Chromium: 132.0.6834.196
Node.js: 20.18.2
V8: 13.2.152.36-electron.0
OS: Darwin arm64 24.3.0

• AWS Toolkit version: 3.49.0
• Amazon Q version: Not installed but doesn't matter. I can install it and experience the same behavior.

[jreslock]

This commit specifically looks like it may be related to triggering the reported behavior.

[cwinters8]

Same type of configuration and error here, which seemed to inexplicably start happening a few weeks ago, lining up with the 3.47.0 upgrade. I gave up on using the extension since then, until today when I thought I'd give it another shot (it's awfully handy for reviewing and tailing CloudWatch logs). After finding this issue, I downgraded to 3.46.0, which allowed my credentials to start working again.