Is there SSO credentials resolution documentation?

[iainelder]

botocore documents its credential resolution chain like this:

Boto3 will look in several locations when searching for credentials. The mechanism in which Boto3 looks for credentials is to search through a list of possible locations and stop as soon as it finds credentials. The order in which Boto3 searches for credentials is:

1. Passing credentials as parameters in the boto.client() method
2. Passing credentials as parameters when creating a Session object
3. Environment variables
4. Shared credential file (~/.aws/credentials)
5. AWS config file (~/.aws/config)
6. Assume Role provider
7. Boto2 config file (/etc/boto.cfg and ~/.boto)
8. Instance metadata service on an Amazon EC2 instance that has an IAM role configured.

SSO credentials aren't mentioned here. Implicitly are they handed by step 5 or step 6?

In any case, it would be great to see in the documentation how and when the SSO credentials are resolved.

(By the way, I can find the credential documentation for botocore's credential resolution only in boto3. If there's some where else I should look please let me know!)

[stobrien89]

Hi @iainelder,

Thanks for pointing this out. sso credentials are actually handled by a separate provider (sso provider), which is a profile-based provider which first searches for a valid sso config and then for cached sso credentials. This happens between step 6 and 7. In my opinion, this should definitely be included in the boto3 credential resolution documentation, but I'll check with the team to see if it was intentionally excluded.

Although credential resolution is not documented in botocore, the behavior is essentially the same. I do think that would be worth documenting as well.

[iainelder]

Although credential resolution is not documented in botocore, the behavior is essentially the same.

The config key sso_start_url appears only in the botocore repo. From this I assumed that the botocore behavior is the behavior for boto3, AWS CLI, and everything further up the stack.