How to let awscli automatically login sso session when the current session turns out to be expired before execution

[zzJinux]

Whenever the AWS CLI complains that the session token has expired (Error when retrieving token from sso: Token has expired and refresh failed), I manually run aws sso login --sso-session. This is tedious, and I couldn't find a way to automate this.

1. Does the AWS CLI have built-in support for this?
2. (If not) any known solution for it?

[uldyssian-sh]

AWS CLI does not have a built-in “auto-run aws sso login” feature when an SSO token is expired.

For security reasons the CLI will not silently re-authenticate, because SSO login may require interactive browser/device authorization. When the cached SSO token expires and refresh fails, the CLI returns the error you see and expects you to re-run aws sso login.

What you can do instead:

Use the device-code flow (often easier to script around in terminals):

aws sso login --profile my-profile --use-device-code

Wrap your AWS CLI calls in a small script that retries once after triggering login. Example pattern:

aws sts get-caller-identity --profile my-profile 1>nul 2>nul || aws sso login --profile my-profile
aws --profile my-profile

Or, if you are using named SSO sessions (sso-session), call login for that session:

aws sso login --sso-session mysession

Practical recommendation:

Run aws sso login once at the start of your workday (or before CI steps that require it). The CLI will reuse the cached token until it expires, but it will not auto-renew via an interactive login on its own.

[uldyssian-sh]

Thanks! If this helps, please consider marking it as “Helpful” or “Accepted” 😊

[zzJinux]

For security reasons the CLI will not silently re-authenticate,

I understand it. But it doesn't have to be slient. The CLI may ask for your consent to proceed with the SSO login (or anything re-authentication flow the user has configured) when the original command fails with auth.

Use the device-code flow

Would you explain what you meant by this? Does it have something to do with automation?

Wrap your AWS CLI calls in a small script

Any way to tell if the command fails due to auth expiration?

Run aws sso login once at the start of your workday

Unfortunately for my case, the duration is not long enough that I have to run 2~3 aws sso login a day. 😢.

Thank you for having a look at the question.

[zzJinux]

@uldyssian-sh Are you AWS employee?

[uldyssian-sh]

1. “It doesn’t have to be silent — CLI could ask for consent and then run SSO login”

Current behavior (example):
You run:
aws s3 ls --profile dev

Your SSO session is already expired. The CLI immediately fails with:
Error when retrieving token from sso: Token has expired and refresh failed

The CLI will NOT:

• Ask “Do you want to login now?”
• Launch a browser or device-code flow automatically

Required manual step:
aws sso login --profile dev
aws s3 ls --profile dev

If you want this behavior automatically, you must wrap it yourself, for example:

• Run aws s3 ls
• If it fails with the SSO token error, call aws sso login
• Retry aws s3 ls

2. “What do you mean by device-code flow — does it help automation?”

Normal browser-based login:
aws sso login --profile dev
→ Browser opens automatically, you sign in, CLI continues.

Device-code login (example in SSH / remote terminal):
aws sso login --profile dev --use-device-code

CLI prints something like:
Enter the following code in your browser: ABCD-EFGH
Visit the sign-in page and complete authentication

You open a browser on any machine, enter the code, approve access.
The CLI then completes the login.

Important practical point:

• You still must be present to enter the code and approve access.
• A CI job or cron task cannot complete this.
  So device-code flow improves usability in headless terminals, but does not remove the human step.

3. “Any way to tell if the command fails due to auth expiration?”

Direct command example:
aws sts get-caller-identity --profile dev

Expired session output:
Error when retrieving token from sso: Token has expired and refresh failed
(exit code ≠ 0)

Wrapper logic example (conceptual):

• Run aws sts get-caller-identity
• If it succeeds → proceed
• If stderr contains “Error when retrieving token from sso”
  → run aws sso login --profile dev
  → retry aws sts get-caller-identity
• If it fails for another reason (AccessDenied, network error, typo)
  → do NOT retry login

This avoids unnecessary logins and avoids masking real errors.

4. “I have to run 2–3 logins a day — duration isn’t long enough”

Example scenario:

• IAM Identity Center portal session duration: 4 hours
• Permission set session duration: 1 hour

What happens in practice:

• Every hour, role credentials expire → CLI transparently refreshes them.
• After ~4 hours, the SSO refresh token is no longer valid.
• Next AWS CLI command fails with “refresh failed”.
• You must run aws sso login again.

Administrative fix example:

• Increase the IAM Identity Center portal session to 8 or 12 hours.
• Increase the permission set session duration to match typical work blocks.

Result:

• You might only need to login once per workday instead of multiple times.
• No CLI flags or environment variables can override these limits; they are enforced server-side by Identity Center.