Missing required parameter REFRESH_TOKEN

[eax32]

Describe the bug
For some users we received logs like that while user try to pass authentication with Cognito. In most cases (all?), this happened after token expiration(?) and next uninstalling and reinstalling the application with Google autobackups enabled. Signout or other attempts to clean cache do not lead to success.

Missing required parameter REFRESH_TOKEN (Service: AmazonCognitoIdentityProvider; Status Code: 400; Error Code: InvalidParameterException; Request ID: 6f675297-6d89-11e9-ba25-5fdef691f990);
com.amazonaws.mobileconnectors.cognitoidentityprovider.CognitoUser.getCachedSession(CognitoUser.java:955)
com.amazonaws.mobileconnectors.cognitoidentityprovider.CognitoUser.getSession(CognitoUser.java:743)
com.amazonaws.mobile.client.AWSMobileClient$5.run(AWSMobileClient.java:1107)
com.amazonaws.mobile.client.internal.InternalCallback$1.run(InternalCallback.java:101)
java.lang.Thread.run(Thread.java:764)
;

To Reproduce
Looks like it can be reproduced after expiring some tokens and next user delete the app and reinstall again. (Google auto backup is enabled for app, so may be this is the problem)

Which AWS service(s) are affected?
AWS Cognito Auth

Expected behavior
App should pass authentication.

Environment Information (please complete the following information):

• AWS Android SDK Version: 2.13.0
• Device: Different devices
• Android Version: 7 - 9 (more often on 9)

Additional context
Add any other context about the problem here.

[desokroshan]

@eax32 Thanks for reporting this. Can you please share some relevant code snippet. Does this happen on sign-in or signups after reinstalling?

[eax32]

@desokroshan Thanks for answer. So, we use AWSMobileClient:

private void _signIn(String username, String password, final boolean sendVerificationCode, final AuthProcessHandler authProcessHandler) {
        mobileClient().signIn(username, password, null, new Callback<SignInResult>() {
            @Override
            public void onResult(SignInResult result) {
                processSignInResult(result, sendVerificationCode, authProcessHandler);
            }

            @Override
            public void onError(Exception e) {
                final MPSyncError error = getErrorFromException(e);
                mExecutionContext.onMain(new Runnable() {
                    @Override
                    public void run() {
                        authProcessHandler.onError(error);
                    }
                });

                doFailedAuth();
            }
        });
    }

So, I think (after exploring our app logs) it happend on sign-in after reinstall app.

[eax32]

@desokroshan Also, have a question: in previous versions of our app we use low level api (something like AWSMobileClient uses) - and after app upgrade to AWSMobileClient, mobileClient.initialize allways returns that there is no logined user, so we ask user to relogin, and next all worked well. It's normal behaviour?

[eax32]

@desokroshan @kvasukib Hello, do you have any updates/info for me?

[mutablealligator]

@eax32 Sorry for the delayed response. AWSMobileClient has its own persistent store and does not share the credentials stored by the CognitoIdentityProvider SDK (aws-android-sdk-cognitoidentityprovider). So if you are migrating to AWSMobileClient, the credentials will not be migrated from the underlying SDK to AWSMobileClient.

[eax32]

@kvasukib so, this bug reproduces on android 9.0 with auto backups enabled. User login, next delete the app, and next reinstall again - so, we have "Missing required parameter REFRESH_TOKEN". Also we fix this issue by cleaning shared preferences before signin.
SharedPreferences csiCachedTokens = mContext .getSharedPreferences("CognitoIdentityProviderCache", 0); SharedPreferences.Editor cacheEdit = csiCachedTokens.edit(); cacheEdit.clear(); cacheEdit.apply();

So, you can integrate in to upstream something like this or more elegant.

[alphamu]

@desokroshan I developed this issue recently on my Pixel (original) and found the following:

• Issue came up after an account had been deleted from cognito and recreated several times (with exact same details, first name, last name, email, phone number, email was set as verified).
• On the Android SDK the user could not login and I would get the CognitoInternalErrorException.
• Uninstalling the app, restarting the phone, then reinstalling the app did not help.
• I was successful logging in with an account that was not recreated a bunch of times.
• The offending account would work perfectly fine with the Web SDK. I was able to login, change password, whatever.
• The offending account would work perfectly on an other Android device.

So, for some reason, this account whose deletion and recreation I was working testing on a particular device just doesn't work any more, even if I uninstall the app and restart. This leads me to believe that there is a server side component to this, for some reason, the username + the device seem to be black listed by Cognito, or there is some sort of cache somewhere that suggests that a if a username + device is believe used that it belongs to an AWS account that no longer exists?

I'll try to debug more and report back if I find anything more.

[alphamu]

So @eax32 was spot on, I delete the CognitoIdentityProviderCache and it works!

[mutablealligator]

@alphamu When the user signs out, do you call the appropriate signOut method from the SDK? That should clear the contents of SharedPreferences and wipe the credentials and the associated encryption keys used for encryption of those credentials. You don't have to manually wipe the contents of the SharedPreferences.

[alphamu]

Yes, I do. As far as I can tell, it doesn't clear the shareprefernces, in this or any other AWS shareprefernce file.
I simply call awsMobileClient.signOut() no callback or anything.

[mutablealligator]

@alphamu @eax32 AWSMobileClient.signOut() internally calls CognitoUser.signOut() which clears the tokens cached in the SharedPreferences. It clears the access token, id token and refresh token.

However the lastKnownUser field is not cleared from the CognitoIdentityProviderCache SharedPreferences and.

Also do you use the rememberDevice functionality through our SDK where it remembers the device the end user is using by storing metadata in the CognitoIdentityProviderDeviceCache SharedPreferences`.

Please correct my understanding: When autoBackup is enabled, Android backs up the SharedPreferences files and then restores when the app is reinstalled again. So the current workaround would be to clear the SharedPreferences upon a user signOut besides what the SDK does.

[alphamu]

I wasn't switching devices and I haven't explicit set autoBackup in my manifest. All my phone's were signed in with the same account, yet installing the app and signing into an other phone worked. I am not using remember last known user. Is the SDK configured to remember the last known user by default? This could explain why even though I uninstalled the app, the issue remained after reinstalling the app. Regards

…

On Fri., 7 Jun. 2019, 3:40 am Karthikeyan, ***@***.***> wrote: @alphamu <https://github.com/alphamu> @eax32 <https://github.com/eax32> AWSMobileClient.signOut() internally calls CognitoUser.signOut() which clears the tokens cached in the SharedPreferences. It clears the access token, id token and refresh token. However the lastKnownUser field is not cleared from the CognitoIdentityProviderCache SharedPreferences and. Also do you use the rememberDevice functionality through our SDK where it remembers the device the end user is using by storing metadata in the CognitoIdentityProviderDeviceCache SharedPreferences`. Please correct my understanding: When autoBackup is enabled, Android backs up the SharedPreferences files and then restores when the app is reinstalled again. So the current workaround would be to clear the SharedPreferences upon a user signOut besides what the SDK does. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#940?email_source=notifications&email_token=AAGOJDDMETOZMD7IUQIV24DPZFDW3A5CNFSM4HK6I4V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXDTR2Y#issuecomment-499595499>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGOJDBL4U753QXXBOZCGXDPZFDW3ANCNFSM4HK6I4VQ> .

[alphamu]

Just checked, seems allowBackup is true by default in the Manifest.

…

On Fri., 7 Jun. 2019, 3:40 am Karthikeyan, ***@***.***> wrote: @alphamu <https://github.com/alphamu> @eax32 <https://github.com/eax32> AWSMobileClient.signOut() internally calls CognitoUser.signOut() which clears the tokens cached in the SharedPreferences. It clears the access token, id token and refresh token. However the lastKnownUser field is not cleared from the CognitoIdentityProviderCache SharedPreferences and. Also do you use the rememberDevice functionality through our SDK where it remembers the device the end user is using by storing metadata in the CognitoIdentityProviderDeviceCache SharedPreferences`. Please correct my understanding: When autoBackup is enabled, Android backs up the SharedPreferences files and then restores when the app is reinstalled again. So the current workaround would be to clear the SharedPreferences upon a user signOut besides what the SDK does. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#940?email_source=notifications&email_token=AAGOJDDMETOZMD7IUQIV24DPZFDW3A5CNFSM4HK6I4V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXDTR2Y#issuecomment-499595499>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGOJDBL4U753QXXBOZCGXDPZFDW3ANCNFSM4HK6I4VQ> .

[eax32]

Please correct my understanding: When autoBackup is enabled, Android backs up the SharedPreferences files and then restores when the app is reinstalled again. So the current workaround would be to clear the SharedPreferences upon a user signOut besides what the SDK does.

@kvasukib our workaround is to clear shared prefs before signin.

[mutablealligator]

I am closing this issue and linking to the main issue #937 where we track this bug.