OAuth (obsolete info)/ru

OAuth предоставляет стандартный протокол для согласования маркеров безопасного доступа и предоставления сторонним инструментам (веб или клиенту) детального доступа к частным ресурсам. Этот протокол не раскрывает имена пользователей или пароли стороннему инструменту. Предложение авторизации на основе OAuth для вики-страниц MediaWiki повысит возможность повторного использования их данных и стимулирует создание экосистемы приложений вокруг MediaWiki. 

Обоснование
Существует последний рубеж, где Википедия и ее дочерние проекты не так открыты, как могли бы/должны быть: нечеловеческие взаимодействия. Инфраструктура Викимедиа предназначена для того, чтобы миллионы людей во всем мире могли свободно использовать ее содержимое, но ей не хватает средств, позволяющих сторонним службам легко «повторно использовать свои данные». Цель этого предложения - начать разработку функциональности OAuth в MediaWiki, чтобы упростить повторное использование содержимого Википедии и возглавить создание экосистемы новых сервисов и приложений на основе ее данных.

Прослушать Когда в этом документе упоминается OAuth, его следует читать как OAuth 2 draft 22 или выше. *Вероятно, самый большой вопрос сейчас заключается в том, должна ли эта функция идти в ядре или быть разработана как расширение. Пожалуйста, укажите на Странице Обсуждения.
 * Примечания
 * Это предложение направлено на расширение платформы MediaWiki, но многие примеры вдохновлены Википедией, чтобы сделать варианты использования более понятными.
 * В этом предложении предлагается не полная реализация спецификации OAuth 2, а реализация части кода авторизации.

Документы

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

Общая информация
У MediaWiki есть, обеспечивающий доступ для чтения/записи к своей базе данных. Это означает, что вы можете редактировать, изменять и взаимодействовать с содержимым MediaWiki без использования интерфейса MediaWiki. Однако, за редкими исключениями, доступ на запись на основе API используется только ботами.

Существование API вдохновляет на идею редактирования Wikimedia с помощью чего-то другого, чем MediaWiki. Можно использовать совершенно другой интерфейс, адаптированный к конкретным потребностям пользователя. Принятие MediaWiki API ограничено знающими разработчиками MediaWiki и опытными пользователями Wikipedia. Создание сторонних приложений вокруг текущего API затруднено тем фактом, что такие приложения должны будут хранить учетные данные пользователя. Поддерживая аутентификацию/авторизацию на основе OAuth, мы можем значительно расширить пользовательскую базу API и привлечь новых участников к проектам Wikimedia.

MediaWiki как сервер авторизации OAuth
Целью этого предложения является превращение MediaWiki в сервер авторизации OAuth: цель состоит в том, чтобы позволить клиентским приложениям: Внедрение функциональности OAuth-клиента в MediaWiki, т. е. предоставление пользователям MW доступа к другим готовым OAuth-сервисам - например, для аутентификации и взаимодействия с внешними сервисами, такими как Twitter, Facebook, LinkedIn - выходит за рамки текущего предложение.
 * 1) безопасно получать учетные данные пользователя в MediaWiki;
 * 2) obtain specific authorization from the user (the resource owner);
 * 3) выполнять действия в MediaWiki от имени пользователя

Псевдо-аутентификация OAuth
OpenID это популярный протокол, используемыйidentity providers. В то время как основное внимание OpenID уделяется аутентификации, OAuth в основном касается авторизации. MediaWiki имеет, который больше подходит для входа одного пользователя, но не подходит для предоставления детальной авторизации для различных частей API MediaWiki. OAuth предоставляет так называемый механизм псевдо-аутентификации, разница между OpenID и OAuth-аутентификацией обобщена ниже:



= Предложение =

Authorization flow
С точки зрения клиентского приложения рабочий процесс «Авторизация пользователя» состоит из примерно следующих шагов:


 * Пользователь посещает стороннее приложение X (к сторонним приложениям мы относим сторонние веб-сайты, сторонние мобильные приложения и сторонние настольные приложения).
 * Стороннее приложение X просит предоставить авторизацию от пользователя для определенного набора действий
 * Стороннее приложение X отправляет пользователя обратно в Wikimedia
 * Wikimedia запрашивает подтверждение того, что пользователь хочет авторизовать стороннее приложение X для предоставления определенного набора действий на данном наборе ресурсов и в течение заданного периода времени или на неопределенный срок
 * Wikimedia проверяет, есть ли у пользователя соответствующие права на уровне пользователя; если да, то пользователь подтверждает авторизацию, Wikimedia отправляет пользователя обратно в стороннее приложение X, в противном случае авторизация не проходит.

Рабочий процесс аутентификации пользователя будет состоять из следующих шагов:


 * 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
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.

Преимущества для пользователей

 * 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

Преимущества для Wikimedia

 * Создает основу для создания экосистемы приложений вокруг Wikimedia/MediaWiki. у
 * Предоставляет способ утверждать приложения и устанавливает обязательные правила относительно допустимого использования
 * Предоставляет возможность третьим сторонам 'делать правильные вещи' и не собирать пароли
 * Предоставляет способ идентифицировать действия в вики, выполненные третьими лицами, и легко остановить их в случае необходимости

Проектная документация
См. на Design Documentation

Минимальная версия MediaWiki
Расширение OAuth, вероятно, будет зависеть от следующих функций:


 * getAllRights, r34357, MediaWiki 1.13.0
 * getWgHooks, r6405, MediaWiki 1.4.0

Конфиденциальность и условия использования
Использование MW-OAuth в проектах Викимедиа потребует, чтобы данные, созданные любой клиентской службой, были доступны по открытым лицензиям сообществу Викимедиа и соблюдали условия конфиденциальности, установленные WMF.

Критика
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 и OAuth

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

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/
 * Extension:Facebook
 * Extension:TwitterLogin

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.

См. также

 * OAuth2 background
 * OAuth 2.0 and the Road to Hell
 * OAuth2 specification
 * OAuth2 UML sequence diagram
 * The Current State of OAuth 2
 * Decentralising Wikimedia
 * strategy:Proposal:Implement OAuth for MediaWiki (and employ in Wikimedia)
 * wm2011:Submissions/Opening up Wikipedia's data: A lightweight approach to Wikipedia as a platform
 * OpenID at Wikimedia
 * Request to support OpenID on Wikimedia
 * MediaWiki Authentication Using Twitter and OAuth
 * Account Chooser
 * Twitter description of OAuth
 * Differences between OpenID and OAuth