Preamble
The MediaWiki extension 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-allor:
$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
- Case 1: server sysadmin authorized that nickname previously
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 does not cover some use-cases
Desirable use case
Let's take 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
- Case 1: user (→ not server sysadmin) authorized it previously
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
Resolution criteria
- add a way, for legacy registered users, to activate remote logins for themselves (instead of requiring interventions by the system administrator)
- allow a legacy existing user with nickname "Foo" to authorize itself even if it's remote nickname is "Fee" or whatever