aws-sso-util login fails with Login failed: 'expiresAt'

[kbakk]

When trying to log in, after having been logged in before, I'm getting an error:

$ aws-sso-util login
Logging in https://<our_subdomain>.awsapps.com/start
Login failed: 'expiresAt'

$ aws-sso-util check
aws-sso-util: v4.31.0; aws-sso-lib: v1.14.0; time: 2023-01-27T08:57:49Z
Identity Center instance start URL https://<our_subdomain>.awsapps.com/start from profile and region eu-west-1 from profile
Exception in loading token: 'expiresAt'

It works after running aws-sso-util logout, then aws-sso-util login again.

For reference, I'm running it on Python 3.10 on MacOS 13.1.

[benkehoe]

Well that is weird. Is it something that you can reproduce? It appears that your token didn't have an expiresAt field in it, which should always be present (so there's no check for it). I'll add that to aws-sso-util check and the token validity logic, but I have no idea why your token would end up that way. If you see it again, take a look at the token and validate that it isn't there.

[kbakk]

It's something that happens very rarely. Not sure what is causing it, haven't happened since I reported the issue (before then it seemed to happen more frequently). But now it happened again:

$ aws-sso-util check -v
INFO:aws_sso_util.check:aws-sso-util: v4.31.0; aws-sso-lib: v1.14.0; time: 2023-03-15T13:37:08Z
INFO:aws_sso_util.check:Identity Center instance start URL https://nep-cloud.awsapps.com/start from profile and region eu-west-1 from profile
DEBUG:aws_sso_util.check:Traceback (most recent call last):
  File "/Users/krisb/.local/pipx/venvs/aws-sso-util/lib/python3.10/site-packages/aws_sso_util/check.py", line 258, in check
    elif token_fetcher.is_token_expired(token):
  File "/Users/krisb/.local/pipx/venvs/aws-sso-util/lib/python3.10/site-packages/aws_sso_lib/vendored_botocore/utils.py", line 238, in is_token_expired
    return self._is_expired(token)
  File "/Users/krisb/.local/pipx/venvs/aws-sso-util/lib/python3.10/site-packages/aws_sso_lib/vendored_botocore/utils.py", line 99, in _is_expired
    end_time = self._parse_if_needed(response['expiresAt'])
KeyError: 'expiresAt'

ERROR:aws_sso_util.check:Exception in loading token: 'expiresAt'

It happens consistently now – but will have to make it work now (logout and login). Anything I should try to do next time - insert any print statements or similar? I suppose the details are cached on disk *somewhere*. 🤔

[benkehoe]

Use -vvv which will turn on all debug logging.

When it's working correctly, check the files in ~/.aws/sso/cache, one of them should have your token in it (along with an expiresAt field). That filename remains consistent, so check it again when it breaks, and see if you can tell the difference in the contents.

[kbakk]

Found out. I'm using Lola (https://www.lola.dev/) and SSO login. There's a conflict where the file created by Lola is attempted used.

So steps to reproduce:

1. Reset the SSO cache - rm .aws/sso/cache/*.json
2. Open Lola and log in using SSO
3. Observe a new JSON file:

   ls .aws/sso/cache/* | xargs -I {} sh -c 'echo {} && jq . {}'
   .aws/sso/cache/1922f82411c7994cb3be69e98d450e7600d56dd3.json
   {
     "accessToken": "<redacted>",
     "startUrl": "https://<redacted>/start"
   }
   

4. Attempt aws-sso-util login, see error:

   Logging in https://<redacted>/start
   Login failed: 'expiresAt'
   

[benkehoe]

Huh. Does that cache entry work with the AWS CLI, e.g. aws sts get-caller-identity? It does seem like it should (code link)

[kbakk]

No, it doesn't seem to like that - after logging in with Lola:

$ aws --profile work-sso sts get-caller-identity

Error loading SSO Token: Token for https://<redacted>/start is invalid

If I do rm ~/.aws/sso/cache/*.json and aws sso login --profile nep-sso it will work:

$ aws --profile nep-sso sts get-caller-identity
{
    "UserId": "<redacted>",
    "Account": "<redacted>",
    "Arn": "arn:aws:sts::<redacted>:assumed-role/<redacted>"
}

For reference, get-caller-identify works when using aws-sso-util as well.

[kbakk]

I will report this to the Lola developers.

I would suggest that aws-sso-util produces the same error as botocore (or even a more helpful one, with suggested workaround (logout) and pointing to the invalid file). If you don't feel like that's the right course let me know and we can close this.

Thanks for helping troubleshooting! 🙌

[benkehoe]

I think aws-sso-util login should just treat the token the same as a missing or expired token, don't you think? With a debug error message, and aws-sso-util check identifying the problem

[kbakk]

That should work as well. It sounds more helpful, which I suppose is the goal of aws-sso-util 😉