Feature: Multi-Auth login about loopback-component-passport HOT 11 CLOSED

Any feedback on this?

from loopback-component-passport.

@raymondfeng ^

from loopback-component-passport.

:beep boop:

from loopback-component-passport.

@BerkeleyTrue What did you end up doing here?

from loopback-component-passport.

I overwrote the link method on the userCredential model

  UserCredential.link = UserIdentity.link.bind(UserIdentity);

A word of warning, doing this was a bad idea.

90% of our support tickets were from users who created duplicate accounts when they mistakenly used the wrong oauth. We've since made it impossible to create new accounts with all but one oauth.

from loopback-component-passport.

@BerkeleyTrue Do you mean you allow users to create accounts with email/pass OR oauth? I would think you still might end up with duplicate accounts that way, no?

In any case, I've ended up having to overhaul passport-configurator.js, partly related to the issue you encountered (though what we did was lookup if an oauth account creator had already linked to another user, and if so then we do nothing -- instead of creating a dupe account).

Though the other reason we had to overhaul is that it basically falls down when you try to use it with an iOS app. API/JSON behavior is not fully baked. Am thinking to maybe ditch/fork this module and roll my own variant modeled off of this.

from loopback-component-passport.

Problem is not all o-auth services send back an email. Also, users will create accounts on these services with different emails. You can't always rely on having enough information or the correct information to match up social o-auths. And users won't realize this and blame you for loosing their account and their data.

from loopback-component-passport.

The solution is very easy using hooks.

@ernie58 made a good solution to provide a stable sync between creds and identity:

#19 (comment)

from loopback-component-passport.

@BerkeleyTrue : Not a problem with proper flow.

When you use some social network (o-auth provider) to login and can not identify user as new or current - just make clear statement on this. If social network did not provide any email and you want to use email as user identifier - just add a step to sign-up to provide/confirm email. If user will provide email for current account, link them (maybe after some security checks). Provide ability to merge accounts based on sign-up via different o-auth providers.

Other case is when already logged-in user want to link his account with some social network. So after linking he should be able to use that social network to login into his account.

This should be not mess.

from loopback-component-passport.

just add a step to sign-up to provide/confirm email

This was considered but this adds a ton of friction for new users

So after linking he should be able to use that social network to login into his account

That was the point of this issue

from loopback-component-passport.

@BerkeleyTrue :

This was considered but this adds a ton of friction for new users

Then product designers should consider: what make more friction for users - one more step for sign-up process or merging accounts later.

IMHO, merging accounts looks better.

That was the point of this issue

Yup. For me mess with linking account in LoopBack was surprise. If user linked social network with his account - then he should be definitely able to login via social network into his account. Not a case for LoopBack. This is silly.

I m agree that sign-up based on social networks have different design patterns and different products should be able to choose flow. But framework should support that different flows: maybe some project will use sign-up stage with email confirmation after sign-up with twitter (which did not disclosure email of signed-up user), maybe other project will choose to merge accounts later. Its up to project, but framework should provide flexibility.

Not sure if my english is enough to describe my point ;)

from loopback-component-passport.