aws / aws-cli

Universal Command Line Interface for Amazon Web Services
Other
15.13k stars 4.02k forks source link

[v2] invalid grant when doing sso login #5058

Open trondhindenes opened 4 years ago

trondhindenes commented 4 years ago

Here's what I do and what happens:

OS: Ubuntu 19 with chrome as default browser. aws cli version aws-cli/2.0.2 Python/3.7.3 Linux/5.3.0-40-generic botocore/2.0.0dev6 I wipe the ~/.aws folder. Chrome is open, and I'm logged in to my landing page ('https://.awsapps.com/start#/' I run aws configure sso --profile platform-nonprod, get prompted for start url (I copy in the open url from Chrome) and region (eu-central-1).

the aws cli opens a new chrome tab, and after 1 or 2 redirects, I get prompted to "Sign in to AWS CLI". Once I hit that button, I get this:

Screenshot from 2020-03-12 15-02-07

According to chrome dev tools, this is the url that fails: https://oidc.eu-west-1.amazonaws.com/device_authorization/associate_token, which returns a HTTP 400 with this payload: {"error":"invalid_grant","error_description":"Invalid grant provided"}

The same thing happens if I use another browser: BROWSER=brave aws configure sso --profile myprofile

All in all, I'm unable to use sso from aws cli v2.

trondhindenes commented 4 years ago

Update on this. The steps above was when I chose "eu-central-1" as the region, since that's the region we have most of our stuff. However, I can see that the "device_authorization" url that fails is in the eu-west-1 region which makes sense because that's where the AWS SSO instance is running. Actually, eu-central-1 isn't even a valid choice for AWS SSO afaik.

So, if I chose the region "eu-central-1" in the "aws configure sso" dialog, everything works as it should. I guess it would maybe make sense to see if its possible ti discover that the user has chosen an incorrect aws sso url (maybe by doing a dns query on the SSO start URL value or similar.

In any case, I'm not blocked by this, it was a user error after all.

KaibaLopez commented 4 years ago

Hi @trondhindenes , Glad to see you found your problem, I saw that you closed and reopened the issue though, is there anything that you're missing about this? Are you asking for a clearer error or a get endpoint function?

trondhindenes commented 4 years ago

I reopened it because I'm thinking that there are things that can be done to make sure this doesn't happen. For instance, AWS SSO isn't available in eu-central-1 so ideally that shouldn't be in the list of regions that are suggested. I don't know if its possible to lookup a list of available regions dynamically, I fully understand that those types of things shouldn't be hardcoded in a library.

Further, the error message itself is difficult to understand, but I'm guessing that this is something that maybe has to be fixed by AWS SSO rather than in this repo.

So, I decided to keep it open just in case there's anything that can be done to improve the experience from the cli side of things. Feel free to close if there isn't.

KaibaLopez commented 4 years ago

Yea I think this is all reasonable, I'll ask around see what can be done and update you, probably I'll end up escalating to the service teams so even if we can't improve these things from the sdk we might be able to get the services to do something for us.

vibhuyadav commented 4 years ago

Changing it to the correct region worked for me too. Thanks

Umkus commented 4 years ago

Thanks! This helped me as well. The correct region was us-east-1.

joguSD commented 4 years ago

@trondhindenes The list of available regions that are suggested is based on the list of regions that SSO is modeled to support, which should be accurate. However, what we don't know is what region your specific SSO configuration is in.

Just to clear up any confusion, when creating/setuping up SSO as an administrator it's created in a particular region and all interaction with SSO must happen within that region, including logins by the end user. Right now, there isn't any official way to derive the region from the start url. Unfortunately, this means that one simply has to know the region their SSO configuration is in or get it from the administrator that created the SSO configuration.

I definitely agree that the error message is confusing. Ideally, the login flow would fail at the API level letting us know the incorrect region was used before we even redirect the user to the browser.

luisamador commented 4 years ago

thank you, this has also helped me.

vineethelias commented 3 years ago

Make sure you use the correct region. I got this same error while using the wrong regions.

sidewinder12s commented 3 years ago

Could this also happen if you:

  1. Run aws sso login
  2. Close the auto-opened Device Auth page
  3. Open the URL manually
  4. Copy Code

I just tried that flow and I get Verification Failed in the web page, though when I look at dev console I see invalid grant.

I am also using the us-east-1 device.sso page, which is where our SSO instance is homed.

Edit: I think is can happen in this case above, when AWS SSO opens the Device Verification page for you it actually submits the form for you as well, most likely making the device code displayed in the CLI invalid.

hollyjrobertson commented 3 years ago

Same issue - I was using us-east-1 for sso login. Tried east-2 = Worked GREAT! Thank you!

kappasairam commented 2 years ago

thank you It was helped for me to.

nickollascoelho commented 2 years ago

Same here, region issue! It's not clear in any docs and the error message doesn't help.

bhiravabhatla commented 2 years ago

Check the network call that happens when we click on Allow. It should have the right sso_region where sso device is present. image

Setting the sso_region to the one in the URL (oidc url) worked.

abd-shouman commented 1 year ago

Update on this. The steps above was when I chose "eu-central-1" as the region, since that's the region we have most of our stuff. However, I can see that the "device_authorization" url that fails is in the eu-west-1 region which makes sense because that's where the AWS SSO instance is running. Actually, eu-central-1 isn't even a valid choice for AWS SSO afaik.

So, if I chose the region "eu-central-1" in the "aws configure sso" dialog, everything works as it should. I guess it would maybe make sense to see if its possible ti discover that the user has chosen an incorrect aws sso url (maybe by doing a dns query on the SSO start URL value or similar.

In any case, I'm not blocked by this, it was a user error after all.

Great catch, it was the same issue with me as well. The SSO region I was using was different than the "device_authorization" URL.

I was wondering though how the "device_authorization" URL is set. Is it set by the admin?

jomojowo commented 11 months ago

I observed same issue as reported in these issue. aws version: aws-cli/2.11.20 Python/3.11.3 Darwin/22.4.0 source/arm64 prompt/off

Work-around for me: when I change my sso region to: us-east-1, it works. Which I believe these relates to the region that was selected during sso creation, in aws iam identity center.

Screenshot 2023-08-08 at 17 35 30
AlexAtkinson commented 11 months ago

Still getting this issue. Been waiting for years, AWS.

awscli version: aws-cli/2.13.10 Python/3.11.4 Linux/6.2.6-76060206-generic exe/x86_64.pop.22 prompt/off

jeremymcgee73 commented 9 months ago

I observed same issue as reported in these issue. aws version: aws-cli/2.11.20 Python/3.11.3 Darwin/22.4.0 source/arm64 prompt/off

Work-around for me: when I change my sso region to: us-east-1, it works. Which I believe these relates to the region that was selected during sso creation, in aws iam identity center. Screenshot 2023-08-08 at 17 35 30

I had the same issue with govcloud. This solved my problem, I noticed it was redirecting to another region than what was set.

ayoh1 commented 2 months ago

I had sso setup in ohio but wanted this profile to work in nvirginia, so this worked for me. in awscli config:

[profile your_env_name]
region = us-east-1
sso_region = us-east-2
...

Before I also had sso_region us-east-1 and was the problem. This way you can auth in one region and work in another. Hope it helps..