awscli does not respect Identity Center sso session duration length

[jeremymturner]

Describe the bug

When a user runs aws sso login, the returned SSO session token expiresAt returns a +8 hour value, regardless of what the administrator set under IAM Identity Center -> Settings -> Authentication -> Maximum session duration.

Note that this is not looking at a session duration of any permission sets, just at IAM Identity Center itself.

Expected Behavior

awscli should respect the value set under IAM Identity Center -> Settings -> Authentication -> Maximum session duration when it returns the expiresAt value.

Current Behavior

awscli returns the current time +8 hours

Reproduction Steps

rm ~/.aws/sso/cache/*; rm ~/.aws/cli/cache/*;
aws sso login
cd ~/.aws/sso/cache
echo expiresAt
cat $(ls -t . | head -n1) | jq -r ".expiresAt"
echo currentTime
TZ=Z date +%Y-%m-%dT%H:%M:%SZ

Possible Solution

Short-term fix:

1. Modify awscli to respect the Maximum session duration value in IAM Identity Center -> Settings -> Authentication -> Maximum session duration.

Long-term fix:

1. Provide a maximum session duration setting for console and a separate one for command-line
2. Modify awscli to respect the (new) command-line maximum session duration value

Additional Information/Context

Resolution of this would also complete the request asked for in #6547.

CLI version used

aws-cli/2.9.8 Python/3.11.0 Darwin/21.6.0 source/arm64 prompt/off

Environment details (OS name and version, etc.)

macOS Monterey 12.6.1

[tim-finnigan]

Hi @jeremymturner thanks for reaching out. This comment from the issue you linked mentioned how the https://docs.aws.amazon.com/singlesignon/latest/userguide/authconcept.html documentation page said:

Each time a user signs in to AWS SSO, a sign in session is created with an 8-hour lifetime.

That documentation has since been updated to note:

Each time a user signs in to IAM Identity Center, a sign in session is created for the duration configured in Identity Center, which can be up to 7 days. For more information, see Manage IAM Identity Center integrated application sessions.

This is what I see when configuring session settings in the IAM Identity Center:

You said you're using v2.9.8 which is currently the latest CLI version per the CHANGELOG. But you're saying that if you configure the session duration beyond 8 hours then it does not refresh the token?

If you have a support plan I recommend reaching out through AWS Support for direct assistance with issues like this.

[jeremymturner]

"You said you're using v2.9.8 which is currently the latest CLI version per the CHANGELOG. But you're saying that if you configure the session duration beyond 8 hours then it does not refresh the token?"

Correct. If I configure the session duration to 24 hours, the ~/.aws/sso/cache/*.json expiresAt value remains at 8 hours. I tried logging out and back in to my IdP, and removing all cached tokens in ~/.aws with the same behavior.

Additionally, I looked at the boto3 module docs under the sso and sso-admin sections, and it's not clear to me that there is an API that would return this information. https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/sso-admin.html

The actual token refresh (from SSO token to permission set/role token) seems to be working normally. It's just that the SSO token duration doesn't match what the UI has.

[tim-finnigan]

Hi @jeremymturner - I reached out to the SSO team regarding this behavior, as it came up in another recent issue. I added their response here: #7104 (comment)

This statement from the documentation: "When the AWS Command Line Interface (CLI) is used, AWS SSO uses the session duration setting on the permission set to control the duration of the session" is correct. Checking the access token which will always be 8 hours only. To check the permission set equivalent duration you need to check the file in the location ~/.aws/cli/cache.

So based on that explanation I believe this is the expected behavior.

[github-actions]

Greetings! It looks like this issue hasn’t been active in longer than five days. We encourage you to check if this is still an issue in the latest release. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or upvote with a reaction on the initial post to prevent automatic closure. If the issue is already closed, please feel free to open a new one.

[ronmegini]

The same thing happens here.
The session duration configured in the IAM Identity Center is 12 hours but the token generated by the AWS SSO login command expires in 8 hours.
Current time: 13:08:07, Expiration time (in ./aws/sso/xxx.json): "expiresAt": "2023-11-29T21:08:07Z".

For example with granted assume cli the session duration is indeed 12h: [✔] [development](us-east-1) session credentials will expire in 12 hours

Leave me a comment for further details.

[jishi]

Why was this closed?

I'm seeing the same thing, the iam identity center is completely schizofrenic. I have several AWS accounts that I can log into via identity center. Some of them will give me 8h tokens regardless of the session expiration setting in identity center, but now I notice that one of the accounts always give me a 1h token (!), probably due to sso configuring it at a later time (so something has changed?)

This is even more frustrating than having an 8h token.

Web console session length is even worse, I seem to be logged out seemingly randomly, even though I have set the session duration to 3 days.

[SampaioLeal]

@jishi i'm freaking out having to configure sso every hour
the real feeling is like every day the expiration time is reduced 🥲

[panda7zip]

regardless of what you are configuring in AWS Identity Center - you will get 8 hour access, why this is closed?

[hostmit]

+1, SSO configuration has no effect, it's always 8 hours

[UnbiasedGoat]

+1 - We're having the 1 hour issue - our expiresAt on the latest cli (2.23.7) is always 1 hour (I think it used to be 8) - we used to use it to check whether our creds were still valid but that doesn't work anymore and it seems we now have to login more frequently - in identity center itself it's set to 12 which is definitely not being respected