[solution] Error: fetching SSO web token received API response "400 Bad Request", error: "invalid_grant", description: "The application's assurance requirements are not met by the 'subject_token'."

[monde]

Edit: see #153 (comment)

We'll add these notes to the README as well:

If you are seeing Error: fetching SSO web token received API response "400 Bad Request", error: "invalid_grant", description: "The application's assurance requirements are not met by the 'subject_token'." then try these remedies:

Check if the AWS Fed App policy is set to device: registered, or device: managed

Check if the the AWS Fed App policy re-auth is set for 'every attempt'

'every attempt' is hit and miss, much like if you login to the Okta dashboard and hit the admin button immediately you get right in, but if you wait 5 seconds might get prompted for MFA again depending on policies. Customers run into this off and on not knowing the reason. When they modified the AWS Fed App policy to be Re-authenticate after: 2 minutes they never saw this issue again. You can mimic this by setting the policy for AWS fed app to re-auth 'every attempt'. Then in the okta-aws-cli introduce a 5 second sleep before the web sso token exchange and you will see this error even if you don't usually see it when re-auth 'every attempt' is set.

[michaeldop]

I think I just ran into this issue when I started moving polices today for our fed apps. The issue also occurs when I set the policy to be Never re-authenticate if the session is active. I am not sure if this is expected behavior either.

In this mode I have even seen it open the device activation twice:

System web browser will open the following URL to begin Okta device authorization for the AWS CLI

https://XXXXXXX.okta.com/activate?user_code=GTCXJVJK

System web browser will open the following URL to begin Okta device authorization for the AWS CLI

https://XXXXXXX.okta.com/activate?user_code=QPRQMJPN

Error: fetching SSO web token received API response "400 Bad Request", error: "invalid_grant", description: "The application's assurance requirements are not met by the 'subject_token'."
Usage:
  okta-aws-cli [flags]

Only when I set it to Re-authenticate after: XXX that I stop seeing this issue

[punmechanic]

We're experiencing the same issue. Setting the app to reauthenticate after a time period works for some applications, but not all. This broke after things worked fine for a few days so I am not convinced this is a problem with the application, but potentially a bug with the token exchange endpoint @ Okta.

[monde]

I believe a feature in the Okta service caused this issue and was rolled back Wednesday. I'll keep this issue open for a week.

[wpline]

We're having the same issue, but only one of our aws accounts is throwing fetching SAML assertion received API response "400 Bad Request". Can you provide the name of the feature that's causing this? Thanks.

[wpline]

Our issue was a missing colon in the Identity Provider ARN (Required only for SAML SSO) between IAM and the AWS account number. Not sure how that happened as there's no log of it being changed.

[monde]

@wpline if you believe the IdP ARN value changed on the Okta side, outside of any Admin doing click ops in the Admin UI, please open a support ticket ASAP https://support.okta.com/ . We need to find out why that value changed on the Okta side.

And reference this GH comment / issue.

[acelinkio]

Can this get some additional attention? Appears the Production 2023.11.0 rollout happened and this activity is back. Getting the same bad request errors.

Error: fetching SSO web token received API response "400 Bad Request", error: "invalid_grant", description: "The application's assurance requirements are not met by the 'subject_token'."
Usage:
  okta-aws-cli [flags]

[QuentinBtd]

Same as @acelinkio,

okta-aws-cli is inusable. The bypass that worked initially no longer works.

EDIT: case opened on Okta Support

[gg-chrisd]

We're seeing this, too. Is there any update?

[mccartni-aws]

My team is also seeing this. An urgent fix is required, thanks.

[QuentinBtd]

I was on call with Okta support.

There is a temporary workaround:

In the authentication policy, set User must authenticate with to Password only. It is recommended to use the condition User's IP is set on In any of the following zones: with your Offices/VPN's IPs declared in zones.

For my case, I have one policy for AWS Fed APP, and another for okta-aws-cli OIDC app. I've added a rule (with the configurations described above) on the two policies.

[Will282]

@monde Are you able to share any info/timeline on a fix? Many thanks!

[QuentinBtd]

For more informations: https://status.okta.com/#incident/a9C4z000000TXHaEAO

[QuentinBtd]

It should be resolved 🎆

https://status.okta.com/#incident/a9C4z000000TXHaEAO

[monde]

Closing now. I kept this open to surface Okta API status information affecting this feature at the time it occurred. This is no longer an issue in the Okta API.

[estokes-vs]

@monde hello, this issue has been happening for a few of our end users with seemingly little cause. Is there another Okta API service issue over the past few days that may have caused this to happen? The errors we are seeing are identical to the ones posted above, and I'm not finding anything in this thread that points to a misconfiguration on our end as our policy mandates Reauthenticate after 12 hours.

Is the temporary workaround of requiring Password Only instead of Any two factors still in play?

Web browser will open the following URL to begin Okta device authorization for the AWS CLI

https://XXXXXXX.okta.com/activate?user_code=VPHCPQTR

Web browser will open the following URL to begin Okta device authorization for the AWS CLI

https://XXXXXXX.okta.com/activate?user_code=PQRBBXQV

Error: fetching SSO web token received API response "400 Bad Request", error: "invalid_grant", description: "The application's assurance requirements are not met by the 'subject_token'."

[rlister]

Also seeing this the last few days. The issue is highly sporadic.

[monde]

I'd open a support ticket with Okta Support when you all see this error https://support.okta.com/

okta-aws-cli is consuming Okta's API as a 3rd party and we aren't running in the core service.

[tkant]

@monde The issue resurfaced, can we please re-open this?

[monde]

@tkant Open a support ticket with Okta support https://support.okta.com/ . Again, this is an issue with the Okta API not okta-aws-cli. The CLI is a downstream consumer of the API, it doesn't control the API, and only reflects back errors given by the API.

Github issues on this repo are for flaws in the CLI itself as well as feature requests.

I'd open a support ticket with Okta Support when you all see this error https://support.okta.com/

okta-aws-cli is consuming Okta's API as a 3rd party and we aren't running in the core service.

[oswanderson]

[SOLVED] Hey, everyone 👋 leaving it here just in case someone is still facing the same issue, so this may help. On my case, I really believe it was an old session scenario where my current authentication/policy required a new authentication method that the previous one did not require. Although I was already enrolled on this new one, the CLI was still getting this error (no one else in my team had faced this error before).

I deleted every trace of credentials and config I could find and yet nothing worked. I was trying to brute force reset my okta session. I even restarted my laptop. Since nothing worked, I simply logged out using the browser and tried to login again using the CLI. The CLI took me to the Okta page for the credentials input. I believe the session was reset at this moment. After this, the error stopped. Good luck 🤞

[monde]

Thank you @oswanderson I'm going to pin this for other to see.

[bioshazard]

I have to open an Incognito session with the auth URL to get around this error