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.
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.
Is there a way to limit use of a web app to only users who have access to a specific custom Gmail domain. e.g users must have a '#companyName.ac.uk'email address in order to successfully sign-up/create an account.
Using just Firebase Authentication, no, you can’t limit who authenticates-it just authenticates users. Controlling what kind of privileges various users are granted is an issue of authorization and that’s up to the developer to build. That being said, Firebase does offer some features that can help like auth token custom claims, server-side Functions, and Firestore/Real-time Database access rules. Which combination of these works best for you depends on how you’re building you app.
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.
I'm getting a little overwhelmed with all the information available to me.
Say I have a website on which I want to authenticate users and manage their profiles for cross mobile reuse. This website works closely with Amazon AWS.
How can I achieve the following combination?
Authenticate users using a wide array of providers
Not integrate each and every provider separately and manually
Use the credentials from these authenticated users to integrate with Amazon Cognito
Facts that I am aware of:
There are services out there that offer a single API to authenticate with a wide variety of providers (well known example: oneall.com).
OpenId is a standardized authentication scheme that some providers implement. But the list seems much shorter than the lists of Social Network Providers that services such as OneAll support. However, OneAll also support OpenId it seems, but I'm not sure what that means for me.
Amazon Cognito integrates a very limited list of Social Network Providers, but you have to do the groundwork yourself, Amazon Cognito only seems to known about the keys they produce
Amazon Cognito also support OpenID
Ideally I would like to use one of the Social Network Provider meta services that allow me to effortlessly add and remove login options. At the same time, I want to be able to use Amazon Cognito to link these credentials to profiles.
What are my options?
Amazon Cognito supports users logging in with Facebook, Amazon, Twitter, Digits, Google, or any OpenID Connect provider. If you want to support users logged in with another provider or with a federated provider, you can use OpenID Connect or Developer Authenticated Identities.
OpenID Connect: There are products out there that federate/broker multiple social providers and expose the federated user via OpenID Connect which have special support for Cognito including Ping Federate and Auth0 to name a couple.
Developer Authenticated Identities enables you completely control the authentication process for the user. Essentially your user logs in with your own backend (which you could use to broker social logins) and your backend makes a secure call to Amazon Cognito with an identifier that you use to uniquely identify the user to retrieve a token from Cognito. Potentially you could federate identities using this method as well. The Cognito Developer Guide has a visual showing the flow to understand the big picture and a complete guide to setting it up.
Again, Amazon Cognito already supports the most popular social providers out of the box and we have a topic for each social provider in the Amazon Cognito Developer Guide, but above is a more exhaustive list of options.
I have tried using the node-xmpp package and blather gem. I got the furthest with blather, but succeeded with neither.
Blather attempt:
https://github.com/adhearsion/blather/issues/119
Node-xmpp attempt:
https://github.com/astro/node-xmpp/issues/149
From the Facebook API Docs:
Authenticating with Username/Password
The DIGEST-MD5 SASL mechanism is available to support traditional XMPP
or multi-protocol IM clients that are not customized for (or even
aware of) Facebook. This mechanism requires prompting the user for his
or her password; therefore, it should only be used when necessary. In
particular, it MUST NOT be used for any client that:
Proxies the XMPP connection (the connection must be directly from the user's computer to Facebook).
Reports messages or any other information about user activity to a third party (including the client developer).
Integrates with Facebook, or has a Facebook Application ID. If your application does any of the above, you must use Facebook Platform authentication instead.
I think your application is doing one of the following, correct me if I'm wrong but based on the links you provided for your blather and node-xmpp issues I think you may be trying to violate the third criteria.
Integrates with Facebook, or has a Facebook Application ID. If your application does any of the above, you must use Facebook Platform authentication instead.
Link: https://developers.facebook.com/docs/chat/