I am trying out Firebase / Firestore. When I run the command-line firebase login in a Linux terminal, I am redirected to the typical Google login web-site but with an additional Firebase-logo. After login on that web-site, I have to enable various features and permissions for Firebase to access my Google account.
Then the firebase program on my local Linux PC knows that I have logged in to my Google account. Even after I restart the computer, the firebase program is apparently still logged in to my Google account.
How does this work behind the scenes? Is my Google account password stored on my local PC somewhere, since firebase remains logged in to the account? Doesn't that cause a security risk?
Thanks!
No, passwords are never stored like that. That would be incredibly unsafe. The CLI is storing a special token that gives access to parts of the account that you authorized in the web browser. That token is valid until something invalidates it, or you sign out by running firebase logout. It's similar to the way most auth systems work that allow an individual to stay signed in for long periods of time without reauthenticating.
If you want to see exactly what the CLI is doing, it's all open source.
Related
I have the following mobile app scenario based on a Firebase backend:
Two or more mobile app instances communicate with each other through a central service (trusted). The apps are paired by exchanging a shared secret, e.g. through scanning a QR code or entering a pairing code.
Users are anonymous, ie no signup required (or possible). Essentially, it is the specific app on a specific device that is paired with a ditto counterpart (vs user-to-user).
Information exchanged is sensitive but has no intrinsic value: It must be possible to trust that information comes from a given device and it must be possible to trust that the information has reached the intended device and not an impersonating device. But it is not a critical problem that an app instance's information is lost, e.g. if the app is removed or the device is destroyed (an annoyance that requires re-pairing, but not a critical issue).
It seems Firebase Anonymous Auth is a perfect match for this scenario - but the documentation hints that it should only be used as a temporary solution until users create an actual account. Are there any drawbacks to using anonymous auth as the sole authentication method for the solution? The alternatives I see are some kind of hack using a custom token-based login or perhaps email/password auth.
Are there any drawbacks to using anonymous auth as the sole authentication method for the solution?
There isn't unless the user uninstalls the app.
The documentation hints that it should only be used as a temporary solution until users create an actual account.
Why a temporary solution? It's because anonymous accounts do not persist across application uninstalls. If a user uninstalls the app, everything that was saved locally will be deleted, including the anonymous auth token that identifies that account. Unfortunately, there is no way to reclaim that token for the user.
The alternatives I see are some kind of hack using a custom token-based login or perhaps email/password auth.
IMHO, the best approach would be to use anonymous authentication but to also let the user the possibility to link their account with email and password or any other providers, like Google, Facebook, Instagram, and so on.
I want to develop a Web App which runs on Firebase where I log in (once) using the providing google sign in.
The App should use the google APIs to display a variety of informations (email, some special calendars etc).
The idea is to have this Web App run on my tablet 24/7 and never touch it but according to this the authentication token will expire after 24 hours which means I need to login every 24 hours.
What is the best way to have a "persistent" login which only expires when the device (or browser) is shut down?
You're looking at documentation for IoT core. Unless you're using IoT core, that documentation won't apply to you
In regular web apps that use the Firebase JavaScript/Web SDK, the ID tokens is automatically refreshed every hour, and credentials are persisted by the SDK and restored when the app restarts.
In practice this means that the user can sign in once, and stay signed in until you either sign them out explicitly, or until a compelling event forces them to reauthenticate (something like their password being changed, or you disabling their account). Unless something like that happens, you can always get the currently signed in user by using an auth state listener.
I am building a Flutter app with Firebase Authentication. I am trying to find a way to ensure that the communication going to my backend is actually from the app I wrote and uploaded to the stores. I thought that I could be using the JWT provided as a result of the firebase login for this task to ensure that the logins can be made only from within my app.
I figured out that certain signs in email and password methods can be logged in from outside the app it was intended for. However, since google and phone sign-in require an SHA-1 key to be registered to the firebase project, I wondered if I could ensure that by restricting logins to these methods, only the trusted app can generate valid JWT and communicate with my backend.
I do not know much about security, so I would really appreciate any tips.
I have an application that connects to firebase cloud storage to store images and firestore to store data. I have added some security rules that require the user to be authenticated to be able to modify the data. My application doesn't allow users to connect with firebase, I use another service so I made an automatic anonymous firebase authentication at the launch of the app so that users can use the application. I thought that the computer's SHA-1 key entered in the firebase(android) console would prevent the android application from being compiled on another machine and thus guarantee that anonymous users are on my application. However I can build and run the application on another computer without any problem, as if anonymous allowed that? How do I secure my application?
Thanks
The configuration data used by Firebase to find your project on the servers is not a secret (see here) and can be taken from your app by anyone and then used to also make API calls against your project. There is currently now way to ensure calls to the API can only come from your app (see here).
What you instead should do is create security rules that ensure all access is authorized, no matter where the API is called from. Doing this through Firebase's server-side security rules ensures that no one can bypass these rules, not even a malicious user.
Say that you give each user their own folder in Firebase Storage. You can then use security rules to ensure each user can only read and write files in their own folder. And with those security rules in place, it doesn't matter anymore whether they use your app to access the files, or whether they call the API with your project keys and their own code:, since the access is controlled by the server-side security rules.
I thought that the computer's RSA key entered in the firebase(android) console would prevent the android application from being compiled on another machine and thus guarantee that anonymous users are on my application.
That's not really the way it works. You can't restrict Firebase Auth from working on different devices or computers. The underlying REST APIs are public and can be called from anywhere on the internet. The SHA-1 key that you enter in the console is intended to identify your app, not a piece of hardware.
I have a web application where my users can log in through either user/ pass or Google, using Firestore to manage users/ auth.
I also have a Chrome extension that needs to leverage the same authentication session if possible - i.e stays logged in, token can easily be revoked if needed, and no need to type username/ password into the Chrome extension.
It is easy to do this by grabbing the user logged into Chrome (Not my app explicitly, but in most cases this is the same thing). This works fine using OAuth2.
Reading the docs, username/ password authentication seems to suggest you use Firebase Admin in a server environment to generate and return a token. This then creates more complexity around managing tokens, logouts, and revocation from what I can see.
I am wondering if it is possible to simply share the logged in state between Chrome and the Chrome extension via pushing the Firebase session/auth data in IndexedDb from the browser to the Chrome Extension in a content script? Would this effectively give the plugin the same 'session' as the main browser? Is there any risk in doing this?
Thanks