== Preamble ==
The MediaWiki extension [[ https://www.mediawiki.org/wiki/Extension:WSOAuth | WSOAuth ]] allows to have an external identity provider for your wiki relying on the OAuth protocol.
This extension was probably designed to speedup sign up in a fresh wiki, or in a wiki where the nicknames were the same of another wiki, without much concerns about allowing already registered users to decide whether or not to authorize a certain identity provider for them.
== Description of the issue ==
At the moment, it's up to the server system administrator to fight a phenomenon called "account usurpation" with WSOAuth.
In short, when you are sure that a specific nickname `Foobar` in your local wiki is in use by the same human of the same nickname from the upstream identity provider, you tell the server sysadmin to execute a maintenance script from the command line:
```
$ php extensions/WSOAuth/maintenance/migrateUser.php --user 'Foobar'
```
This workflow was damn simple and effective for those wikis where all the already existing users have nicknames definitely the same as upstream. In fact, to just approve every upstream nickname to login into your local nicknames, you can just execute this command:
```
$ php extensions/WSOAuth/maintenance/migrateUser.php --user '*' --migrate-all
```
or:
```
$wgOAuthMigrateUsersByUsername = true;
```
In short this is the current WSOAuth workflow:
# user wants to login via an external identity provider
## Case 1: __server sysadmin__ authorized that nickname previously
### user redirected to external identity provider and insert its correct credentials
### redirected back to your wiki and login success
## Case 2: __server sysadmin__ does __not__ authorized it previously
### login fail
That's not a desirable use case for some reasons:
* manual verification activity in large wikis takes time
** every hour of a server sysadmin costs ($$)
* it's not clear how to verify an user (contact each user via Special:SendEmail via both wikis?)
* this can be the cause of human errors or social engineering
* this is not the real-world workflow
== Desirable use case ==
Let's take [[ https://gitlab.com/ | GitLab ]]. GitLab is not MediaWiki but, as user, you may get yourself a good idea.
GitLab has lot of external identity providers. They do not have any "account usurpation" system because none of its identity providers is allowed to "usurp" any existing account. GitLab's workflow, instead, is:
# user wants to login via an external identity provider
## Case 1: __user__ (→ not server sysadmin) authorized it previously
### user redirected to external identity provider and insert its correct credentials
### redirected back to GitLab and login success
## Case 2: __user__ does __not__ authorized it previously
### login just fail
How to enter in Case 1? Let's see:
# user is already authenticated
# user press "allows this specific identity provider"
# user redirected to external identity provider and insert correct credentials
# user redirected back to GitLab and that identity provider is now usable
NOTE: In GitLab, server sysadmins are not involved in any step of this workflow.
== Proposed solution ==
[] add in WSOAuth a special page ("ConnectedOAuthAccounts"?) to activate signin with one of the provided identity providers. The page must be accessible only by registered (logged-in) users.
[] edit the user's preferences page to add a courtesy shortcut to that special page