5 days and 15 hours ago
in reply to
The second reason to take this approach is the fact that it is not a common case to login with different accounts to single site. Do you really think this case can be useful?
We just redesigned our login system for several reasons
1. We had multiple accounts with the same email and different login methods. Many of our users would log in with twitter one day, yahoo the next, google and facebook and them create a local account. I don't think this was intentional in all cases as people just forgot if it was google or facebook login they used.
2. We were using openID 2.0 and wanted to modernize our accounts.
3. We wanted to integrate with sitefinity better.
We ended up building an identityserver3 server that support google, facebook, twitter and local accounts and all our apps use owin OpenIdConnectAuthentication() with some custom patches (there are bugs in the way it manages cookies).
The plan was to deploy a man in the middle STS that translated from OpenID connect so having this built into 10.0 means I will leave this integration point out till later.
The big stumbling point is if the new system will pull common fields like email (it's all we collect) so users can sign up for sitefinity newsletters and such without retyping their email.
As for trusting providers, google will tell you if it has verified the email. Facebook will not let you log into other sites until you verify. Twitter doesn't provide an email so we let them log in and then block them until they click a link in the email.
The issue we are typing to solve still is how to allow AD authentication for the admin but social for the front end.