AuthUI.getInstance()
.signOut(this)
.addOnCompleteListener(task -> {
if (task.isSuccessful()) {
finish();
} else {
Toast.makeText(this, R.string.sign_out_failed, Toast.LENGTH_LONG).show();
}
});
FirebaseAuth.getInstance().getCurrentUser() which returns the user that I had logged out before reinstallingFirebaseAuth.getInstance().getCurrentUser()NOTE: I'm also allowing backup in my manifest with android:allowBackup="true"
android:allowBackup="false" although I haven't tested this extensively enough to be 100%.Originally reported in a comment in #644
@ahaverty Noooooooooooooo! 😁 Please don't disable auto backup; this "bug" is a feature that's great UX. The idea is that if a user is changing devices or reinstalling your app for one reason or another, they can get right back to whatever they were doing instead of having to go through some long and annoying setup. Hope this swayed your opinion a little! 😁
You're right, it's probably doing more harm disabling backups. My main reason for disabling was to make testing a fresh install easier during development (removing shared preferences & un-authenticating), but really I should keep backups enabled and look into starting fresh for debug builds only. Any suggestions there?
The main reason I'm wondering if this is a security bug:
If I logout of any online service, like a website via chrome on my Mac for example. Once I logout and end my authenticated session, I would expect that if I were to roll back my Mac to a backup from a week ago, that I wouldn't be automatically authenticated to that website again.
If it's the backup that's causing this issue, does that mean the backup is storing some form of my credentials or a "session" that should no longer be authenticated? 🤔
@ahaverty so I can't say I know what Facebook is storing locally on the phone, but I can tell you what Firebase is storing.
Firebase keeps an authentication token in your app's local storage. This identifies the user but does not give them access to actually do anything unless it's refreshed every hour. The Firebase SDKs that use this token (like realtime database) seamlessly handle this refresh for you which is why you don't have to think about it. If you attach an AuthStateListener in your app you'll see that you get a new event every hour as the token changes.
So there's no security risk of restoring this token, since auto backup is linked to the user's google account anyway. This would be different if we were storing, say, a Google Sign In access_token which could be taken out of context and used to impersonate the user.
@ahaverty I hope that's convincing to you, and @SUPERCILEX has provided some good justification as to why we don't tell developers to turn off auto backup. I am going to close this issue as "working as intended" but we can keep discussing if you're curious.
Sounds good, thanks @SUPERCILEX and @samtstern 👍
@samtstern wow, that's really great info about Firebase Auth!!! 😁 Great explanation!
Is this the same issue I am having or should I file a separate bug?
My app has been recovering firebase auth token after page refresh (even close tab and reopen),
however, IT DOES IT EVEN AFTER LOGGING OUT!
I call this.authService.logout() which seems to log it out, but it comes right back after page refresh!
@polyglotinc you should bring this up here:
https://github.com/firebase/firebase-js-sdk
sam its me again, this experience is not that great. if user has logged in with multiple accounts and then logs out and re-installs app it sometimes not using the last login. its using another login. im not sure if its because it needs time to back up but this is a security concern . dont you have a toggle you could make when opening firebase auth so we can decide if we want this feature or not. this is a security concern because user has uninstalled the app and expects all data is gone. i think we should have a setting in to decide if user should have this or not. what do you think ?
Most helpful comment
@ahaverty so I can't say I know what Facebook is storing locally on the phone, but I can tell you what Firebase is storing.
Firebase keeps an authentication token in your app's local storage. This identifies the user but does not give them access to actually do anything unless it's refreshed every hour. The Firebase SDKs that use this token (like realtime database) seamlessly handle this refresh for you which is why you don't have to think about it. If you attach an
AuthStateListenerin your app you'll see that you get a new event every hour as the token changes.So there's no security risk of restoring this token, since auto backup is linked to the user's google account anyway. This would be different if we were storing, say, a Google Sign In access_token which could be taken out of context and used to impersonate the user.