OKTA_AWSCLI_CACHE_ACCESS_TOKEN=true does not work

[nikitaromm]

Version:

okta-aws-cli version 1.1.0
okta-aws-cli_1.1.0_darwin_arm64.tar.gz

Description:

When utilizing OKTA_AWSCLI_CACHE_ACCESS_TOKEN=true, we encounter an issue while attempting to log in for the second time. The error message received is as follows:
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'."

Steps to Reproduce:

1. Enable OKTA_AWSCLI_CACHE_ACCESS_TOKEN=true.
2. Successfully log in for the first time using the tool.
3. Upon attempting to log in for the second time, the "invalid_grant" error occurs.
4. Removing the token rm ~/.okta/awscli-access-token.json resolves the issue, but this prevents us from using the cache token feature.

Expected Behavior:

We should be able to use the cache token feature (OKTA_AWSCLI_CACHE_ACCESS_TOKEN=true) consistently without encountering the "invalid_grant" error on subsequent login attempts.

Additional Information:
We have multiple AWS accounts, and the ability to use the cache token feature is crucial for our workflow. This problem started occurring approximately two to three weeks ago, as before that, the caching feature worked great. It happens in the latest okta-aws-cli version as well. Assistance in resolving this issue would be greatly appreciated.

[monde]

@nikitaromm do you know if your session was logged out with the window of the cached token expiry window? Maybe your org has a policy that is causing log out on some trigger? I am releasing a token retry in #118 that will be released as v1.2.2 today. If the token gets an API error okta-aws-cli will jump back out to the device auth loop via the browser.

[monde]

note to self: maybe this is duplicate

[nikitaromm]

Hi @monde,
Thank you for the update. I'm not certain if our company has a policy regarding this matter, but I'd be happy to look into it. Could you kindly provide guidance on where I should begin my search?

Additionally, I wanted to mention that I recently updated the tool to v1.2.2. It appears that with this version, a web browser opens each time I use the tool instead of using the token. In previous versions, this behavior occurred when the OKTA_AWSCLI_CACHE_ACCESS_TOKEN was set to false. Unfortunately, we are still can not using the token caching feature.

Thanks

[nikitaromm]

Hi @monde,
Any updates on the issue?

[monde]

@nikitaromm I'll take a look and see if I can reproduce. If it's something obvious I'll see about a fix as v1.2.3. That said, all my effort is going into v2 of okta-aws-cli which has many improvements. You can try out a beta https://github.com/okta/okta-aws-cli/releases/tag/v2.0.0-beta.1

Remind me, in your use of v1.2.2 all of the arguments are by environment variables and you don't have a .env file in the directory from which you run your command?

[nikitaromm]

@monde yes, we are using environment variables. Just tried the beta version and seems it does not write creds into ~/.aws/credentials. I have OKTA_AWSCLI_WRITE_AWS_CREDENTIALS=true, OKTA_AWSCLI_AWS_CREDENTIALS=~/.aws/credentials, OKTA_AWSCLI_FORMAT=aws-credentials

[monde]

@nikitaromm can you give https://github.com/okta/okta-aws-cli/releases/tag/v2.0.0-beta.2 a try? I verified there was a bug in v2 (that was causing a panic 😢 ) in how it writes the aws credentials file. I fixed that.

I'm on a macbook, I verified the cli was working for me using env vars as settings. Let me know what you find.

$ echo $OKTA_AWSCLI_AWS_CREDENTIALS
# just a new line here

# cli will use golang home dir code to find $HOME/.aws/crendentials if not set by operator
$ go run cmd/okta-aws-cli/main.go web
# more output ...
Updated profile "default" in credentials file "/me/.aws/credentials".

$ export OKTA_AWSCLI_AWS_CREDENTIALS=~/.aws/credentials
# more output ...
Updated profile "default" in credentials file "/me/.aws/credentials".

[monde]

addressed in https://github.com/okta/okta-aws-cli/releases/tag/v2.1.0