SSO Cache filename should be based on sso_session in addition to sso_start_url

[schrobot]

Acknowledgements

• I have searched (https://github.com/aws/aws-sdk/issues?q=is%3Aissue) for past instances of this issue
• I have verified all of my SDK modules are up-to-date (you can perform a bulk update with go get -u github.com/aws/aws-sdk-go-v2/...)

Describe the bug

The SSO cache files in ~/.aws/sso/cache are assumed to have filenames based only on the startUrl. Other SDKs, namely the Python SDK, and seemingly what the AWS CLI uses, actually use the sso_session if provided, and fallback to the sso_start_url otherwise. This leads to issues where if I login via the aws CLI, with a profile that has a sso_session configured, tools that use the go SDK, like https://github.com/awslabs/amazon-ecr-credential-helper, fail to correctly find my cached credentials and produce authentication errors.

See https://github.com/boto/botocore/blob/master/botocore/utils.py#L3354 and
https://github.com/aws/aws-sdk-go-v2/blob/main/credentials/ssocreds/sso_credentials_provider.go#L98

Expected Behavior

The go SDK should generate the same filenames as the other SDKs and CLI.

Current Behavior

The go SDK computes the filename only based on the start URL, which makes it unable to find the right cached credential file produced by the CLI.

Reproduction Steps

1. Create an AWS profile in ~/.aws/config enabled for SSO, that has an sso_session
2. Run aws sso login --profile <that profile>
3. Run retrieve passing in the info for that profile (which can only include the account, startUrl, etc; but won't include the session name)

Possible Solution

Replicate the logic in the botocore SDK

Additional Information/Context

No response

AWS Go SDK V2 Module Versions Used

latest version has this issue

Compiler and Version used

n/a

Operating System and version

Mac

[RanVaknin]

Hi @schrobot ,

It's not clear under which circumstances the Go SDK is not able to resolve certain filenames?

I have used the aws sso login --profile x both with a profile that has a start URL, and one that uses a sso_session parameter and in both cases Im able to use the Go SDK to use that SSO profile and make requests as usual.

For example:

[profile my-sso]
sso_region = us-east-1
sso_start_url = https://d-REDACTED.awsapps.com/start
sso_registration_scopes = sso:account:access
sso_account_id = REDACTED
sso_role_name = s3FullAccess

and

[profile my-new-sso-3]
sso_session = my-new-sso-session-3
sso_account_id = REDACTED
sso_role_name = s3FullAccess

[sso-session my-new-sso-session-3]
sso_region = us-east-1
sso_start_url = https://d-REDACTED.awsapps.com/start
sso_registration_scopes = sso:account:access

I'm able to use both of these profiles to run s3 code perfectly using the SDK.

Does this only manifest when using the https://github.com/awslabs/amazon-ecr-credential-helper?

Are you able to write an in-depth reproduction just using the SDK without credential helper that can exhibit this behavior?
It would be helpful if you can also show how your profile is set up.

Thanks,
Ran~

[wty-Bryant]

Hi, thx for your feedback, I just checked v2's implementation of sso cred provider, current config cred resolution will resolve a sso token provider, which use the session name to generate the cached token path. According to your workflow, the session name should be respected to get the cached token file.

Could you clarify what version of sdk go v2 are you using in your repo? If it is too old, the sso token provider might not present to detect the sso session and resolve cached file from that

[schrobot]

Hi, thx for your feedback, I just checked v2's implementation of sso cred provider, current config cred resolution will resolve a sso token provider, which use the session name to generate the cached token path. According to your workflow, the session name should be respected to get the cached token file.

Could you clarify what version of sdk go v2 are you using in your repo? If it is too old, the sso token provider might not present to detect the sso session and resolve cached file from that

Thank you for getting back so quickly, and for those pointers. I took a look at the version the helper uses, and what's committed to main is later the version that added the resolution you linked to. However the helper has not been released in ~1 year, and the SDK dependency the released version uses is much older. I was able to clone the helper repo, and build and run the helper locally using the latest code on main, and that seems to work as I'd expect--properly using the session name to construct the cache key, if it is specified. So, I believe the https://github.com/awslabs/amazon-ecr-credential-helper project just needs to release a new version with the latest code they have in their repo. Thank you for the help, and apologies for the disruption on your side!

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.