For Firebase local it states "An explicit sign out is needed to clear that state. Note that Firebase Auth web sessions are single host origin and will be persisted for a single domain only."
Is there any way for logins to be persisted for multiple domains with one login?
Related
My firebase application involves uploading users via CSV on our platform which then adds users accounts to firebase. This has been fine for handling Google / Microsoft based accounts since these accounts are able to be linked with the existing records automatically when a user signs in.
However, I recently added a custom Open Id Connect application through OneLogin, and these accounts are not treated the same. If users are uploaded the old way, they can not be linked to this provider and users cant authenticate.
Is it possible at all to automatically set an identity provider to an account? Or does it require a successful authentication through that provider?
I am using firebase firestore as datastore for my web based application. The application has 2 different actors.
Supervisor: logs in via a common password set for all supervisors plus the ability to generate unique codes.
User: logs in via the unique code generated by the supervisor.
I am using cloud functions to do the heavy lifting for both actors. Now these functions are protected with cors and whitelist for origins.
I am trying to secure the routes created with cloud functions with a Auth Middleware relying on the concept of if the request is not from authenticated account or not.
I have created a email and password accounts for both actors for the frontend section of my application.
The question is if I am to go with firebase Auth api to get the refresh token and use it as jwt in the Middleware, will it be an issue since let's say 100 supervisor are connected and performing some tasks, and the same thing for the second actor ? Because after examining the refresh token it contains the uid of the account authenticated and using the same account for multiple connection is the blocking stone in this scenario.
the point of a token to be used in every operation is to validate the origin of the request
Firebase Authentication uses ID tokens to verify the user's identity, not the origin of requests. A malicious user in your scenario can get the credentials from the app, and use them in their own code - calling APIs on your Firebase project.
If you want to only allow calls from your own app, consider using the new App Check feature of Firebase.
I know that using firebase in a web app requires putting some public config keys in the front end code and that its safe to do so. But I am confused about how firebase would prevent malicious people from just copying those config keys and pasting them in their own sites and initializing the firebase analytics sdk there to try to spoil my analytics data.
In firebase auth, we also give some whitelisted domains and authentication services are only allowed on those domains by firebase. So even if we try to access those auth services from another domain, firebase won't allow it.
So how will firebase differentiate in case of analytics? If the same config keys are put in webpages on two sites abc.com and xyz.com and abc.com is my actual site whose traffic is supposed to be tracked, how will firebase know and discard data from the bad website xyz.com if the person who created xyz just copied my config from my front end code and initialized firebase.analytics() on their site to spoil my analytics?
I am new to Identity server but I found it quite easy to set up.
Our goal is to implement SSO down the line but at the moment we are just moving our authentication logic out of application.
It is going good except I have one confusion.
When I set up the Idsrv, I had to create admin user as well as token requesting user. This was to access and configure Idsrv.
For application auth, I have to use Idsrv as federation server as well and authenticate users against some Asp.Net data store.
Now there is already one data store where Identity server specific users are stored.
Should I be using same store for my application user auth and created/edit these users in that store? Or can I/should I create a separate database for application specific users and use both?
At the minute, I am authenticating application users against Idsrv store.
I am not sure if I am logically thinking in right way to split these two user sets and calling one as Idsrv specific users. (We will have Identity service separately deployed for each application)
Thanks for your help in advance.
"Authentication requests to Firebase Simple Login are only permitted from domains you specify." and the two default domains are "localhost" and "127.0.0.1".
Let's say that my server's IP is "267.156.423.22". How do I setup my security rules so that that the two first domains can read specific data, but only the server can write it?
For example, if a client purchases a product, this fact and associated data needs to be noted on the client's account in the Firebase. For obvious security reasons this information must be 'writeable' by the server only.
The authorized domains configuration for Firebase Simple Login applies solely to OAuth-based authentication providers (Facebook, Twitter, and GitHub), and restricts requests to those origins in the browser.
That means if you're using one of those OAuth-based authentication providers, you'd want to enter in any origins which your end users will use to access the page (i.e. if your user accesses the page via subdomain.example.com, that'd the be origin to enter).
Keep in mind that Firebase Simple Login is built on top of that standard, one-size-fits-all custom login / token generation in Firebase. It is an abstraction layer intended to make it easy to generate Firebase Auth. Tokens, a secure way of sharing data between you and Firebase.
Once a token has been generated (via Simple or Custom login), you can begin using that token's payload in your security rules (via the auth variable). If you'd want your server to bypass security rules, simple generate a token with the admin privilege, or your Firebase secret. See https://www.firebase.com/docs/security/security-rules.html for more details.