What are the differences between signInWithPopup vs linkWithPopup in firebase? From the API reference, I can barely get anything useful regarding the differences.
They are completely different operations.
signInWithPopup is for signing in an existing user through an authentication provider that can use popup windows to handle the interactions with the user. The alternative with signInWithRedirect, which does not use a popup.
linkWithPopup is for linking additional authentication providers to an existing Firebase auth account using a popup window. The alternative is linkWithRedirect, which does not use a popup.
I suggest reading through the documentation for signing in users (Google, Facebook), and linking additional accounts.
Related
There is plenty of tutorials and articles on this precise question but each one contradict the previous one,
I'm trying to make a signup and login reactJs pages with Firebase js sdk on the frontend, that's what I found most of youtubers devs do,
And then I found that is not secure (doing the authentication on client side).
You should use the Firebase Admin SDK (firebase.google.com/docs/admin/setup) on Firebase Cloud Functions or a self-hosted server in that case. Everything else would just be a dirty hack – PRSHL source
It's not recommended to create admin accounts on the front end as anyone could look into the code and action it themselves. source
I really want to understand if it is not secure to use it on the client side, Why does firebase provided it in the first place ?? or is there another way to properly write the auth using firebase js sdk on the frontend ? of course without using admin sdk
Or should I use firebase js sdk on the backend with express ?
I only want clear and detailed answers please !!
My best guess is that you're confused between authenticating a user client-side and the fact that Firebase provides a client-side SDK for authenticating users.
Though all you have to do to use Firebase Authentication in your app is implement its client-side SDK, there are many more parts involved in the process - and quite a few of them run on secured servers.
It's just that Firebase (and the authentication providers it supports) have implemented the server-side of the authentication process for you already and made the variables parts of the process part of the configuration that you provide either in the Firebase console, the provider's web interface, and/or in the configuration that you specify when you initialize the Firebase SDK in your client-side application code.
From the comments you now added, the second is correct and explains exactly what the risk is:
It's not recommended to create admin accounts on the front end as anyone could look into the code and action it themselves.
So while you can safely create a user account on the client (a process known as authentication), marking them as an admin (a process known as authorization) has to happen in a trusted environment as otherwise any user could make themselves an admin.
I am using firebase for a website, where users can sign in with their microsoft accounts via OAuth 2.0:
import {getAuth, signInWithRedirect, OAuthProvider} from "firebase/auth";
(...)
const provider = new OAuthProvider('microsoft.com');
const auth = getAuth();
signInWithRedirect(auth, provider);
It prompts the Microsoft Single Sign-on with a redirection work-flow.
The authentification works nice with firebase, except one detail:
When I sign in with the Microsoft account in the browser for the webapplication, I am also signed in to my complete Office 365 account in the background and other potential microsoft sites.
So if I open a new tab and go to the my Outlook 365 online mail, then I am already logged in since I logged into my webapplication. If I happen to forget to log out from the webapplication, my entire mailbox, calendar with all the microsoft account information are exposed.
I have looked through all the pages and settings in the Azure Portal where I set up application/tenant id's, looked at Scopes and looked at OAuth 2.0 parameters from the Mirosoft documentation,but I can't find anything about this issue.
Single sign-on is originally made as a convenience for the user, but in my case I would like to prevent it as a security measure.
How can I limit the microsoft sign-in to only authenticate in the webapp/firebase project, and nothing else?
The simple answer is - you can't do that.
SSO is exactly what it means - Single Sign-On. The user logs in once and can use different apps without the need of authenticating again. You ask Microsoft to verify the identity of the user for you. Microsoft logs the user in and gives you back the answer. But it means, that on this browser the user will be able to use other Microsoft services as they already verified their identity.
The only thing you can do is to inform your users about the security risks and tell them to make sure to log out at the end of their work (you can then log them out at Microsoft as well).
If MS supports backchannel initiated log out, then you can try to implement some action that will check if your user's session is still active, and if not, then initiate a logout at MS. I don't know if they support it though.
I'm using Firebase in a side project that requires authentication using Facebook, Twitter, Google and Twitch. Unfortunately, Firebase Auth doesn't support authentication using Twitch out of the box. I would like to know the best approach to solve the problem: can I use Firebase Auth & a Custom Auth system only for Twitch?
Firebase supports signing in with any provider, as long as you are willing to write the code for it. The process is pretty well documented in a page called creating custom tokens.
If you're looking for samples for other providers, have a look at the functions-samples repo, which contains a.o. samples for signing in with LinkedIn, Okta, and Spotify.
I am trying to implement sso with firebase authentication and i am trying to use without using third party like okta and wanted to know is it any workaround with this.basically the use case like this
A client wanted to build a custom SSO solution and had already chosen Firebase, based on Google’s promise to rollout SSO support in the future. The client did not want migration to any other SSO provider like Auth0 or Identity Server, or to deal with user-password migration and potential related issues. They preferred instead to use a temporary, custom solution that would store user’s passwords in Firebase Authentication.
The client had several customer portals based on WordPress Customer Relationship Management (CRM) and an existing list of users in Firebase Authentication. Each time users visited a new portal, credentials were required, and again when users followed a link from one portal to another. It was not always obvious for users that the same credentials should be used for different portals.
By default, Firebase keeps authentication context for one domain but doesn’t provide seamless SSO integration between different domains. To provide this functionality, SoftServe determined that a new Firebase service should be implemented.
I'd like to create a user using admin.auth() with GoogleAuthProvider.
I've successfully allowed the creation of users with email/password combinations from the back-end, but is the same possible with e.g. Google / Facebook sign-in?
It seems there are providers available for use with firebase.auth():
var provider = new firebase.auth.GoogleAuthProvider();
Is something similar possible with admin.auth()?
I don't think this is possible, as the sign-in libraries for the various authentication providers depend on other libraries that were built to be run in web browser environments, and depend on the user being able to authenticate themselves using UI components that require browser interaction. In those cases, Firebase Authentication never sees the user's password or other credentials.