This page is superseded, check out Auth systems for updates.

OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on MediaWiki wikis will increase the reusability of its data and spur the creation of an ecosystem of apps around MediaWiki.

Rationale

There is a final frontier where Wikipedia and its sister projects are not as open as they could / should be: non-human interactions. Wikimedia’s infrastructure is designed to make it possible for millions of humans worldwide to freely reuse its contents, but it falls short of providing tools to allow third-party services to easily reuse its data. The goal of this proposal is to kickoff the development of OAuth functionality in MediaWiki to facilitate the reuse of Wikipedia's contents and spearhead the creation of an ecosystem of new services and applications based on its data.

Notes

This proposal is aimed at extending the MediaWiki platform but a lot of the examples are Wikipedia inspired this is to make the use cases clearer.
Whenever this document mentions OAuth it should be read as OAuth 2 draft 22 or higher.
This proposal does not suggest to fully implement OAuth 2 specification, but to implement the Authorization Code portion of the specification.
Probably the biggest question right now is whether this feature should go in core or be developed as an extension. Please chime in on the Talk Page.

Timeline

Documents

User requirements:
Specifications:
Software design document:
Test plan:
Documentation plan:
User interface design docs:
Schedule:
Task management:
Release management plan:
Communications plan:

Communications

Background

MediaWiki has an API providing read/write access to its database. This means you can edit, change and interact with MediaWiki's contents without using the MediaWiki interface. With some rare exceptions, though, API-based write access is only used by bots.

The write API inspires the idea of editing Wikimedia via something other than MediaWiki. A completely different interface could be used, tailored to particular user needs. The adoption of the MediaWiki API is limited to knowledgeable MediaWiki developers and highly experienced Wikipedia users. The creation of 3rd party apps around the current API is hindered by the fact such apps would need to store user credentials. By supporting OAuth-based authentication/authorization we can greatly expand the userbase of the API and attract new contributors to Wikimedia's projects.

MediaWiki as an OAuth authorization server

The focus of this proposal is to turn MediaWiki into an OAuth authorization server: the purpose is to allow client apps to:

securely access user credentials in MediaWiki;
obtain specific authorization from the user (the resource owner);
perform actions in MediaWiki on the user's behalf

Implementing OAuth-client functionality in MediaWiki, i.e. allowing MW users to access other OAuth-ready services – for example to authenticate and interact with external services like Twitter, Facebook, LinkedIn – is beyond the scope of the present proposal.

OAuth pseudo-authentication

OpenID is a popular protocol used by identity providers. While OpenID's primary focus is on authentication, OAuth is mainly concerned with authorization. MediaWiki has an OpenID extension which is more suited for single user login but it is not suited for providing granular authorization to different parts of the MediaWiki API. OAuth provides a so-called pseudo-authentication mechanism, the difference between OpenID and OAuth authentication are summarized below:

Proposal

Authorization flow

From a client app perspective, the user authorization workflow consists of roughly the following steps:

User visits third-party app X (with third-party app we include third-party websites, third-party mobile apps and third-party desktop apps).
Third party app X asks to grant authorization from user for a particular set of actions
Third party app X sends user back to Wikimedia
Wikimedia asks confirmation that user wants to authorize Third party app X to enable a particular set of actions, on a given set of resources and for a given amount of time or indefinitely
Wikimedia checks if the user has the appropriate user level rights, if yes then the user confirms authorization, Wikimedia sends user back to Third party app X else authorization fails.

The user authentication workflow will consist of these steps:

User visits third-party app X.
Third-party app offers user the possibility to sign up using Wikimedia credentials
Third party app X sends user back to Wikimedia to check user identity
Wikimedia asks confirmation that user wants to allow Third party app X to create an account using their Wikimedia identity
Wikimedia checks if the user has the appropriate user level rights to allow authentication, if yes then the user confirms request, Wikimedia sends user back to Third party app X with pseudo-authentication token else authentication fails.

The following is taken from http://tools.ietf.org/html/draft-ietf-oauth-v2-22, it shows the general workflow of OAuth 2.

Terminology

Resource Owner: An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
Resource Server: The server hosting the protected resources, capable of accepting and responding to protected resource request using access tokens.
Client: An application making protected resource requests on behalf of the resource owner and with its authorization.
Authorization Server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

Scope

Scope limits access to the client. The default scope should be read-only. Each single write right should explicitly granted by the resource owner.

Suggested Granularity of Permissions

Action	Relevant API command	Minimum required user group
Edit page	edit	Unregistered User
Create page	createpage	Unregistered User
Move pages	move	Registered User
Rollback	rollback	Administrator, Rollbacker
Delete pages	delete/undelete	Administrator
Restore deleted revisions	deletedrevs	Administrator
(Un)protect pages	protect/unprotect	Administrator
(Un)block users	block/unblock	Administrator
(Un)watch pages	watch	Registered User
Send e-mail	emailuser	Newly Registered User
Patrol changes	patrol	Unregistered User
Import pages	import	Administrator
Change user group membership	userrights	Administrator
Upload files	upload	Autoconfirmed Users
Retrieve public lists	allpages, alllinks, allcategories, allusers, allimages, backlinks, categorymembers, embeddedin, exturlusage, imageusage, logevents, recentchanges, search, usercontribs, users, random, protectedtitles	Registered User
Retrieve private lists	blocks, deletedrevs	Administrator
Retrieve Watchlist	watchlist, watchlistraw, feedwatchlist	Registered User

The current proposal does not consider the configuration of which groups should have access to these different rights.

Guidelines for 3rd party apps

Here are a few initial thoughts about guidelines for prospective 3rd party apps developers. Please discuss these on the Talk Page.

Every single transaction made by a third app on behalf of a registered user should be directly attributable to the individual user and username.
Administrators should have the right to immediately revoke the access of an individual 3rd party application.
All content created and modified through a 3rd party application will fall under Wikipedia's licenses and general terms of use.
The user preference page will include a separate section showing what Third party apps have been authorized and should have single-click revocation of authorization.
OAuth should be configurable in GlobalSettings.php
Network traffic is encrypted with SSL from the end user to the 3rd party app.
Rollback of all the actions by an individual application should be possible.

Use cases

The most obvious use case is to have a (simplified) editor that allows you to edit a Wikipage, such an editor could be more simpler than the current Wiki editor, it could be more advanced or it could be tailored to specific Wikiprojects. A second use case is it could offer platform independent replacement for tools such as Twinkle, Huggle and (AWB). A third use case is that it will enable us to quickly prototype new features without having the struggle to get it deployed on one of the Wikipedia projects to test it more rigoroursly.

Benefits for users

Wikipedia's data becomes even more reusable and accessible to whole new range of people.
No need to give their password to third parties
Revoke any authorization without having to change their password and without upsetting the others

Benefits for Wikimedia

Enable the creation of a ecosystem of apps around Wikimedia / MediaWiki.
Provides a way to approve applications, and set enforcable guidelines about acceptable use
Provides a way for third parties to "do the right thing" and not collect passwords
Provides a way to identify, on-wiki, actions made by third parties, and easily stop them if necessary

Design Documentation

Go to Design Documentation

Minimum version MediaWiki

The OAuth extension will probably depend on the following functionalities:

getAllRights() and Manual:$wgAvailableRights , r34357, MediaWiki 1.13.0
getWgHooks() and Manual:$wgHooks , r6405, MediaWiki 1.4.0

Privacy and terms of use

Use of MW-OAuth in Wikimedia projects will require that data produced by any client service be made available under open licenses to the Wikimedia community and respect privacy terms established by WMF.

Criticism

Argument: One concern that has been voiced in the past is that OAuth would open the floodgates to new people and hence we would see an increase in vandalism.

Reply: OAuth does not make MediaWiki / Wikimedia more open than it already is. OAuth offers additional safeguards including the API based throttling, limiting of scope of authorization and the actions of editors will still be directly attributable to the individual user.

Argument: OAuth 2 requires the authorization server to run over https and most Wiki installations (non WMF wiki's) are not supporting https.

Reply: OAuth support is definitely a more advanced feature for the MediaWiki platform but these days it is not very expensive to obtain an SSL certificate. The potential abuse by offering an insecure implementation is quite high it seems prudent to stick with the specification.

OpenID and OAuth bugs

bugzilla:3060
bugzilla:9604
bugzilla:13631
bugzilla:23735
bugzilla:30348 (Add Oauth support to MediaWiki)
bugzilla:35199
https://jira.toolserver.org/browse/TS-1084

Relevant extensions

Relevant documentation

Previous discussions

Alternative editing interfaces using write API
Revisiting becoming an OpenID Provider
MediaWiki OpenID patch
OpenID extension for MediaWiki
IRC discussion August 16, 2011
IRC discussion November 17. 2011
The Death of OAuth 2
OAuth/Issues - Issues in both OAuth 1 and OAuth 2 that seem to indicate we should abandon v2 of OAuth all together and perhaps consider working writing a new standard ourselves.

OAuth (obsolete info)