aws
SSO Login command requires browser support. Requesting feature to support terminal interaction.
"aws sso login" requires browser support on the machine. This is problematic in environments where there is no browser (ssh jumphosts and automation machines). Open source tools like aws-azure-login and saml2aws support this feature but require tedious configuration. It would be really useful if awscli supports this right out of the box.
#5301 has a few more details on this , the resulting feature should also allow opt-out from opening a browser even if the machine does have a browser. The user should be allowed to opt-out of automatically launching a browser and instead to use the URL and code from the console to grant access from a separate machine than the one running the aws sso login or aws configure sso commands.
@ppandey2004 The default behavior is that the browser is automatically attempted to be opened but if it fails for some reason manual instructions and links should be printed instead. Is this not functioning correctly for you?
Greetings! It looks like this issue hasn’t been active in longer than a week. We encourage you to check if this is still an issue in the latest release. Because it has been longer than a week since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or add an upvote to prevent automatic closure, or if the issue is already closed, please feel free to open a new one.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hey! thanks for responding. I understand that the browser doesn't have to be on the machine which is trying to authenticate but it is still something that requires manual/human intervention.
Scenario - An automation system has an identity in our IDP. The system (server - physical/virtual) tries to deploy resources in the AWS.
Expected behavior - System should be able to deploy resources without human intervention. One click deploy.
Current behavior - Automation has to pause while the initiator validates access.
Possible solution - aws sso login --profile <PROFILE_NAME> accepts credentials via the command line. No browser support required as long as the machine can provide credentials on the terminal itself.
@onitake thinks this is probably unsolvable, is he right? We have a couple of automated scripts outside AWS that run aws-cli commands. If manual intervention is always needed, it would be better to switch back to IAM access keys
@shrivastavshubham34 Yes, I think this isn't solveable, at least not in aws-cli. The very nature of SSO Login is that it requires you to set up a session token by logging into a third-party service. If you'd like to have full automation, I guess it will be necessary to roll your own tool. The AWS SSO API was recently extended and it should be possible to do so now.
Absolutely, API launched should help you setup bunch of CURL commands in an automated script. I guess that will be the approach I'll be taking. Thanks for reminding me about SSO API, totally forgot about that.
Note that the documentation is split into separate pages, the one you probably need is the OpenID Connect API: https://docs.aws.amazon.com/singlesignon/latest/OIDCAPIReference/Welcome.html
It seems to me that this is also the API that aws-cli uses for aws sso login.
For fully-automated use cases, why not just create a service user in IAM, give it credentials, then use those longer-term credentials in your CI/CD pipeline? SSO is for human beings, not robots.
It's still a normal case for human being to work on a headless server (e.g. remotely connected via ssh). And having to copy-paste code from there and open browser manually on another machine is a big annoyance.
Closing this issue as this PR was merged: https://github.com/aws/aws-cli/pull/6743
Parameter added here: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/configure/sso.html https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sso/login.html
--no-browser(boolean) Disables automatically opening the verfication URL in the default browser.
⚠️COMMENT VISIBILITY WARNING⚠️
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. If you wish to keep having a conversation with other community members under this issue feel free to do so.
@tim-finnigan I believe this issue should be re-opened. Being able to opt-out of the immediate browser open is one thing, but it's not the same as actually being able to login just through the CLI.
I can share some things I've discovered that others might find useful.
Open Specific Browser Profiles for SSO Login:
This can be achieved by setting the BROWSER env variable to a command that launches a specific profile.
In the case of Chrome on MacOS, that may look like this:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --args --profile-directory="Profile 1"
You can discover your possible profiles by running
ls ~/Library/Application\ Support/Google/Chrome
For myself, Default is the first profile I ever created for Chrome, Guest Profile is the guest profile, and Profile 1 is the second profile I setup on Chrome for this machine.
AWS SSO Login Entirely in CLI:
I was also able to go through the entire CLI SSO login flow on the CLI by using the browsh CLI web browser. It runs a headless Firefox and renders in your terminal. Of course, this was still pretty slow/painful and hard to read, but it even worked with my Yubikey usage with Google Workspace/GSuite as the IdP. I just went through the IdP flow and hit ctrl-w at the end to close the browsh browser.
This kind of works, but it's still a less than ideal setup.
BROWSER=~/Downloads/browsh aws sso login --profile <YOUR_PROFILE>
Closing this issue as this PR was merged: #6743
Parameter added here: awscli.amazonaws.com/v2/documentation/api/latest/reference/configure/sso.html awscli.amazonaws.com/v2/documentation/api/latest/reference/sso/login.html
--no-browser(boolean) Disables automatically opening the verfication URL in the default browser.
I agree this should be re-opened. The --no-browser feature from the closing comment does not address the use case described in this issue.
Thanks for following up here to clarify those points. I may have misunderstood the original request so will reopen this.
Although I appreciate looking into this further, I doubt it will be possible to implement the full authentication workflow in aws-cli.
As mentioned before, the AWS side has APIs available, but the IdP side can be completely arbitrary, and it will never be possible to capture every single IdP in aws-cli. Hence, my suggestion to roll your own tool that interacts with your specific IdP.
Yeah, I guess that's a fair take. A wrapper tool could capture the output of stdout which has the expected code and work off that. The BROWSER env variable control allows for the possibility of this.
Actually, one more thought: Even if we somehow managed to capture and resolve credentials for an IdP, there's still the webpage expecting users to hit "Allow" within AWS SSO. That means there's no escaping browsers even just for the AWS SSO side of it post-IdP auth.
there's still the webpage expecting users to hit "Allow" within AWS SSO
@bilalq Well this one at least is fully controlled by AWS, while they can't change the IdP, I suppose they can make this one a cli friendly one (input enter or bypass with --yes).
Thus, if the user was already logged to the 3rd party IDP with their default browser, and the token/cookie/whatever was inherited in a browserless instance launched by the cli, we could end up with zero user interaction needed
The fundamental problem here is that the OAuth spec assumes a browser. There are no widely-implemented standards for a programmatic interactive auth API. The CLI uses the OAuth Device Authorization Grant. There's no provision in the spec for the verification URI to respond with a standard set of information for prompting.
Without such a standard, AWS would have to implement a hacky screen-scraping implementation for every different IdP supported by Identity Center, which would break if the IdPs changed anything, which just isn't sustainable.
What I am wondering is: why is there no login flow that does NOT involve using a mouse? This approach feels so... out of place?
What I am wondering is: why is there no login flow that does NOT involve using a mouse? This approach feels so... out of place?
You should ask your IdP that question. They're implementing the device login interface how they see fit, and if it's not usable without a mouse, that's on them.
As @benkehoe mentioned, the OAuth standard is lacking a specifaction for non-interactive authentication, but ultimately it's the IdP that needs to implement it.
Saw this the other day and immediately thought of using it for SSO here. https://github.com/fathyb/carbonyl I get why this isn’t really feasible, however.
The main point is, even if every IdP provided a programmatic authentication interface, unless they all implemented a common interface, AWS SSO/Identity Center wouldn't be able to use it, because the whole point of it is that it doesn't require any IdP-specific code from AWS. That's why it would need to be something like an OAuth standard, rather than just, say, Okta creating some API.
It would be nice to have this available at least for the cases where native AWS auth UI is used to submit all of the credentials (e.g. when using the AD connector approach), in this case it's just user/password + AWS MFA all done on signin.aws pages, there are no external redirects.
Note that the API, and the associated OAuth spec, do not expose what IdP is being used (on purpose, it's supposed to be irrelevant to the client).