5.0.0-beta.4 – Frequent CRYPTO_EXCEPTION Errors on Android

[helmoski]

Checklist

• The issue can be reproduced in the react-native-auth0 sample app (or N/A).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

We are seeing a large number CRYPTO_EXCEPTION errors specifically on Android devices after upgrading from 5.0.0-beta.3 to 5.0.0-beta.4:

CRYPTO_EXCEPTION: A change on the Lock Screen security settings have deemed the encryption keys invalid and have been recreated. Any previously stored content is now lost. Please try saving the credentials again.
  at construct(native)
  at <global>(/node_modules/react-native-auth0/src/core/models/CredentialsManagerError.ts:1:41)
  at constructor(/node_modules/react-native-auth0/src/core/models/CredentialsManagerError.ts:47:5)
  at handleError(/node_modules/react-native-auth0/src/platforms/native/adapters/NativeCredentialsManager.ts:20:40)
  at throw(native)
  at asyncGeneratorStep(/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:17)
  at _throw(/node_modules/@babel/runtime/helpers/asyncToGenerator.js:20:27)
  at tryCallOne(/node_modules/promise/setimmediate/core.js:37:14)
  at setImmediate$argument_0(/node_modules/promise/setimmediate/core.js:123:25)
  at apply(native)
  at global.queueMicrotask$argument_0(/node_modules/react-native/Libraries/Core/Timers/immediateShim.js:46:21)

This error is occurring without any changes to the lock screen security settings and even on a new device with a fresh install that has never had our app on it before.

Interestingly, we are still able to retrieve and use credentials via getCredentials even after this error occurs, so we started just filtering out that error for now.

Reproduction

We haven't been able to determine a way to reproduce it consistently, but it is happening frequently. I was hesitant to open this issue, but I thought it would be better to report it than to remain silent.

Additional context

No response

react-native-auth0 version

5.0.0-beta.4

React Native version

0.79.5

Expo version

53.0.19

Platform

Android

Platform version(s)

n/a

[subhankarmaiti]

Hi @helmoski,
Thank you for trying out the latest version and reporting this issue.
We’ll need more information or the exact steps to reproduce the issue so that we can properly debug it.
Could you please confirm if your app is directly using Android SharedPreferences to store any values with the following keys?

• com.auth0.credentials
• com.auth0.credentials_expires_at
• com.auth0.credentials_access_token_expires_at
• com.auth0.credentials_can_refresh

[helmoski]

Thank you for your help @subhankarmaiti. We are not using SharedPreferences directly, and we don't store any values with those keys. We just rely on the standard react-native-auth0 credential management APIs.

We do use React Native's AsyncStorage to store some other values such as user preferences, but not any auth credentials nor any values with those keys.

[subhankarmaiti]

Hi @helmoski ,

Interestingly, we are still able to retrieve and use credentials via getCredentials even after this error occurs, so we started just filtering out that error for now.

How are you obtaining the credentials if this is throwing an error? It should either return a success or raise an error.

[helmoski]

That's a great question. I should have clarified that the error is being surfaced from useAuth0 and not the call to getCredentials.

import { useAuth0 } from 'react-native-auth0';
const { error } = useAuth0();

Even if that error variable changes to the crypto exception, we're still able to call getCredentials successfully.

[subhankarmaiti]

Interesting, however, in the current implementation, any error that occurs is always thrown, so it should surface at the point where it’s called. Could you share a sample code snippet showing which methods you’re using from React Native Auth0, before calling the getCredentials?

[helmoski]

import Constants from 'expo-constants';
import { useCallback, useEffect, useState } from 'react';
import { Button, Text, View } from 'react-native';
import { Auth0Provider, useAuth0 } from 'react-native-auth0';

const rawScheme = Constants.expoConfig?.scheme;
export const scheme = rawScheme ? (Array.isArray(rawScheme) ? rawScheme[0] : rawScheme) : undefined;

export const AppWrapper = () => {
    return (
        <Auth0Provider domain="<DOMAIN>" clientId="<CLIENT_ID>">
            <App />
        </Auth0Provider>
    );
};

const App = () => {
    const {
      error,
      user,
      authorize,
      clearSession,
      getCredentials,
      hasValidCredentials,
      isLoading
    } = useAuth0();

    const [isReady, setIsReady] = useState(false);
    const [isAuthorized, setIsAuthorized] = useState(false);

    const login = useCallback(async () => {
        await authorize(
            {
                audience: '<AUDIENCE>',
                scope: '<SCOPES>',
                additionalParameters: {
                    prompt: 'login',
                },
                connection: 'Username-Password-Authentication',
            },
            {
                customScheme: scheme ? scheme + '.auth0' : undefined,
                ephemeralSession: true,
            },
        );
        setIsAuthorized(true);
    }, [authorize]);

    const logout = useCallback(async () => {
        await clearSession();
        setIsAuthorized(false);
    }, [clearSession]);

    // getToken is called by our Axios instance every time it makes a request
    // to our API from within the "Authenticated Experience".
    const getToken = useCallback(async () => {
        if (!(await hasValidCredentials(60))) {
            await logout();
            return null;
        }
        const credentials = await getCredentials(undefined, 60);
        if (!credentials) {
            await logout();
            return null;
        }
        return credentials.accessToken;
    }, [getCredentials, hasValidCredentials, logout]);

    // Ensure user credentials are still valid
    useEffect(() => {
        if (isLoading) return;
        if (!user?.sub) {
            setIsReady(true);
            return;
        }

        // Call `getToken` to validate the token is still valid
        getToken()
            .then((token) => {
                if (token) {
                    setIsAuthorized(true);
                } else {
                    setIsAuthorized(false);
                }
            })
            .catch(() => {
                setIsAuthorized(false);
            })
            .finally(() => {
                setIsReady(true);
            });
    }, [getToken, isLoading, user?.sub]);

    if (error) {
        return (
            <View>
                <Text>Error: {error.message}</Text>
            </View>
        );
    }

    if (isLoading || !isReady) {
        return (
            <View>
                <Text>Loading...</Text>
            </View>
        );
    }

    return isAuthorized ? (
        <View>{/* Authenticated Experience */}</View>
    ) : (
        <View>
            <Button onPress={login} title="Login" />
        </View>
    );
};

[subhankarmaiti]

Looking at the code, I can see an issue. As per the migration guide, errors should now be handled for all hook methods. Please wrap these methods in a try...catch block—this will help identify which method is throwing the error.

[helmoski]

We actually do have them in try/catch blocks, but I stripped them out for the sample code 😅

I was wrong; we have the authorize call wrapped, but not the getCredentials call. I'll add that

[helmoski]

After adding in the try/catch's, I can confirm that the CRYPTO_EXCEPTION is being thrown by getCredentials.

[subhankarmaiti]

Could you confirm whether this happens every time, or only in certain cases where you’re able to reproduce the error? Also, since you mentioned the exception occurs in getCredentials, how were you able to obtain the credentials—was it through the authorize call?

[helmoski]

Could you confirm whether this happens every time, or only in certain cases where you’re able to reproduce the error?

We have been able to reproduce in that it occurs when we're testing, but it's sporadic, so there isn't a specific sequence of steps to reproduce it that we have been able to determine. It doesn't happen every time.

Also, since you mentioned the exception occurs in getCredentials, how were you able to obtain the credentials—was it through the authorize call?

We would call getCredentials again after the error occurs and it would succeed. This was before we added in the automatic logout on error.