Security issues: Persisting user info to localStorage

[amitnovick]

Hi Robin, big fan of your work on React!

I've been trying to tackle the problem you described in React Firebase Auth Persistence with Local Storage: the delay between when the UI loads and when Firebase figures out that the user is signed-in is unpleasant user experience indeed.

In this version of /src/components/Session/withAuthentication.js my issues are twofold:

1. ) A malicious client can set their own localStorage authUser JSON-style string to any other user, and this way access a user's pages and abuse said access to the detriment of the user.
2. The data stored (authUser object) contains personal information about the user contained in that user's Firebase user, including: full name, email address, etc. (depending on the permissions the OAuth app requires). having such information available to any user of that machine, unencrypted, is risky.

Would like to hear your thoughts on these points 🤔
Felix

[rwieruch]

Good points and maybe someone else has a profound opinion on it. I would have to dig deeper into the topic myself on how to secure the data from local storage on this security level.

Do you have any ideas?

[rwieruch]

Opened Issue for it over here the-road-to-react-with-firebase/the-road-to-react-with-firebase#15 regarding 1) Would like to hear your @feelextra thoughts over there as well :)

Not sure how to handle 2) though, because that's the information Firebase exposes anyway, isn't it? Maybe we can discuss it any further here.

[alex067]

I've been scratching my head at this as well, and its getting really annoying because it's holding my production up.

I think a straight forward improvement is to store the id token in local storage, that way no one can manually tamper it (if they tamper with it, it's completely useless). Then, when the user accesses your page again, you can just decrypt the token to store the user data in your global session.

[alex067]

For anyone that is curious, the method I'm going for with my product is to keep the user stored in memory.

It's pretty much the same solution as provided here on this repo, except we don't store the user in local storage. Therefore, when the user logs in, and revists the page, the listener will run and grab the user from firebase.

The only issue with this is that, your initial state, for a split second, will have the user not logged in. To make a better user experience, we went with creating a loading screen that shows for a split second, whenever the user refreshes the page / revisits the page / any event that causes the dom to refresh.

[ohsofoxy273]

Perhaps you could store the token provided by firebase.auth().currentUser.getIdToken() instead of the entire user object.