User talk:Tgr (WMF)/external login

There are several advantages (as well as disadvantages) to using an external identity provider. It allows for faster sign in and account creation, users don't need to remember different passwords for each website, etc.

However, it can be a privacy issue. The OAuth 2.0/OpenID Connect access scope should have the minimum permissions necessary to sign in and collect the external user ID (and e-mail address if creating a new account), and nothing else (throw away all unnecessary information such as the user's full name), and using an external identity provider to sign in to MediaWiki should be optional.

While creating an account, let users use their external account to create the account. The e-mail address on the external account (if any) will be used as the MediaWiki account's e-mail address, and the user will be asked to create a username after signing in to their external account. If there is no e-mail address on the external account, or MediaWiki was unable to get the e-mail address, the user should be asked to specify an e-mail address and verify it.

Users should be able to link and unlink their external accounts using Special:Preferences.

Users will be asked to create a password (or get a temporary password by e-mail) if they unlink all external accounts and they don't currently have a MediaWiki password.

As for what identity providers to use in Wikimedia sites, use the most commonly used ones, such as Google, Facebook and Microsoft, and sort by most commonly used. And use identity providers that implement OAuth 2.0, OpenID Connect and (maybe) SAML 2.0.

This isn't really any different than the possibility that someone might forget their password.

The difference is that a user forgetting their password is purely within the user's control, while a third-party going away is something out of their control.

We could ostensibly also use external providers as proof of authenticity but not an identity source - ie. when you click the Google button on signup and Google verifies you have an account with them, we clear the captcha and disable throttling (and throttle on the Google ID instead), but you still need to go through the normal login process. I don't think there is much point to it but technologically it would not be hard.

We can use the external provider for authentication, but still have MediaWiki accounts. Also, if the third party goes away (or the user's account is deleted, or if the user cannot access the external account), the user can use Special:PasswordReset to regain access to the account.

Personally I think the biggest issue will be determining how and which external login providers we support. We should establish criteria that all external login providers must meet, and then a process for adding new ones (are we going to require a minimum number of users before adding a service?, etc.). And how we display them on the login/create account pages themselves..do we want to make the most popular ones more prominent (Google, Facebook, etc.) or can we be neutral and just alphabetize them or something..

As a start, I think we should only be supporting login providers that use a standardized auth mechanisms (OAuth, OpenID, etc.), no proprietary protocols.

And RIP Persona :(

Yeah, it's a shame Persona did not work out. As for choosing a login provider, IMO no need to overthink it, just pick the biggest one and you get most of the benefit for the least amount of debate and development cost. Google and Facebook are the obvious choices (both have around 1B monthly active users, with all competitors lagging far behind); given that Facebook is arguably more misaligned with Foundation values and definitely more disliked, and that GoogleLogin is better maintained than the Facebook alternatives, I think we should go with Google. (Also it would be more interesting for the Android app.) If some community wants a different provider that's more popular in their geography, that can be discussed later on a ony-by-one basis.

I suspect the biggest technical blocker to enabling a new service will be "someone needs to write a PrimaryAuthenticationProvider for the new service".

I looked for stats and the closest thing I found is this PDF (via here). It has a fair amount of self-promotion and limited to the users of a certain social login/share plugin, but claims Facebook is quite a bit more popular than Google for login (the runners-up being Twitter and LinkedIn). Also, "80% of users dislike traditional registration forms and 73% prefer to log in using their social accounts" although again, they have an interest in promoting social login + unclear how they got the numbers.

Just found out (through the accident of a friend) that this antifeature is still in effect. Unless it can be verified that it cannot be used for OAuth, we definitely need to stay away from Facebook.

It seems to me a fair bit of this bullet is overblown, since anyone who is concerned about connecting their Wikipedia account with their third-party account is free to just not link them, and if some attacker manages to break into our database to steal the account mappings we're probably going to be much more concerned that the attacker could also have stolen password hashes and email addresses.

True (although we plan to move hashes to more secure storage, not sure about emails). The one scenario that is troubling me is where the attacker monitors the network traffic, detects the Wikipedia -> provider-> Wikipedia pattern that's indicative of an external login, and correlates it with public user activity. As long as we have public account creation logs / account lists it's trivial, and even if we hide them there it might be possible to identify the user over time from edits performed immediately after logging in. Granted, if you are worried about government tracking, you should not use external login... maybe we should just show a warning and use a cookie to make it one-time-only?

Would this service be covered by the Meta:Privacy policy? If so, presumably the following section would apply.

To Our Service Providers

We may disclose personal information to our third-party service providers or contractors to help run or improve the Wikimedia Sites and provide services in support of our mission.

As hard as we may try, we can't do it all. So sometimes we use third-party service providers or contractors who help run or improve the Wikimedia Sites for you and other users. We may give access to your personal information to these providers or contractors as needed to perform their services for us or to use their tools and services. We put requirements, such as confidentiality agreements, in place to help ensure that these service providers treat your information consistently with, and no less protective of your privacy than, the principles of this Policy.

Are you confident that Google or Facebook would agree to sign the WMF confidentiality agreement?

More likely this section would apply, considering that it would only be used when a user specifically links their Wikimedia wiki account to the third party for the purpose of authentication.

With Your Permission

We may share your information for a particular purpose, if you agree.

Further, it's likely that MediaWiki itself wouldn't send any user-specific information to the third party. Everything the third party gets would be either the "Information We Receive Automatically" type (because they receive it automatically too, that's how the Web works) or things they might be able to derive by correlating the login with data that MediaWiki makes publicly available such as edits and Special:Log.

As Anomie says, the WMF would not share any information with the external provider; the provider would share information with the WMF (presumably a user ID, a username and maybe an email address), after getting explicit permission from the user. It's important to explain to users what information their browser will share with the provider if they use the login option, but that's not really something that would fall under the privacy policy. (In my non-expert opinion, anyway. WMF Legal would of course be involved before any serious planning.)

I'm glad to hear that you don't think that the proposal would rely on having other, possibly for-proft, parties signing up to WMF terms.