uiteoi
commented
10 years ago Here is what we are implementing in the Connected Sets Reactive Web Application Framework along with Passport-based authentication.
Think about each provider sign-in as different user identities for the same person and respect that this may be a desired feature for privacy, or professional vs personal use, or any other reason.
In many cases you don't have a choice anyways because you will not have access to information that would allow you to automatically link these identities such as an common email address.
In your "User Account Management" allow persons to link their user identities, but don't merge them so that users may me able to unlink identities in the future. To do so, allow signed-in users to sign-in using additional providers. Once signed-in you have enough information for linking identities.
The tricky part them comes with authorization management because users may use several identities throughout your service. You could allow your users to either:
- Select an identity, allowing users to switch identities at any time. The linking above allows them to switch identities without signing-out/in with another provider, making the process smoother.
- Use all their identities simultaneously to gain access to all resources accessible through all their identities. In this case you will still need to have a default identity that will be used for the creation of new authorization rules.
- To limit the undesired creation of identities, have a long-living cookie letting you know which provider was last used to sign-in to your service from this user-agent. Then provide this provider first with a distinctive sign letting end-users know which provider was last used to sign-in to your service.
Other rules that you may consider if you want to be friendly and less intrusive, therefore more trustworthy:
- Never request an email address from end-users, don't use a local strategy. It also greatly simplifies your user management such as user and password recovery, password management and related security issues, and removes a barrier of adoption for your application.
- Go one step further and discard any email address you receive through provider sign-ins, and let your end-users know with a message such as "Because your privacy is important to us, we are discarding your email address bellow unless you explicitly want us to keep it". This will make your application even more trustworthy to privacy-concerned end-users.
0xgeert
Not sure if this is the best place to ask but please bare with me.
Let's say I've defined multiple authentication providers (facebook, local), and consider the following flow:
What should happen now? Any best practices? In loads of implementations I see a
email-address already takenvalidation-message or something, but this doesn't feel quite right. Instead I would perhaps:options:
This must have come up earlier, so all insight greatly appreciated.