Support programmatic AWS SSO authentication in botocore v1 without AWS CLI v2

~I’m looking forward to the AWS CLI v2 allowing aws login to connect with AWS SSO. I’m also excited that the auth token retrieved by the CLI is managed by botocore, because it means scripts using the boto3 SDK can be run with the identity from aws login. However, it would be great if scripts could manage their auth directly without involving the CLI.~

With botocore 1.17, support for loading credentials cached by aws sso login has been added. This still means that Python applications cannot initiate AWS SSO auth, requiring their users to also install and understand the AWS CLI.

I’m asking for three things:

1. Make the SSOTokenFetcher.on_pending_auth hook a provider-based system like the one for credentials.
2. Move the browser provider from the CLI into botocore, so a script using boto3 can use browser-based authentication (I guess I would also want a provider that only ever did the “print url+code instructions” too)
3. Add a process provider like credentials have, so that users can implement alternative auth schemes against their IdP (for example, a browserless flow on headless systems like EC2 instances).

[benkehoe]

@0xW1sKy I have written aws-sso-lib for programmatic AWS SSO functionality, and aws-sso-util for things like generating profiles for all AWS SSO account+roles. Your script looks like it writes to ~/.aws/credentials as well, which I have aws-export-credentials for (that works with all kinds of AWS credentials)

[joguSD]

Following up on this now that the provider has been back ported into botocore v1.

For now, we have no immediate plans to expose the interfaces to programmatically resolve SSO credentials and store them in the shared caching location beyond the credential provider. There’s a few reasons we’ve decided to keep these private and here are some of the highlights:

1. Given the asynchronous nature of resolving / using the SSO credentials it’s potentially problematic to have multiple processes attempting to perform the login flow at once. Theoretically, this is possible even with a single tool (i.e. CLI V2) just a lot less likely given that the login flow is explicitly invoked rather than some implicit attempt to refresh.
2. Currently, SSO login attempts need to be explicitly requested by the user (via CLI V2) and not implicitly invoked as part of an attempt to use those credentials. This has the benefit of vastly simplifying the credential provider, as the process of performing an SSO login is not an implicit part of being a compliant provider. Additionally, this falls more inline with the guidance in the device authorization RFC:

To avoid unneeded requests on the token endpoint, the client SHOULD only
commence a device authorization request when prompted by the user and not
automatically, such as when the app starts or when the previous authorization
session expires or fails.

1. Individual tools concerned with using a profile configured to use SSO credentials all ensuring the underlying login token is up to date and prompting for login flows seems like an anti-pattern. As the credentials are shared, any process using said credentials will all attempt to initiate the login flow without the knowledge of any other tool attempting to do so. The end result is the user being prompted by multiple tools to complete the login, which seems annoying at best, and hostile/broken at worst. By adding and supporting public interfaces for this in the SDK we’re promoting scenarios where multiple tools think they’re responsible for refreshing the login session. Ultimately, we want to limit the number of tools concerned with performing this logic.

Realistically, only one process needs to refresh the underlying SSO login session to ensure the credential provider can exchange for credentials using the shared cached session token. That being said, I definitely agree that there are improvements to be made on the current workflow. Ideally, in my mind this would be some kind of daemon that monitors login sessions and can notify the user when their credentials may be close to expiration to refresh the login session (e.g. via notifications, the task/menu bar, etc).

As a question, is there anything specifically about using the CLI v2 to perform the SSO login that’s a hard blocker?