From c675c6bbb8f73a24ec391b1e53fa476dabc2112d Mon Sep 17 00:00:00 2001 From: Thomas Sibley Date: Tue, 9 Jan 2024 09:53:19 -0800 Subject: [PATCH] =?UTF-8?q?aws/cognito:=20Extend=20validity=20of=20the=20C?= =?UTF-8?q?LI's=20refresh=20tokens=20from=2030=20=E2=86=92=2090=20days?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In practice, 30 days seems too short. I've observed users who get the CLI installed and logged in but then don't get to uploading their datasets until more than 30 days later (i.e. they spend time producing the datasets or on other work) and so then have to log in again when it's time to upload. This has been a minor frustration and stumbling block for them. In a different use case, @corneliusroemer has also found 30 days to be too short in automation contexts. Although I'd suggest a different approach for automation¹, I suspect his approach will not be an uncommon one for users to take so we should ensure it's not too onerous when they do. Resolves . ¹ --- aws/cognito/clients.tf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aws/cognito/clients.tf b/aws/cognito/clients.tf index 2a5324433..b62d50f33 100644 --- a/aws/cognito/clients.tf +++ b/aws/cognito/clients.tf @@ -97,7 +97,7 @@ resource "aws_cognito_user_pool_client" "nextstrain-cli" { # Token lifetimes dictate background refresh (and re-login) rates for the CLI. id_token_validity = 60 access_token_validity = 60 - refresh_token_validity = 30 + refresh_token_validity = 90 token_validity_units { access_token = "minutes" id_token = "minutes"