User automatically proceeds through the Auth0 universal login after app uninstall

[trod-123]

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

If the user logs in via Universal Login, and then decides to uninstall and reinstall the app (without first logging out), and then go through Universal Login again, the user will automatically go through without resubmitting and verifying their credentials.

This bug seems to expose a potential security vulnerability with the Auth0 SDK implementation, and to be honest I am extremely surprised this hasn't been patched.

This is related to this other issue regrading ephemeral session support. I humbly think such support should be default behavior on Auth0. Otherwise we run into super weird behavior cases such as this one.

I've verified this occurs on the Sample, both on 2.11.0 (which our organization is using), and on latest main.

We can try triggering the logout flow every time before starting the login flow, but the UX is not smooth and will make our app look bad.

Please advise any more viable workarounds. If this is not as much a security concern as how I'm making out to be, please provide a message I can share with our organization if they decide to consider this a blocker for us adopting the Auth0 Android SDK. Thank you

Reproduction

1. Sign in via Universal Login
2. Uninstall the app
3. Reinstall the app
4. Go through Universal Login again
5. Notice you aren't asked for your credentials. You automatically get signed in

Additional context

No response

Auth0.Android version

2.11.0

Android version(s)

14

[pmathew92]

Hi @trod-123 , we understand your concern and will plan to add support for ephemeral session in our upcoming releases. Meanwhile could you add the parameter prompt with value login in the WebAuthProvider while making the login call. Adding this will make the SDK try to authenticate the user everytime when making the login call.
Let me know if you have any more queries .

[trod-123]

Hi @pmathew92 , thank you for your response.

Meanwhile could you add the parameter prompt with value login in the WebAuthProvider while making the login call. Adding this will make the SDK try to authenticate the user everytime when making the login call.

I'm verifying this does as you described in both the auth0 sample app and our app. ✅

We gate the user's ability to login if we do not have an access token for that user stored in the device, so under normal circumstances, the scenario where the user tries to log in when they are currently logged in shouldn't pose a problem for us, and in that regard I am now unblocked.

That said, if the user goes through log in again, does this effectively overwrite and invalidate any access tokens that are currently stored as cookies on the user's browser? Just want to understand whether this avoids the potential of security leaks, or if it really is a workaround until proper support is added later.

Thank you!

[pmathew92]

Hi @trod-123 , This flow doesn't invalidate the previous user cookies stored in the browser until the user explicitly logouts. This is a limitation with custom chrome tabs for the time being . The prompt = login is more of a workaround till we add proper support

[igormsiqueira]

Hi @pmathew92 I'm currently facing the same issue @trod-123 mentioned but for our organization we had to omit the prompt=login if we pass that Home Realm Discovery is skipped and we need that for accounts using Okta & EntraID, apart from the prompt=login is there any other workaround to that behaviour? - Thank you

[pmathew92]

Hi @igormsiqueira , currently passing prompt = login is the only workaround for the above scenario till we add support for ephemereal session

[igormsiqueira]

Hi @pmathew92 thanks for your answer! Above you mentioned that the cookies are only invalidated when the user logs-out, is there any way for upon a fresh install detect that there's an active session in the browser? - I have attempted using the credentials manager but it always returns false for hasValidCredentials even if there's an active session in chrome, this creates a problem in our flow because the user could have started authenticating locally, provided our own ui with its user name, which we save, and when that triggers the WebAuth flow this user would receive a token for the valid session in the browser instead of being asked for his credentials, so even passing a hint=newUser the browser still returns a valid callback and this creates a situation where I might need to add additional checks such as:

fun onAuth0LoginSuccess(credentials: Credentials) { if (credentials.user.email != sessionPreferences.username) { // logout() }

is there a way to detect that there's an active session in the browser? - Thanks for your time!

[pmathew92]

Hi @igormsiqueira , Credential manager stores the session data using shared preferences after a successful login. So a fresh install of your app will always return false for hasValidCredentials since you haven't successfully authenticated the user.
Regarding your query of checking if there's an active session, I believe its not possible. custom chrome tabs share the same cookie jar as the chrome browser on your device. We directly don't have any apis through which we can check these AFAIK.
As of now , you would have to handle this on your end via your checks. Please be patient till we add support for ephemereal session . Thank you for your understanding

[trod-123]

Hi @pmathew92 , I'm curious why the browser needs to store the auth cookie in the first place. I think it should be the role of the client itself (i.e. the Android app) to manage credentials in the first place, and the browser should not really care.

If we keep the credentials solely managed by the client (browser just acts as a credential generator and passes it to the client without persisting it), it would also remove the need for the app to awkwardly launch the browser when the user signs out.