OAuth (obsolete info)

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 an OAuth implementation to facilitate the reuse of its contents in the form of structured data and spearhead the creation of an ecosystem of new services based on Wikipedia’s data.

Note 1: 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.

'''Note 2: Whenever this document mentions OAuth it should be read as OAuth 2 draft 22 or higher. '''

Note 3: This proposal does not suggest to fully implement OAuth 2 specification, but to implement the Authorization Code portion of the specification.

=Synopsis= OAuth provides a standard protocol for negotiating secure access tokens to provide granular access to third-party tools (web or client) based on account permissions and selective authorization to MediaWiki resources. This protocol does not reveal usernames or passwords to the third-party tool.Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of data and spur the creation of an ecosystem of app's around Mediawiki.

=Background= MediaWiki has a write API. This means you can edit, change and interact with MediaWiki's contents without using the MediaWiki interface. With some rare exceptions, this functionality is currently 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 this API is not possible because such a app would need to store the user credentials. By offering OAuth we can greatly expand the userbase of the API and attract new people in new ways.

The OAuth usage terms will require that data produced by any such service be made available under open licenses to the Wikimedia community and be respectful of privacy terms established by WMF.

=Proposal= We offer OAuth server side enabled by default on Mediawiki. The user 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 ask confirmation that user wants to authorize Third party app X to enable a particular set of actions for a given amount of time
 * 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.

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

Terminology

 * Client is the third party app.
 * Resource Owner is the end user
 * Authorization Server is the MW application that generates tokens and verifies permissions
 * Resource Server is the actual project to which access is gained.

++                              +---+     |        |--(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 ---|               | ++                              +---+

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
 * Can manage authorization to third parties from the OAuth provider (ie MediaWiki)
 * see all authorizations they have granted
 * 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

Granularity of Permissions
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.
 * Third party app's code *must* be open source (up for debate)
 * 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.

Proposed database model
This datamodel is inspired on oauth2app.

Constants
KeyGenerator creates a SHA1 key with the specified length.

Client Table
Stores client authentication data

default_key: KeyGenerator(CLIENT_KEY_LENGTH)

default_secret: KeyGenerator(CLIENT_SECRET_LENGTH)

Access Range Table
This table stores the range data or also known as scope

Access Token Table
Stores access token data

default_token: KeyGenerator(ACCESS_TOKEN_LENGTH)

default_refresh: KeyGenerator(REFRESH_TOKEN_LENGTH)

Nonce Table
This table is maybe not necessary as we can store the nonce's in memcache.

Common Criticism
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. 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.

OAuth & Openid
OpenID is primarily focused on authentication while OAuth is 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.

Relevant bugs

 * https://bugzilla.wikimedia.org/show_bug.cgi?id=3060
 * https://bugzilla.wikimedia.org/show_bug.cgi?id=9604
 * https://bugzilla.wikimedia.org/show_bug.cgi?id=13631
 * https://bugzilla.wikimedia.org/show_bug.cgi?id=23735
 * https://bugzilla.wikimedia.org/show_bug.cgi?id=30348

Relevant extensions

 * https://fusionforge.org/plugins/mediawiki/wiki/fusionforge/index.php/OAuth_Provider
 * https://fusionforge.org/plugins/mediawiki/wiki/fusionforge/index.php/OAuth_consumer_Plugin
 * http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/OpenID/
 * http://www.mediawiki.org/wiki/Extension:Facebook
 * http://www.mediawiki.org/wiki/Extension:TwitterLogin

Relevant documentation

 * http://www.mediawiki.org/wiki/Extension:OpenID
 * http://www.mediawiki.org/wiki/Authentication

Previous discussions

 * Alternative editing interfaces using write API
 * Revisiting becoming an OpenID Provider
 * MediaWiki OpenID patch
 * OpenID extension for MediaWiki