Default AWS profile is set even if profile is configured

[joshes]

Describe the bug
When using a profile, both [default] and [profile] entries are configured in the ~/.aws/credentials file.

To Reproduce
Steps to reproduce the behavior:

Example configuration:

[classic]
profile = classic
base-url = myorg.okta.com

1. With a working configuration, set the profile to a valid string (classic in the above example)
2. Confirm the ~/.aws/credentials [default] section is empty or non-existent
3. Run okta-awscli -o classic and go through the auth flow
4. Confirm the ~/.aws/credentials [default] section now exists and is duplicated by the [classic] section with the same sts credentials

Expected behavior
Only the [classic] profile to be configured

Output
Output of your okta-awscli run, using the --debug flag.

INFO - No existing credentials found. Requesting new credentials.
INFO - App Link set as: https://[redacted].okta.com/home/amazon_aws/[redacted]/272
INFO - Authenticating to: [redacted].okta.com
INFO - Authenticating as: [redacted]
INFO - Using pre-selected factor choice                                          from ~/.okta-aws
INFO - Performing secondary authentication using: OKTA
Waiting for push verification...
INFO - Using predefined role: arn:aws:iam::[redacted]:role/ProductOperations-Administrator
INFO - Authenticating to: [redacted].okta.com
INFO - Session token expires on: 2022-06-07 00:24:11+00:00
INFO - Temporary credentials written to profile: classic
INFO - Invoke using: aws --profile classic <service> <command>
INFO - Setting default profile.

Environment (please complete the following information):

• OS: MacOS, Monterey 12.4
• Version of okta-awscli: 0.5.4

Additional context
This also happens when the sts credentials are checked. For example, you can delete the [default] entry and leave the [classic] entry and re-auth and it will re-add the [default] section.

[joshes]

I have a commit that addresses this, but thinking the whole notion of the [default] profile should be reassessed. If the expectation that it only displays the STS credentials to stdout if no profile is given, then it would always need to be explicitly set by the user as -p default which doesn't make sense.

Maybe the better solution would be to remove it entirely, simplifying things in the process and making it more explicitly clear about expectations.

• When no --profile and no --verbose means, basically a no-op
• When --profile is given and --verbose we can do both
• When --profile is given only we use that (even if it's default)

The other option is when no --profile is given we could set it default but I think this is a poor idea as the user may just want to get the STS credentials to stdout.

[mildmojo]

In my case, my script needs to fetch separate credentials for two profiles, so I call okta-awscli twice. Since every okta-awscli run rewrites the [default] profile credentials unconditionally, the last one "wins". For UX reasons, I need to get credentials for first-profile before second-profile, but I need default to point to first-profile.

My workaround is to run okta-awscli one more time to set the default profile. It's ugly, but it works.

okta-awscli --okta-profile first-profile --profile first-profile --verbose
okta-awscli --okta-profile second-profile --profile second-profile --verbose
okta-awscli --okta-profile first-profile --profile first-profile --verbose

The last call is basically a no-op since I already have valid credentials for first-profile, but it resets the default creds to match first-profile.

For my case, something like a --not-default or --preserve-default option would work fine, so I can prevent it from setting default credentials in some cases.

[xgt001]

Running into this as well and I am using a workaround by running export AWS_PROFILE=my-original-preoverwritten-profile when the default profile is overwritten by okta-awscli