Cognito tokens lifespan depends on local device time.

[maff91]

Describe the bug

Id and Access tokens expiration time is server absolute time. If client time is manually set to a different time it leads to a problem.

Our tokens lifetime is set to 1h. If device time is manually set to 1h+ forward Cognito considers its tokens already expired immediately after login or token refresh. CognitoUser.getDetails(...) will always throw CognitoNotAuthorizedException.

Apparently, it's not such an edge case. Analytics/Google Play reviews shows that it regularly affects our users.

To Reproduce

1. Go to device settings and manually change time to the future more than now+token lifespan.
2. CognitoUser.getSession(...).
3. AuthenticationHandler.onSuccess(...) is called, though CognitoUserSession.isValid() returns false and CognitoUser.getDetails(...) throws CognitoNotAuthorizedException

Which AWS service(s) are affected?

Cognito.

Expected behaviour

If token's lifespan is expected to be 1h it should valid for 1h since login regardless of device/server time.

Environment(please complete the following information):

• SDK Version: 2.10.1

Device Information (please complete the following information):

• Not device-specific.

[palpatim]

Hi @maff91

Thanks for reporting this issue. I know we do have some handling around clock skew on the iOS side, but we'll need to investigate to see whether we have the same strategies for Android (or indeed if that is the issue here at all).

[minbi]

Hi @maff91 ,

The expiry check is based on the local device time. We can add this as a feature request to use the server time if available. The downside is that the server time is not updated until a request is made. We could make a change that requests server time before a expiry check but would then require a network call and delay the expiry check as well as any calls that are being made.

[minbi]

The clock skew feature that @palpatim mentioned is used to adjust the time for service calls not for local expiry checks which is why this is a feature request.

[maff91]

@minbi I'm familiar with the technique when the token's life time is passed from the server rather than exact expiration date. In this case client can calculate expiration date based on its local time. Anyways, I'm pretty sure it's not something that can be adapted at this stage.

[mregnauld]

I just experienced the same problem with the SDK version 2.14.1. Is there any update?

[gpanshu]

Hello apologies for the delay in responding to this issue. We have now released a V2 version of our Amplify Library for Android completely rewritten in Kotlin. In there we do not check if the expiry time is less than the current time but give that ability to the customer to check by returning the current expiry time of the token. Furthermore the session expiry will be checked on the backend instead of the frontend in V2 hence eliminating the problem all together and returning a session expired from the backend if the session is truly expired. Hope this helps.