Re-resolve SSO access token on each credential refresh instead of caching it at construction time

[alextwoods]

Re-resolve SSO access token on each credential refresh in the SSOCredentialsProvider instead of caching it at construction time ensuring that refreshed tokens (for example from running aws sso login) are always used

Motivation and Context

Fixes #3777

Currently we are incorrectly caching the token at construction time instead of refreshing it each time we perform a credentials refresh.

Modifications

• Move token resolution into the supplier.
• Unify invalid token exception handling.

Testing

New and existing test

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license

[joviegas]

suggestion (non-blocking): When expiresAt is missing, this throws the same generic DEFAULT_MESSAGE as an expired token. The old code gave a specific message here: "The SSO session's expiration time could not be determined." Can we keep a distinct message for the expiresAt == null case so a malformed token file is easy to tell apart from an expired one.

[alextwoods]

From a user perspective, the action is the same (re-authenticate) - so I was following the more recent guidance from the login credentials provider which uses a single exception/error message for any issues with the token file since the user action is always the same: re-authenticate (eg, run aws sso login).

[joviegas]

Just trying to make sure I understand this correctly. As far as I can tell SsoCredentialsProvider doesn't set staleValueBehavior anywhere, so wouldn't this be STRICT by default rather than ALLOW? Curious where ALLOW kicks in?

[alextwoods]

Ah yeah good call out - I had these changes originally in my static stability branch, but then pulled them out to release separately. I'll remove this test (and re-add it in that branch once this is merged....)

[github-actions]

This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one.