1

So my situation is as follows. I have an external user ID that accesses a third party API. I need a users external ID in order to access that API. Every day I want to check through x amount of users and send them a push notification against certain data that comes from the 3rd party API but I’m sure this would get very expensive as my user base grows if by I have to look up all of these 3rd party IDs in Firestore every day.

What I’m thinking of doing is storing all of the 3rd party ID’s inside of a custom claim and running a firebase function every day to look these users up and process all the info accordingly. However a users 3rd party user ID is kind of sensitive info, so my question is would it be secure to store these IDs inside of a custom claim?

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
Joseph Alvini
  • 25
  • 1
  • 5
  • I didn't fully understand where you want to store them (is it in nodeJS code inside the firebase functions - > hardcoded?) – Berci Oct 18 '21 at 09:59
  • Anyway what I would suggest would be creating a docs just with the external ID's, get them all in a request and just iterate trough each. This way, if your database rules are good, your data is safe and your code is cleaner and the id's are easier to update. – Berci Oct 18 '21 at 10:01
  • No I would be storing these inside of custom claims which are part of firebase auth: https://firebase.google.com/docs/auth/admin/custom-claims – Joseph Alvini Oct 18 '21 at 10:02
  • Yes but that is very expensive at scale. – Joseph Alvini Oct 18 '21 at 10:03
  • I mean a users name and email address is stored in these tokens so I take it that they are somewhat secure – Joseph Alvini Oct 18 '21 at 10:04
  • It should be safe (as long as you don't give a way for a normal user to access `getAuth() .getUser(uid)` or something similar -> like having a function that returns the value of the custom claims that can be called by a normal user). Even their docs suggest that they can be used to `Add an additional identifier on a user. For example, a Firebase user could map to a different UID in another system.` – Berci Oct 18 '21 at 10:12
  • I was thinking that too. It’s all internal so this would not be returned to the user. This function would run like a cron job every day and would not return anything to anyone – Joseph Alvini Oct 18 '21 at 10:17
  • I doubt that it would be the case but just make sure that there isn't in any other place inside the app where the value of the `getAuth().getUser(uid)` is available to the user. You might have something similar used for login (to store the user details in your local state). For this specific case: should the logged in user be able to see their external ID? As long as you don't have anything similar, or if there is no problem if the current user can find the id than again no problem. On short, unless you have a very specific edge case, even their docs seems to approve this option. – Berci Oct 18 '21 at 10:25
  • That does make sense. I should have read into it a bit more but I just wanted to be sure before proceeding. I also said it’s kinda sensitive (as far as the ID) but it’s not even really. A bad actor would still need the private api key to do anything with it anyway. I’m just being overly cautious. – Joseph Alvini Oct 18 '21 at 10:51

1 Answers1

1

The information in an ID token can be decoded by anyone with access to that token. You can try that yourself by pasting the token into a site like jwt.io. So you should not store secret information in the token.

That said, for most systems the user ID is not a secret. For example, for Firebase: Firebase - Is auth.uid a shared secret?

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • But don’t they need access to it in the first place? So no one can just start grabbing user tokens out of no where they would need to first log in. Also yes you are right about the user id’s they are not super secret as that would be terrible, security through obscurity is never a good practice. I’m just being overly cautious – Joseph Alvini Oct 19 '21 at 10:39