[v2] invalid grant when doing sso login

[trondhindenes]

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:

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]

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]

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]

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]

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]

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

[Umkus]

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

[joguSD]

@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]

thank you, this has also helped me.

[vineethelias]

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

[sidewinder12s]

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]

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

[kappasairam]

thank you It was helped for me to.

[nickollascoelho]

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

[bhiravabhatla]

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

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

[abd-shouman]

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?