firebase-android-sdk: FirebaseAuth.getInstance().getCurrentUser().getUid() returning numbers in place of actual user id

@maclne https://firebase.google.com/docs/reference/android/com/google/firebase/auth/GetTokenResult#public-mapstring,-object-getclaims

Returns the entire payload claims of the ID token including the standard reserved claims as well as the custom claims (set by developer via Admin SDK). Developers should verify the ID token and parse claims from its payload on the backend and never trust this value on the client. Returns an empty map if no claims are present.

Map<String, Object> claims = result.getClaims();
String uid = claims.get("sub"); // or claims.get("user_id")

This is issue has been out now for over 3 years and no explanation or fix whatsoever. We’re facing it again in 2022. Not many users, but again FirebaseAuth.getInstance().getCurrentUser().getUid() returns e-mail adresses instead of an id.

The bad thing is, that because of firebase database moaning to the client if the uid (which is a mail) is used for fetching data, we end up having email adresses now in crashlytics logs. Which is not good.

If this helps: When I lookup the e-mail in firebase authentication, I see that the user does indeed have a uid.

I am also affected by this issue. I can confirm that the numbers are not random. If the user id is invalid (not 28 char alphanumeric), it will be one of the provider UIDs instead. I see a numeric UID when the provider is google, and an email UID when the provider is firebase password. I haven’t been able to reproduce it myself so far.

I see it most frequently after the user brings the app back into focus and the FirebaseAuth.StateChanged event is triggered - the UID will be correct when the app goes out of focus, and FirebaseUser.UserId will be wrong after StateChanged triggers once the app comes back into focus.

Unity Firebase SDK 8.8.0

com.google.firebase.firebase-abt-21.0.1 com.google.firebase.firebase-analytics-20.0.2 com.google.firebase.firebase-analytics-unity-8.8.0 com.google.firebase.firebase-annotations-16.0.0 com.google.firebase.firebase-app-unity-8.8.0 com.google.firebase.firebase-appcheck-interop-16.0.0-beta02 com.google.firebase.firebase-auth-21.0.3 com.google.firebase.firebase-auth-interop-20.0.0 com.google.firebase.firebase-auth-unity-8.8.0 com.google.firebase.firebase-common-20.1.0 com.google.firebase.firebase-components-17.0.0 com.google.firebase.firebase-config-21.0.2 com.google.firebase.firebase-config-unity-8.8.0 com.google.firebase.firebase-crashlytics-18.2.9 com.google.firebase.firebase-crashlytics-ndk-18.2.9 com.google.firebase.firebase-crashlytics-unity-8.8.0 com.google.firebase.firebase-datatrasnport-18.1.1 com.google.firebase.firebase-encoders-17.0.0 com.google.firebase.firebase-encoders-json-18.0.0 com.google.firebase.firebase-encoders-proto-16.0.0 com.google.firebase.firebase-functions-20.0.2 com.google.firebase.firebase-functions-unity-8.8.0 com.google.firebase.firebase-iid-21.1.0 com.google.firebase.firebase-iid-interop-17.1.0 com.google.firebase.firebase-installations-17.0.1 com.google.firebase.firebase-installations-interop-17.0.1 com.google.firebase.firebase-measurement-connector-19.0.0 com.google.firebase.firebase-messaging-23.0.2 com.google.firebase.firebase-messaging-unity-8.8.0

I can confirm that this is still happening on Android firebase-bom:30.0.0. I have one single user where FirebaseAuth.getInstance().getCurrentUser().getUid() is returning their email, causing the app to be unusable.

I reported this issue to Firebase support on Nov 22, 2019. But the issue was not reproducible. We had a lot of discussions.

Here is the case ref:

Case 00023876: Firebase Auth issue [ ref:_00D1Ux0Jq._5001UO6FzC:ref ]

I have added the following workaround on Jul 29, 2020, (I shared the workaround to the Firebase support) to resolve the issue:

So basically, I’m checking if the uid is invalid then just log out the user. Because in my case it is always the email address of the user.

Thanks for the additional info. In case anyone is able to repro this in an emulator or happens to have the contents of adb logcat while they catch this issue happening, can you check if you see this logged: Provider user info list size larger than max size It is possible that some truncation is happening in some rare cases, but it is still not clear how we can end up here. we can try to fix this logic, but it is unclear if it will solve the issue. But the data on the logs will be helpful. Thanks!

Hey @prameshj that might or might no be related to the issue. But since you mentioned if someone is having the log that the provider list size is larger than some max - yes, indeed. That happened. And we are also facing the issue with emails instead of UIDs (I commented way above, too).

So maybe this also relates to this issue: #3885 (comment) where some users had a provider list, containing over 130k(!) items of the same provider. ew.

Thanks for confirming! We are working on a stop-gap solution in this specific scenario. Are you able to repro the multiple firebase provider entries, by any chance? I see you posted a repro in https://github.com/SteveBurkert/firbease-zombie-user-example, but I couldn’t get it to create multiple entries.

This is still an issue in BOM 31.2.2, which is leaking emails into Crashlytics and breaking Realtime Database queries. Any updates on progress here? I have dozens of users with this issue

If this info is useful, I’ve found this has gotten significantly worse when updating Firebase BOM from 29.3.1 to 31.2.0

Thanks for the additional info… We are still working on a repro here and some ideas to recover from this state. Will keep this thread posted. Unfortunately, we are unable to share a concrete timeline, but it is on our radar.

Hi folks, thanks for your patience with this issue! We are still investigating this and might have found a codepath where uid gets populated with ProviderInfo federated Id. It doesn’t appear to be triggered in any valid scenario from what I can tell, but will keep this thread posted.

Can someone confirm if this happens with bom - 31.1.1?

@maclne Yes, same UID (the correct UID, not the wrong one). I’m using Unity with firebase so this is C#, but the steps are:

1. Get user token (TokenAsync)
2. Convert payload section into json
3. Read user_id from json

Here’s a C# snippet with some error handling stripped out:

var pieces = idToken.Split('.'); // header, payload, signature
var payloadBase64 = pieces[1];

switch (payloadBase64.Length % 4)
{
    case 1: payloadBase64 += "==="; break;
    case 2: payloadBase64 += "=="; break;
    case 3: payloadBase64 += "="; break;
}

var payloadSection = Encoding.UTF8.GetString(Convert.FromBase64String(payloadBase64));
var json = SimpleJSON.JSON.Parse(payloadSection);
var payloadUserId = json["user_id"].Value; // always correct UID

@malcolmdeck were you able to get any info on this? I still have users affected by this error. It is very rare, but it does happen occasionally and since I don’t get any errors, just an invalid ID, error handling is super tricky.

1: The current version I use is 20.0.2 and firebase-bom: 26.5.0. I’ll be sure to update it, but I am not using a version that is a year old. 2: Deleting and reinstalling the app is not a great for two reasons. First, the user will loose any data that hasn’t been synced since the error happened. Second, deleting and reinstalling doesn’t solve the issue since it is caused by data persistent in the keychain.

What the user needs to do is to 1: Reach out to support so they can manually send me their data and I can recover it for them 2: Go to the settings app and clear app data. This will remove all content and clear the keychain for the app.

For the user, this is an awful experience. The weird things it that Firebase Auth is not throwing any errors. I would expect the user to be signed out if the keychain has been corrupted, or at least to get an error somewhere. If the user would have been signed out right away, the impact would be minimal as it would be forced to sign in again. Now, they can go for a long time without really noticing that their login doesn’t work, which is awful.

What do you mean by “check what the user looks like on export”?