No cached session while getting access token on version 2.69.0

[m-zagorski]

Describe the bug
We are using aws-android-sdk-mobile-client version 2.69.0 and are seeing a lot of No cached session - almost 1k per day.
So what is happening is that when we get Unauthorized we are calling AWSMobileClient.getTokens with a callback - all calls to this method are synchronized and we're waiting for the AWSMobileClient to be fully initialized (we think its initialized when awsMobileClient.configuration is not null).
In return we're getting No cached session exception thrown from within signalTokensNotAvailable method inside the client.
Currently we are unable to update the library to amplify due to the changes that would be required on the backend side. however from analytics we can see that this issue is not only related to the current version - we're seeing it for quite few months.
Also important thing is that we have the device tracking turned off.

To Reproduce
We were unable to reproduce it locally. What we see from logs, most cases are for the users that were not using the application for quite some time, so that the access token is expired, then when trying to refresh the tokens we get the No cached session. We have checked that AWS Client is initialized, also we have user data in the app - its only that getTokens that makes the session invalid.

Which AWS service(s) are affected?
Only android - aws-android-sdk-mobile-client

Expected behavior
getTokens return correct access tokens or more meaningful exception so we can act on our end

Screenshots
N/a

Environment Information (please complete the following information):

• AWS Android SDK Version: 2.69.0
• Device: Affects all devices
• Android Version: Affects all versions
• Specific to simulators: No

Additional context
N/a

[tylerjroach]

What we see from logs, most cases are for the users that were not using the application for quite some time, so that the access token is expired, then when trying to refresh the tokens we get the No cached session.

Refresh tokens also have an expiration configured. What is the refresh token expiration set to in Cognito? Once a refresh token has expired, the user will need to sign in again.

[m-zagorski]

What we see from logs, most cases are for the users that were not using the application for quite some time, so that the access token is expired, then when trying to refresh the tokens we get the No cached session.

Refresh tokens also have an expiration configured. What is the refresh token expiration set to in Cognito? Once a refresh token has expired, the user will need to sign in again.

We have 730 days of expiration set for the project. So thats not the case. Also we're not experiencing similar issues on iOS where we have even more users.

[tylerjroach]

Can you provide your awsconfiguration file with sensitive information obfuscated? Additionally, what sign in type are you using?

[m-zagorski]

Do you mean this one?

As for the sign in type - I'm not sure which one is the most affected, but we're having password, facebook and google - we dont know which method was used when we get No cached session

[tylerjroach]

Hi @m-zagorski, that is helpful but looking for the awsconfiguration.json file in your app/src/res/raw folder.

I was trying to also figure out what sign in method you were using. It sounds like if you are using password, facebook, and google, you are using the hosted (web) ui sign in flow and not SRP.

If this is the case, please check the awsconfiguration.json file and see if openid is listed under the Scopes. If this is missing, the refresh token will not work.

[m-zagorski]

Hey, we have openid set in scopes: "Scopes": ["openid", "email", "profile"] - and for the sign in method - we're using mostly the hosted (web) ui sign in flow (we have changed google recently but this did not affect the case of No cached session

[tylerjroach]

@m-zagorski I've got a few questions to continue asking.

• Do you also have non-hosted (SRP sign in) capabilities in the app as well?
• Do you have any data that would indicate that this issue may be coming from a specific sign in flow type?
• If you are seeing almost 1k/day, would you happen to know if this is 1k users? Or could this be a small number of users that continue to attempt to make many network calls.
• If you have an identical dev environment set up, have you attempted to lower id token and refresh expirations to see if you can replicate the message seen?
• How long has your app been released? Is it possible some users are starting to hit 730 days?
• Have their been changes to refresh token expiration times (ex: older sign ins would have the older value, not 730)

Please try and provide the awsconfiguration.json file so that we can take a further look and make sure nothing looks misconfigured on that file.

[m-zagorski]

Hello, so:

• We do not have any sign-in capabilities that bypass the cognito flow - even if we are not using web hosted ui, we're relying on cognito methods to sign in users
• Looking at the analytics, most common use case is when users get a notification and this triggers app request which fails - we've checked and the AWS client is initialized, also we have user session details inside the application
• There are indeed users that get this more than once, so that 1k is not a unique number
• We have lowered the id token expiration to 5mins and unfortunately we couldnt reproduce it - we managed to get that once for an account that was unused for few days, but that gave us nothing interesting
• It might exceed 730 days, however looking at ios where we have a lot more users and no such issues I dont think thats the case - especially that some of the users are getting the error few times
• I will try to get that info but it might be hard to get (Im not sure if there is a changelog in there)

As for the awsconfiguration.json file here it comes: (staging one has exactly the same structure):

{
  "IdentityManager": {
    "Default": {},
    "Custom": {}
  },
  "CognitoUserPool": {
    "Default": {
      "PoolId": "eu-west-1_****",
      "AppClientId": "****",
      "Region": "eu-west-1"
    },
    "Custom": {
      "PoolId": "eu-west-1_****",
      "AppClientId": "****",
      "Region": "eu-west-1"
    }
  },
  "Auth": {
    "Default": {
      "OAuth": {
        "WebDomain": "accounts.hidden.com",
        "AppClientId": "****",
        "SignInRedirectURI": "hidden://sign-in",
        "SignOutRedirectURI": "hidden://",
        "Scopes": ["openid", "email", "profile"]
      }
    },
    "Custom": {
      "OAuth": {
        "WebDomain": "accounts.hidden.com",
        "AppClientId": "****",
        "SignInRedirectURI": "hidden://sign-in",
        "SignOutRedirectURI": "hidden://",
        "Scopes": ["openid", "email", "profile"]
      },
      "authenticationFlowType": "CUSTOM_AUTH"
    }
  }
}

[ankpshah]

@m-zagorski is it possible for you to provide detailed logs/stacktrace with sensitive information obfuscated? It would be helpful to understand under what condition no cached session messages are being logged to further identify root cause.

[m-zagorski]

@ankpshah Unfortunately we dont have full stacktrace - only the message from exception coming from cognito, I will check if we can change the logs so that we have full stacktrace

[m-zagorski]

@ankpshah Here is the stacktrace we're getting:

Non-fatal Exception: java.lang.Exception: No cached session.
       at com.amazonaws.mobile.client.AWSMobileClient$11$1.signalTokensNotAvailable(AWSMobileClient.java:1968)
       at com.amazonaws.mobile.client.AWSMobileClient$11$1.getAuthenticationDetails(AWSMobileClient.java:1948)
       at com.amazonaws.mobileconnectors.cognitoidentityprovider.CognitoUser.getSession(CognitoUser.java:1032)
       at com.amazonaws.mobile.client.AWSMobileClient$11.run(AWSMobileClient.java:1929)
       at com.amazonaws.mobile.client.internal.InternalCallback$1.run(InternalCallback.java:101)
       at java.lang.Thread.run(Thread.java:923)

[ankpshah]

Hello @m-zagorski,
Could you upgrade to AWS Android SDK v2.75.0 which provides a clear message during getTokens when there are no valid tokens on device. When doing so, please make sure that you update your implementation for the logic to check for failures.

The changes can be found here: 46fb3c3

Here is a quick summary:

If the token fails to refresh, the caller will receive an exception with "No cached session". The caller is already aware of this.
callback.onError(new Exception("No cached session.", exception));

However, sometimes provided inner exception was null. This is no longer the case, you will receive additional details about exception.

If you receive CognitoNotAuthorizedException, this means that the tokens are no longer valid. The user can be signed out.
callback.onError(new Exception("No cached session.", new CognitoNotAuthorizedException("No valid tokens on device.")));

In any other exception case, the issue is likely to be transient. You may want to log this exception so you can report if you are seeing an abnormal amount of any other exception types.