16

It appears that when someone authenticates via oAuth, Firebase creates a uid that looks something like google:111413554342829501512, for example.

In Firebase rules, you can do (read and/or write):

".read": "root.child('users').child(auth.uid).child('isAdmin').val() == true"

Is it assumed that I can't read the message by sniffing the network because of the use of HTTPS? Is this how it works - the UID is a shared key used by Firebase rules?

I see that UID in firebase:session::ack in Local Storage in my browser once authenticated.

Rob
  • 14,746
  • 28
  • 47
  • 65
Ronnie Royston
  • 16,778
  • 6
  • 77
  • 91

2 Answers2

36

Knowing someones user id is not a security risk.

For example, I know that your Stack Overflow user id is 4797603. That fact alone allows me to potentially find you on Stack Overflow.

But it does not in any way allow me to pretend that I am Ron Royston. To do the latter I'd need to know the username and password (and any other factor) that you use to sign-in.

The same applies to Firebase. If you know that my uid in some Firebase-backed application is google:105913491982570113897, you cannot suddenly pretend to be me. The Firebase servers verify that the auth.uid value is based on the actual credentials of that user. The only way to do is by signing in as me, which in this case requires you to know my Google credentials.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • https://stackoverflow.com/questions/58788289/firebase-how-to-generate-access-token-from-username-and-password-on-the-server/58792053#58792053 talks about a server-side call `admin.auth().createCustomToken(uid)` , and does this mean if I stole another person's uid, then I could call this function successfully? – Morris Feb 10 '22 at 20:23
  • You need the server-side credentials file for the project in order to be able to use the Admin SDK. – Frank van Puffelen Feb 10 '22 at 21:00
  • But is "4797603" the id that is being used for auth as well, or is it only a public profile id? – Fred Jan 12 '23 at 12:04
  • Background: I assume that Firebase auth is designed to be secure, so the real uid can safely be exposed. But secure by design doesn't necessarily mean, that it's secure in reality. And I assume that exploiting possible security flaws is way easier if an attacker knows the auth.uid. So having this extra layer of not sharing that secret feels more secure to me ... But also more complicated to implement ... – Fred Jan 12 '23 at 12:07
  • 1
    The UID of a user is not part of the credentials used to establish their identity, it merely is part of the result of that process. You can implement other layers on top of it, but I personally trust the team that built this approach over my own feelings and expertise on their topic and acknowledge that I'm more likely to harm security than enhance it. – Frank van Puffelen Jan 12 '23 at 15:09
4

I advise to use custom ID along side with UID. When your app grows, you do not want to share the UID or pass it around. Also when setting firebase-rules, you'll be referring to UID, which should be kept private.

generate a random string for the ID.

And for sensitive user data, set a rule in firestore, to only allow reading of the document if request.auth.uid == user.uid. This will prevent unwanted access. Read up a bit more on firestore rules, might be relevant for your use case.

vancatnow
  • 49
  • 4