getCredentials fails on an unrecognized fingerprint while the biometric prompt is still open
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Domain
- authentication, mobile
Research direction
Start in auth0/src/main/java/com/auth0/android/authentication/storage/LocalAuthenticationManager.kt at onAuthenticationFailed(), which currently calls resultCallback.onFailure(BIOMETRICS_INVALID_USER). Compare it with onAuthenticationSucceeded() and onAuthenticationError(), which deliver the final result. Look for existing unit tests for this manager and run them. Done means a non-final failure reports nothing, and the callback receives exactly one result when the prompt closes.
Written by the indexing model from the issue text.
Description
Checklist
- The issue can be reproduced in the Auth0.Android 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
SecureCredentialsManager.getCredentials() with local authentication fails as soon as one fingerprint is not recognized, while the biometric prompt is still open.
LocalAuthenticationManager.onAuthenticationFailed() calls resultCallback.onFailure(CredentialsManagerException.BIOMETRICS_INVALID_USER):
BiometricPrompt calls onAuthenticationFailed() when a biometric is read but not recognized. It is not a final result. The prompt stays open, so the user can try again or use the device credential fallback. The final result always comes later through onAuthenticationSucceeded() or onAuthenticationError().
Because of this the callback gets onFailure(BIOMETRICS_INVALID_USER) first and then, when the user does unlock, onSuccess. SecureCredentialsManager also calls updateBiometricSession() on that later success. So the session starts, but a caller that settles on the first result never sees it. That is what happens in react-native-auth0, where the first result rejects the JS promise and the later success is dropped.
Expected: onAuthenticationFailed() does not report anything, and the callback gets one result once the prompt closes.
The same applies to getApiCredentials(), which uses the same LocalAuthenticationManager.
Reproduction
- Configure
SecureCredentialsManagerwithLocalAuthenticationOptions,deviceCredentialFallback = trueandBiometricPolicy.Session. - Call
getCredentials(). - In the prompt, use a fingerprint that is not enrolled. With the emulator, touch the sensor with a finger that was not registered.
- The callback gets
onFailure(BIOMETRICS_INVALID_USER)right away, while the prompt shows "Not recognized" and stays open. - Tap "Use PIN" and enter the correct PIN.
- The callback now also gets
onSuccess, and the biometric session is valid. The nextgetCredentials()call returns credentials without a prompt.
This happens every time on a Pixel emulator.
Additional context
Found through react-native-auth0 5.11.0, which uses Auth0.Android 3.21.0. The app shows its locked state behind the prompt that is still open, ignores the PIN the user enters, and then unlocks without a prompt on the next attempt.
The same code is in 3.21.1, 4.1.0 and 5.0.0-beta.0.
A possible fix is to remove the resultCallback.onFailure call from onAuthenticationFailed(), or to only call super.
Auth0.Android version
3.21.0 (also present in 3.21.1, 4.1.0 and 5.0.0-beta.0)
Android version(s)
Pixel emulator. The behavior follows from how BiometricPrompt reports results, so it is not specific to one Android version.
- Dominant language
- Kotlin
- Stars
- 301
- Forks
- 183
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 14
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from auth0/Auth0.Android
-
Difficulty 4/5 3-5 days Newbie friendliness 28/100
auth0/Auth0.Android#1093 · 5 comments ·
Maintainers usually reply within 1 day
All issues in auth0/Auth0.Android
Similar issues
-
enhancement triaged
Difficulty 1/5 Under an hour Newbie friendliness 63/100
Maintainers usually reply within 1 day
-
bug follow-up
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
bug 🐞 CI/CD ⚒️
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
valkey-io/valkey-glide#7370 ·
Maintainers usually reply within 1 day
-
binding:web core docs p3
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
RunanywhereAI/runanywhere-sdks#1123 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
openai/openai-java#1202 ·
Maintainers usually reply within 1 day