We are experiencing the exact same issue, with a similar setup, except we store the token in the AsyncStorage using a wrapper like you did. Our users are also getting logged out after some time.
I'm very interested to get more infos on that issue.

Let me know if I can assist with anything to get this progressing.

Sorry you are experiencing issues! Would you be able to provide a larger code snippet or perhaps a basic sample repo that shows this behavior? I'd like to reproduce this, but I haven't seen this behavior before with a React Native app I have configured with federation.

I'm mainly interested in where/how currentSession is used as well as how exactly Amplify is configured.

Also, have you reproduced this behavior without passing in a custom storage solution? Amplify will use AsyncStorage by default, so there isn't a need to pass it in explicitly.

@amhinson Does the following help?

Pretty sure we were able to reproduce it without passing any storage implementation yes, then we did pass one because of the following issue. Seems sessions problems can arise from aws-amplify still using the React Native AsyncStorage implementation while it's now been moved to https://github.com/react-native-async-storage/async-storage.

import Auth from '@aws-amplify/auth';
import Amplify, { Hub, HubCallback } from '@aws-amplify/core';
import React from 'react';
import { Linking } from 'react-native';
import Config from 'react-native-config';
import InAppBrowser from 'react-native-inappbrowser-reborn';

import { navigationRef } from './navigation/helpers';

Amplify.configure({
  aws_project_region: Config.AWS_REGION,
  aws_cognito_region: Config.AWS_REGION,
  aws_user_pools_id: Config.AWS_USER_POOLS_ID,
  aws_user_pools_web_client_id: Config.AWS_USER_POOLS_WEB_CLIENT_ID,
  // storage: SecureStorage,
  oauth: {
    domain: Config.OAUTH_DOMAIN,
    scope: ['email', 'profile', 'openid', 'aws.cognito.signin.user.admin'],
    redirectSignIn: Config.OAUTH_URI_SCHEME,
    redirectSignOut: Config.OAUTH_URI_SCHEME,
    responseType: Config.OAUTH_RESPONSE_TYPE,
    urlOpener: async (url: string, redirectUrl: string) => {
      if (url.includes('logout')) {
        return;
      }

      if (!(await InAppBrowser.isAvailable())) {
        await Linking.openURL(url);

        return;
      }

      const result = await InAppBrowser.openAuth(url, redirectUrl, {
        showTitle: false,
        enableUrlBarHiding: true,
        enableDefaultShare: false,
        ephemeralWebSession: false,
      });

      if (result.type === 'success') {
        await Linking.openURL(result.url);
      }
    },
  },
});

// Used before firing API calls
export const getAuthorizationToken = async (): Promise<string | null> => {
  const session = await Auth.currentSession();

  const token = session?.getIdToken()?.getJwtToken();

  return typeof token === 'string' ? `Bearer ${token}` : null;
};

const useAuthListener = (): void => {
  const handleAuth = React.useCallback<HubCallback>(
    async ({ payload: { event, data } }) => {
      switch (event) {
        case 'signIn':
          {
            const token = data?.signInUserSession?.idToken?.jwtToken;
            const groups =
              data?.signInUserSession?.accessToken?.payload['cognito:groups'];

            if (token && groups) {
              if (groups.includes('USER')) {
                navigationRef.current?.navigate('Home');
              } else if (groups.includes('BETA_CANDIDATE')) {
                navigationRef.current?.navigate('Beta');
              }
            }
          }
          break;
        case 'signOut':
          navigationRef.current?.navigate('Login');

          // Cleanup some internal storages
          break;
        default:
          break;
      }
    },
    []
  );

  React.useEffect(() => {
    Hub.listen('auth', handleAuth);

    return (): void => {
      Hub.remove('auth', handleAuth);
    };
  }, [handleAuth]);
};

const App: React.FC = () => {
  useAuthListener();

  React.useEffect(() => {
    async function redirectUser(): Promise<void> {
      try {
        const session = await Auth.currentSession();

        if (!session?.getIdToken()?.getJwtToken()) {
          throw new Error("Auth.currentSession hasn't returned any session");
        }

        navigationRef.current?.navigate('Home');
      } catch {
        navigationRef.current?.navigate('Login');
      }
    }

    redirectUser();
  }, []);

  // Bunch of screens triggering actions such as:
  // Auth.federatedSignIn, Auth.signIn, Auth.signOut, Auth.signUp, Auth.resendSignUp, Auth.forgotPassword, Auth.confirmSignUp
  return <></>;
};

export default App;

I'm having this same issue. Here's how I reproduce in an emulator:

1. Sign into the app, see my home screen
2. Hit "r" in the terminal to reload the app and I'm booted to the login screen when calling Auth.currentSession() fails

I'm using a custom storage object as described in the Amplify docs. It turns out that the storage object isn't loading all the data it needs from memory before we try to validate the session. So the order of events is:

1. User returns to app.
2. Auth.currentSession() throws an error because there are no current credentials.
3. The sync() method on the storage object completes, so now local memory is populated with remembered credentials.
4. But it's too late! We already redirected to the login screen after step 2 because we thought the user wasn't authenticated.

I'm toying around with different solutions now. The most promising so far is to add a slight delay (100ms) before the first call to Auth.currentSession() to give the sync() method time to complete.

@nerdygirl Thanks for the explanation. Just to make sure we're talking about the same issue:
You mentioned that if you hit "r" in the terminal, you get redirected to login since currentSession() fails. What happens if you refresh again/restart the app after that? In my case, the logout is permanent: the storage has been cleared out and it doesn't matter if I try restarting the app several times, I just won't get logged in.

Yeah, the same thing happens to me in that case.

And although I swear this was working on both Android and iOS previously, it now only appears to work on Android. The difference seems to be that the keys stored in AsyncStorage are now wiped out on iOS, even if I'm just refreshing the app.

Are you noticing any differences between Android and iOS, @samih7?

@nerdygirl Both occurring on iOS and Android for me.

I just got the issue while debugging our app, I logged out the storage content and got the following:
[{"key": "amplify-redirected-from-hosted-ui", "service": "my_service", "value": "true"}, {"key": "amplify-signin-with-hostedUI", "service": "my_service", "value": "true"}]

So it really looks like user-related data has been cleared out from the storage. @amhinson

Edit: once again, Auth.currentSession is failing with 'No current user' error

Same issue. Using own implementation of storage based on SecureStore (expo-secure-store). No issues on Amplify auth v2, started happening on v3.

I have a new theory I'm testing out. Hoping it's helpful to someone (or you can also test and we can share notes).

I followed instructions from AWS Cognito docs to write my custom storage class. Here's the code they provide for setItem() and sync() with a couple of comments from me:

    static setItem(key, value) {
        AsyncStorage.setItem(MYSTORAGE_KEY_PREFIX + key, value);  // I REPLACED ASYNCSTORAGE WITH KEYCHAIN
        dataMemory[key] = value;
        return dataMemory[key];
    }

    static sync() {
        if (!MyStorage.syncPromise) {
            MyStorage.syncPromise =  new Promise((res, rej) => {
                AsyncStorage.getAllKeys((errKeys, keys) => {  // BUT MY KEYS AREN'T IN ASYNC STORAGE
                    if (errKeys) rej(errKeys);
                    const memoryKeys = keys.filter((key) => key.startsWith(MYSTORAGE_KEY_PREFIX));
                    AsyncStorage.multiGet(memoryKeys, (err, stores) => {
                        if (err) rej(err);
                        stores.map((result, index, store) => {
                            const key = store[index][0];
                            const value = store[index][1];
                            const memoryKey = key.replace(MYSTORAGE_KEY_PREFIX, '');
                            dataMemory[memoryKey] = value;
                        });
                        res();
                    });
                });
            });
        }
        return MyStorage.syncPromise;
    }

In my code, I replaced this line:

        AsyncStorage.setItem(MYSTORAGE_KEY_PREFIX + key, value);

with a call to Keychain.setInternetCredentials()

One million tests and console.log statements later, I believe that what happens is this:

1. User logs in
2. Cognito calls setItem() to store 7 key/value pairs
3. User leaves the app
4. User returns to the app
5. Cognito calls sync()
6. sync() looks for keys in AsyncStorage, but they're not there

So to fix, I either need to store the keys—and just the keys, not the values—in AsyncStorage or I need to store them somewhere else and retrieve them in the sync() method.

A quick test with storing them in AsyncStorage works locally, but I haven't tried it on a device yet. I just added this to the top of setItem():

        AsyncStorage.setItem(MYSTORAGE_KEY_PREFIX + key, value); 

Probably not what I'll go with when I ship it, but at least I don't have to log in again every time I refresh the app on my emulator for right now. Tomorrow, I'll figure out a good way to store these keys in Keychain for consistency.

UPDATE: In a major face-palm moment, I figured out why I thought I had it working previously. It's because I tested on my emulator with the default storage. Since that's AsyncStorage, all the keys did get into AsyncStorage. So then when I re-added my custom storage class, it worked! So exciting! Except it was all lies.

The fix I mentioned on April 4 is still needed because of the way I'm querying my own backend service for user data. You can see my confusion on April 8 when it suddenly was only working on one emulator. I now believe that's because I spun up a new iOS emulator so it stopped working there, but kept working on Android.

@nerdygirl @rcCaregiven @Goszu @therealemjy Are you guys also reproducing the issue on v4.x.x?

@samih7 v4 blows up with Expo:

The package at "node_modules/crypto-js/core.js" attempted to import the Node standard library module "crypto". It failed because the native React runtime does not include the Node standard library. Read more at https://docs.expo.io/workflow/using-libraries/#using-third-party-libraries

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Not stale bot, still looking into this. Thank you @Goszu, @samih7, and @nerdygirl for your patience and the details you've provided us thus far. Apologies for the delay.

Thanks everyone for all the details. I am looking into this and I don't seem to be able to reproduce this issue. I tried different auth flows (default and custom) with both default and custom storage solutions and there is no problem with maintaining the current session even after many reloads (or exiting the app and coming back). Auth.currentSession() and Auth.currentAuthenticatedUser() always work as expected.
Does the issue occur consistently after specific actions? if so, can anyone provide a little more details on how exactly is it reproduced?

We did end up resolving this on our end. It had to do with how we were returning promises (or how/when they resolved) after replacing AsyncStorage with react-native-keychain. It has all been refactored since our initial fix, so unfortunately I don't have better details than that.

We see this issue occasionally. It is rare but does happen. I have not been able to pin it down to a particular user action. They open their device and find themselves logged out.

We see this issue occasionally. It is rare but does happen. I have not been able to pin it down to a particular user action. They open their device and find themselves logged out.

Exactly the same than @joebernard for us, except it is not that rare. We also removed the custom auth storage layer we had implemented, so we now use plain AsyncStorage that comes with aws-amplify. But yes, the worst part is that we can't reproduce the issue consistently either.

@Khairo-kh In another context we tried to call currentCredentials from @aws-amplify/auth and we received a No Cognito Identity pool provided for unauthenticated access error. Makes sense since we indeed didn't have an identity pool configured, but could this be related to the logout issue in any way?

@samih7 I think this is an expected response if no identity pool is configured. Identity pools are used more on the authorization side of things. This can be something like authorizing authenticated users to access certain AWS services (S3 storage for example), or allowing unauthenticated access to certain resources.
The issue described here seems to be more about maintaining sessions after authenticating a user (with user pools) so I don't think this is related. Still looking into this, thanks everyone for the feedback.