Managing Firebase Cloud Messaging Tokens with Multiple Users

Question

Looking at the Firebase docs, it suggests that a FCM token is generated for each client instance - which must then be stored manually. If I'm linking each token to a user document in a Firestore database, will I need to manually remove the device-specific token if the user logs out?

For example, user A launches the app and their FCM token (e.g. "ABC") is stored to their user document. Then, user A logs out and B logs in. The FCM token would not refresh**, and therefore I'd need to remove that token from A's user document and move it to B's. Otherwise, any notifications destined for A would be sent to B (all on the same device).

Is this thinking correct? It seems like a tricky way to manage the tokens but as far as I can tell is necessary?

** As per Firebase docs, the token is only refreshed when:

1. The app is restored on a new device
2. The user uninstalls/reinstall the app
3. The user clears app data.

Reading more of the docs, would it be a better solution to locally process the notification first - decide whether it was destined for the logged in account, then present it? I.e. not add any low-level sensitive data (e.g. chat message) to the notification and simply provide an 'notification to fetch a new message'?

Comet

Answer 1

Yes, that is correct. An FCM token identifies an installation of a specific app on a specific device, nothing more and nothin less. It has no inherent relation to a user, so if you need such a relation, you will have to link them together yourself.

Keep in mind that just like multiple users can use a single device, a single user can also use multiple devices. In my experience that is in fact the more common scenario of the two.

---

Locally checking the target user of the notification against the actual current user is an interesting concept that could definitely help prevent showing the data to the wrong user.

In general though, you can also clear the token when the user signs out of your app (or a new user signs in). This is (as far as I can tell) the most common way of dealing with this scenario (see 1, 2, and more from this).

Repertory