I have an app with both fb logins and local logins implemented. Now I'm trying to figure out the best way to combine these strategies. As I see it, I can either
maintain two records
combine the two records
Taking the first option would mean two scenarios: FB record first, or Local registration first. If FB precedes a local registration, I would need to add a hashed password to a record containing an FB ID and email (I'm using email as the primary identifier in the local login as well). That seems like the bigger challenge. But perhaps that's not a great idea - I'm trying to find out what strategies are best supported and practically workable.
For the moment, I'm using just these two strategies, but the app I'm building will probably want to add other social media strategies, which seems to favour allowing each login type to be a separate record.
Can anyone suggest a best-practice, and perhaps help me out with adding a password to a record that represents a previous FB login?
To be honest, there are many ways to solve this. You will have to pick the one that suits your needs best.
To give an example : if you look at parse apps, they support FB login, Twitter login and local registration. They manage this by creating a user record and then storing access tokens for the FB / Twitter logins along with emails & password (used in local registrations).
in your case, it would creating FB/Twitter/other services records against local logins. Does that make sense?
Check out the parse FB integration and see how things work. It should give you a great idea.
Related
I am working on a project which needs User Authentication. The "Clients" are iOS (Swift) or Android (Kotlin) native applications. The original form of the API (NodeJS) used Facebook and Account Kit for OAuth and Phone authentication respectively. Since Account Kit shutdown, we moved to Firebase Phone Authentication for Phone but left Facebook in its original form. Now, we're wanting to consolidate our Authentication providers (to Firebase) but I can't seem to find a way to "convert" or "import" Facebook users to Firebase-based Facebook users.
So far, I've read through the Documentation, including the category about importing users, but it doesn't seem to indicate an ability to maintain backwards compatibility, while also moving forward to Firebase. What I mean is, it has an ability to set information, but it doesn't indicate that the same information will be used to authenticate that user as the same unique visitor.
What I am looking for is either transitory logic, which will handle this during login, or preferably, a "bulk-insert" type migration. Essentially, I want to have it setup so that the API only needs to keep a single authentication UID, and use only a single third party (even if they then use another subsequent third party) while maintaining user uniqueness (so that it doesn't create a new user for the same Facebook account).
Part of my problem in creating a temporary patch (not necessary if the main question is answered) is that I don't know of a way to differentiate between a Facebook UID and a Firebase UID to fork the logic. Again, this is only relevant if there isn't a solution for migration.
Feel free to request any more details that would be useful.
Update #1
I realized my question was open ended in what I was asking. I've been digging further and can better define my question:
I need a way to bulk insert users into Firebase's Authentication with a provider of Facebook. I know I can import them, via admin.auth().importUsers([...]) and that I can create accounts via admin.auth().createUser({...}) but when I do the former I can't seem to get back the user's UID, and the latter doesn't seem to allow specifying a provider. Am I missing something?
Given the increasing concerns in data privacy, is it possible to build a web app that provides a driven user experience (aka different outcomes on different users based on their specific profiles) without sending any personal information that can be tracked, hijacked or forced by any entity on the web app's servers ?
The question is somewhat vague, but due to the fact that HTTP is stateless, you'll need users to send some kind of information, at the very least user registration and login data to identify them and store their identity in some kind of storage (ex. cookie).
If you dont want the users to post any data, you wont be able to personalize the experience, just provide the same experience to everyone every time they enter your website.
I think you can do this, but you will need to identify users at the start, and then unidentify them later - for example, get them to register with an email address, confirm that address, then create an identifier derived from that address (e.g. a hash or random number), switch to using it as a user name and delete the email address. Then you will be at a point where they can log into an account, but you hold no personal identifiers on them.
What Cross-Domain Single Sign-On implementation best solves my problem?
I have two domains (xy.com & yz.com) which already have their own database of users and are already implementing their user authentications separately. Recently there has been the need to implement CDSSO so that users dont have to log in each time they try to access resources from both domains.
Ideally the CDSSO implementation I hope to use should allow custom implementation of authentication, as I hope to call API's provided by both domains during authentication to confirm a user exists in at least one of the domains user database.
I've been looking at Sun's OpenSSO which seems to provide a means to extend its AMLoginModule class yet this seems to be a long thing and more annoyingly they seem to stick to GlassFish.
I've also considered developing a custom CDSSO to solve our needs. Is this advisable?
Is this achievable using Suns OpenSSO considering the disparate user database as I there will be no need to make use of the User db that OpenSSO requires?
Are there any simpler means of achieving what I intend to achieve?
In addition both applications which exist on the two domains were developed using PHP. How does this have an effect considering Suns OpenSSO is based on Java EE?
Are there any clearly specified steps on implementing OpenSSO and or any other SSO implementations from start to finish?
I suggest you to use simpleSAMLphp in order to deploy an Identity Provider and 2 Service Provider (for each app).
SimpleSAMLphp allows you to select multiple authentication source and is not hard to build your own authsource that consults the 2 databases.
My experience in SAML says that the fact of not consolidating the Identity of the user in 1 unique authsource is a bad idea due several reasons:
* identity conflicts: what happen if you have the same user registered with different mail (if that is the field yoy use to identify the user) and you try to access? You could be logged in different account each time.
* what happen if you add a 3rd service, do you gonna add a 3rd database
* what happen if user change its data in one app, the other gonna be no synched?
* what happen if user uses different passwords?
I recommend you to execute a migration process before adding the SAML support and build a unique database for all your identities and unify the registration/edit profile/password recovery process of both sites in one.
SimpleSAMLphp has good documentation, but I can provide to you any documentation related to the process that I suggested.
Let me start by saying I really like Deployd. I want to use it in production, but I want to incorporate OAuth and social logins, so I installed the dpd-passport module. It works great, except for two little (big) problems:
When a user signs in via an OAuth provider (e.g. Facebook, Twitter, Github) a new user record is created...but if the same user clears their cookies or uses a different browser to log in, a new user record is created.
If I do something clever (read: hacky) and assign users with social logins an ID based on the socialAccount and socialAccountId (something unique but constant for each social account), someone could use the standard method of user creation to spoof a user by making a POST request to the /users endpoint if they knew that user's socialAccount and socialAccountId.
My question is: How can I A) prevent #1 from occurring, or B) disable the standard method of user creation without also preventing OAuth user creation?
Has anyone ever successfully used Deployd and dpd-passport in production? If so, I want to speak with you...
Thanks in advance!
First of all, I think you haven't added the custom fields per the docs.
https://www.npmjs.com/package/dpd-passport#requirements
I hadn't either, and observed the new user feature (because it couldn't lookup the response from the auth service to find the user from before). Adding these fields fixed it.
Also, there is a google group here:
https://groups.google.com/forum/#!forum/deployd-users
Hope that helps.
I am trying to use the new authentication system and I cannot find any decent articles/documentation to get what i want. Plenty of stuff out there explaining how the authentication process works out of the box but realistically you will need more.
First of all how do you control which database you store user information? I have read in many place that you can add a connection string. Ok great, but how do you get that connection string to be used by the authentication system?
And how would this work in a web farm, assuming user account information is split across databases with a little piece of logic which decides which database a user should login against?
I have used keystone extensively and it really isnt bad to implement. Its the authentication mechanism of Openstack. Check it out here http://docs.openstack.org/developer/keystone/
To answer your question users would first authenticate with it, receive a token, then they would present their token at any of your servers. If your data is split up, you can configure keystone to only allow access to certain areas of you backend via groups.
Changing the underlying database needs to steps. You have to add the connection string for the database you want to use for Identity. After this you have to change the base constructor call in your DB context to pass your new connection string to the base class (this is your missing step). An example for it is shown in this thread.
For your second question I don't have a good answer, because I haven't used Identity in a multiple DB servers scenario yet.