[v2] Session Duration of Permission Set is not respected by AWS CLI

[hamsec-aumni]

Describe the bug

When our users login via the AWS CLI using aws sso login the session duration is always 8 hours regardless of what the session duration is set in the corresponding permission set.

Expected Behavior

Per this 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

It is expected that what the Permission Set has for Session Duration should match the length of the session when using the AWS CLI

Current Behavior

Regardless if the Permission Sets Session Duration is set to 1, 2, 4, 12 hours or even Custom. When authenticated via AWS CLI it always returns an 8 hour session.

Reproduction Steps

1. Setup AWS SSO with IdP of choice

2. Configure Permission Set with a session duration at 1 hour:

3. Assign a Permission Set to an SSO user and AWS Account

4. The user configures their SSO profile in aws cli via aws configure sso and chooses the role corresponding to the above permission set

5. User is successfully logged in:

Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:

https://device.sso.<region>.amazonaws.com/

Then enter the code:

XXXX-XXXX
Successfully logged into Start URL: <redacted>

6. Check when the accessToken expires:

cat ~/.aws/sso/cache/bb33e6525b773e58656393b27ed0e66d75312f74.json | jq '.' | grep "expiresAt"

7. Note that it is 8 hours from the time the user authenticated and not 1 as set in the Permission Set

Possible Solution

No response

Additional Information/Context

This is a very big security concern as we can't have sessions for more permissive roles set to the minimum of 1 hour. Could be a backend issue for the SSO Service team per this closed issue

CLI version used

aws-cli/2.7.14 Python/3.9.11 Darwin/21.5.0 exe/x86_64 prompt/off

Environment details (OS name and version, etc.)

macOS 12.4 (21F79)

[tim-finnigan]

Hi @hamsec-aumni thanks for reaching out. Here is documentation on SSO that I think addresses the behavior you’re describing: https://docs.aws.amazon.com/singlesignon/latest/userguide/authconcept.html

Each time a user signs in to AWS SSO, a sign in session is created with an 8-hour lifetime. Each time the user accesses an AWS SSO-enabled application, the AWS SSO sign in session is used to obtain an AWS SSO application session for that application. AWS SSO application sessions have a refreshable 1-hour lifetime – that is, AWS SSO application sessions are automatically refreshed every hour as long as the AWS SSO sign in session from which they were obtained is still valid. When the user uses AWS SSO to access the AWS Management Console or CLI, the AWS SSO sign in session is used to obtain an IAM session, as specified in the corresponding AWS SSO permission set (more specifically, AWS SSO assumes an IAM role, which AWS SSO manages, in the target account).

So the default is an 8-hour session but you can customize the permission set session duration as you mentioned.

Are you saying the CLI behavior is inconsistent with that documentation or that the SSO design is the issue?

[hamsec-aumni]

Thanks for your response @tim-finnigan. It seems that the CLI behavior is inconsistent with that documentation. It doesn't seem to be an issue with SSO service because the console access does respect the session duration (if 1 hour it times out after 1 hour and the user needs to sign in again). Regardless of the session duration I set in the Permission Set the CLI session is always 8 hours.

[hamsec-aumni]

@tim-finnigan just wanted to bump this before this moves to "closing-soon". And to just to be clear the CLI behavior is inconsistent with that documentation as the CLI always requests the default 8 hour session regardless of what is set in the permission set.

[hamsec-aumni]

@tim-finnigan just checking in to see if there's anything else I can do to help your investigation on this. Do you need any additional configuration information?

[tim-finnigan]

Hi @hamsec-aumni thanks for following up. I'm still not sure if the behavior you're describing is inconsistent with the documentation shared earlier. For further explanation I found this knowledge center article and blog post. Have you tried authenticating with SSO and confirming that you still have permissions after their designed expiration time?

[hamsec-aumni]

I think you're right @tim-finnigan that I was confusing the expiry time value expiresAt of the JWT that is stored at ~/.aws/sso/cache/bb33e6525b773e58656393b27ed0e66d75312f74.json with the duration of the Permission Set of the role. The duration of the role with the attached permission set can be seen when running this command:

aws sso get-role-credentials --account-id $SSO_ACCOUNT_ID --role-name $awsrole --access-token $AWSACCESSTOKEN --region $awsRegion | jq '.' | grep 'expiration'
    "expiration": 1660952825000

The timestamp above is one hour from when I run that command, so the credentials returned if used would respect the Permission Set duration.

However, it's still an issue because it would seem with every aws command that leverages the IAM Identity Center (successor to AWS SSO) configured profile, makes a call against STS to perform the get-role-credentials call to request new roleCredentials that will expire one hour from the time the aws command was run. As long as the JWT token in ~/.aws/sso/cache is valid, every AWS CLI command gets a new roleCredentials with the session duration expiry time set forward from that moment. It's perpetually one hour in the future.

This is why when I configure my local SSO Profile ~/.aws/config/ to use the SSO Role with a permission set at any duration I can continuously return successful commands for 8 hours after the time when the JWT token was originally retrieved with aws sso login. The inverse is also true if I set the session duration to 12 hours the credentials requested at any moment with have a 12 hour duration but when the 8 hour JWT expiry time is reached, AWS CLI commands require another authentication using aws sso login.

Does that make sense?

[hamsec-aumni]

@tim-finnigan I think I found the documentation that explains exactly what I'm seeing and contradicts the documentation I referenced in my initial reporting of this issue.

In the setup guide for configuring AWS CLI to use AWS IAM Identity Center (successor to AWS Single Sign-On) it says:

As long as you signed in to IAM Identity Center and those cached credentials are not expired, the AWS CLI automatically renews expired AWS temporary credentials when needed. However, if your IAM Identity Center credentials expire, you must explicitly renew them by logging in to your IAM Identity Center account again.

And per the blog post you shared, the cached credentials stored at ~/.aws/sso/cache are always set to expire at 8 hours and that is not configurable as far as I know.

So when this documentation regarding setting the session duration says:

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. By default, AWS SSO-generated IAM roles for permission sets can only be assumed by AWS SSO users, which ensures that the session duration specified in the AWS SSO permission set is enforced.

It is misleading because although technically the role credentials returned (hidden to the user) when running any CLI command do respect the permission set, as soon as the role credentials expire AWS CLI will automatically renew them. Therefore, to the end user and effectively when running AWS CLI commands the access duration is always 8 hours irrespective of what's set in the permission set.

So I guess the only action item for you would be to request that this documentation be updated to properly reflect that.

Does this make sense? Furthermore do you know where else I could report this that might get this code redesigned to have AWS CLI effectively respect the session duration of permission sets?

[lorengordon]

I think I'm running into a similar instance of this issue. Since the aws-cli auto-refreshes the credential, I can usually run cli commands all day long without re-running aws sso login. However, other tools/SDKs do not auto-refresh the sso credential. So things like terraform/terragrunt fail at some point in the day and require re-running aws sso login before they work again. It is a very confusing user experience. I'd expect that once I run aws sso login, all tools would behave the same and the credential in all cases would respect the sso session duration.

[tim-finnigan]

Thanks for following up and providing more information, I've just had a chance to revisit this. I agree that the documentation could be clarified in this case. I created an internal ticket for the Identity Center team to look further into what needs to be updated and I'll post an update here when I hear back. In the meantime if your team is blocked by any service-related behavior we recommend reaching out through AWS Support for a more direct channel of communication.

[hamsec-aumni]

Thanks @tim-finnigan. We have workarounds in place for the time being and look forward to hearing what the Identity Center team says.

[MartinEmrich]

Just also got hit by this with terraform, and at first suspected an issue within terraform: hashicorp/terraform#31943

But indeed, while my PermissionSet was configured for 12 hours lifetime, the CLI wrote an expiresAt of 8 hours into the future. Interestingly, aws CLI continued to work after 8 hours, while the Golang SDK used in terraform, kubectl etc. actually checks the expiresAt field and aborts with a confusing error in that 4-hour-window between expiresAt and the token actually expiring.

[icollar]

Yeah, this is something that also affects us. Since aws sso login isn't idempotent i.e. always attempts a new login despite a session being active, it's a pain to be able to determine the current session state.

[MartinEmrich]

While I closed hashicorp/terraform#31943 now, another participant and I did some more experiments.

Apparently there are two different accessToken formats issued seemingly at random. Either a more "JWT"-like structure, or a shorter binary structure. I could not yet determine a system behind it, it seems random.

And after using SSO more intensively the last few days, sometimes the shorter variant of the token expires even faster than 8 hours, also long before expiresAt.

[Xeroday]

We've also noticed in the past couple of days that the expiresAt is not respected and usually requires re-auth in around an hour.

[tim-finnigan]

We've also noticed in the past couple of days that the expiresAt is not respected and usually requires re-auth in around an hour.

This is likely related to #7340 which has since been resolved.

Regarding the original questions directed to the SSO team, here is the response we received:

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.

@hamsec-aumni please let us know if you had any follow up questions or feedback on this.

[tim-finnigan]

Checking in as we haven't heard back in a few weeks. I'm going to close this since the behavior seems expected and the SSO team confirmed. Please refer to the comment above if you have any additional feedback on this issue.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.

[lorengordon]

I don't think this was related to #7340, as it predated that issue by quite a long while, and has different symptoms. And while this may be "expected behavior" that does not mean it is correct or desirable. It does seem there are improvements that could be made, to align the expiration and behavior across tools and SDKs, to make a better user experience.

[tim-finnigan]

I also don't think the original issue relates to #7340 but some people commented here around the time that issue was created and I think conflated the two. Going forward we can pass along feedback to the SSO team if anyone wants to share any suggestions, or you could consider opening a case through AWS Support for more direct correspondence. We're also tracking cross-SDK feature requests here in a shared repository. But in this case I think the feedback here is for improvements to the functionality or documentation of SSO itself.

[et304383]

I don't understand why the aws sso login command can't just take a session duration parameter like sts assume role does. This is unfortunate and confusing behaviour.

[simon-aira]

To others who might find this ticket – it looks like this works as expected when using the newer [sso-session] configuration style for AWS, i.e. what you get as default when running aws configure sso as per here.

[BwL1289]

This is still impacting me. It was setup manually. Ex:

[profile dev-sso]
sso_session = ex-sso
sso_account_id = <account_id>
sso_role_name = AWSAdministratorAccess
region = <region>
output = json

[sso-session ex-sso]
sso_start_url = <start_url>
sso_region = <region>
sso_registration_scopes = sso:account:access

Session duration is set to more than 1 hour.