Cached Access_Token Causes Login Failure if AWS Fed App Id is not Specified and Okta Browser Session is Ended within the 60 Minute Access_Token Lifetime

[emanor-okta]

okta-aws-cli version v2.1.2

Description:

The CLI is run with the option to cache the access_token and no AWS Fed App is supplied. Login to CLI is successful. Then the browser session used for the device authorization flow logs out of the Okta Org session. If the access_token lifetime has not expired and the CLI is run again without specifying the AWS Fed App the device authorization flow will not take place. Instead the cached access_token will be used for the Web SSO Token Exchange which will fail with an HTTP 400,

{ "error": "invalid_grant", "error_description": "The 'subject_token' either expired or the session associated with it was terminated." }

Repo

1. Use the following for the first login okta-aws-cli -o {org} -c 0o.... -g -d -b -e -z
2. After Successful login, in the same browser session used for the device authorization flow navigate to the Okta dashboard and logout
3. Run the same CLI command again, okta-aws-cli -o {org} -c 0o.... -g -d -b -e -z
4. Will be prompted to choose AWS Fed App and then fail with the above error.

At this point the options are either wait for the access_token to expire, or manually delete it from the users storage.
If at step number 3 above an AWS Fed App id was provided, then the Device Authorization flow will run again and the user will be able to establish a new session.

Bug

The issue is when a AWS Fed App id is not provided to the CLI, the loop used to check for a bad access_token will succeed. This is because the call to listFedApps() using the access_token will work. The /apps management call does not require the underlying Okta session which the access_token was created from to still be valid. The call is successful, so there is no error in check after the call which would nil the access_token. When establishTokenWithFedAppID() is later called with the access_token, then the web sso token exchange call fails since it's security requirements are the underlying Okta session which the access_token is tied to still be active. This failure happens outside of the loop which would nil out a bad / expired access_token, and then kick off the device authorization flow.

When the AWS Fed App Id is supplied to the CLI, then the call to establishTokenWithFedAppID() happens within the loop to check if the AT is no longer valid, so when an HTTP 400 is returned from the failed web sso token exchange attempt, the device authorization code flow happens on the next iteration.

[emanor-okta]

@MikeMondragon-okta OKTA-731212

[monde]

Until a fix with a retry is implemented when an HTTP 400 error error: "invalid_grant" is seen the work around is to remove the cache file in the dot okta directory on the home computer and run the command again. On OSX rm ~/.okta/awscli-access-token.json