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) получить определённую авторизацию от пользователя (владельца ресурса);
 * 3) выполнять действия в MediaWiki от имени пользователя

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



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

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


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

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


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

Следующая информация взята из http://tools.ietf.org/html/draft-ietf-oauth-v2-22 и показывает общий рабочий процесс OAuth 2.

Терминология

 * Владелец ресурса: объект, способный предоставить доступ к защищенному ресурсу. Когда владельцем ресурса является человек, его называют конечным пользователем.
 * Сервер ресурсов(Resource Server): сервер, на котором размещены защищенные ресурсы, способный принимать и отвечать на запросы защищенных ресурсов с использованием маркеров доступа.
 * Клиент: приложение, запрашивающее защищенный ресурс от имени владельца ресурса и с его авторизацией.
 * Сервер авторизации: сервер, выдающий клиенту токены доступа после успешной аутентификации владельца ресурса и получения авторизации.

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

Права доступа
Права доступа ограничивают доступ к клиенту. Права по умолчанию должны быть «только для чтения». Каждое право на запись должно быть явно предоставлено владельцем ресурса.

Рекомендуемая степень детализации разрешений
В текущем предложении не учитывается конфигурация групп, которые должны иметь доступ к этим различным правам.

Рекомендации для сторонних приложений
Вот несколько начальных мыслей о рекомендациях для будущих сторонних разработчиков приложений. Пожалуйста, обсудите это на Странице обсуждения


 * Каждая транзакция, выполненная третьим приложением от имени зарегистрированного пользователя, должна быть напрямую связана с отдельным пользователем и именем пользователя.
 * Администраторы должны иметь право немедленно аннулировать доступ отдельного стороннего приложения.
 * Весь контент, созданный и измененный с помощью стороннего приложения, подпадает под действие лицензий Википедии и общих условий использования.
 * Страница пользовательских настроек будет содержать отдельный раздел, показывающий, какие сторонние приложения были авторизованы, и должна иметь возможность отзыва авторизации одним щелчком мыши.
 * OAuth должен быть настраиваемым в GlobalSettings.php
 * Сетевой трафик шифруется с помощью SSL между конечным пользователем и стороннем приложением.
 * Должен быть возможным откат всех действий по отдельному приложению.

Варианты использования
Наиболее очевидным вариантом использования является наличие (упрощенного) редактора, который позволяет редактировать вики-страницу. Такой редактор может быть проще, чем текущий редактор вики, он может быть более продвинутым или адаптирован для конкретных википроектов. Второй вариант использования - это может предложить независимую от платформы замену таких инструментов, как Twinkle, Huggle и (AWB). Третий вариант использования - это то, что он позволит нам быстро создавать прототипы новых функций, не требуя их развертывания в одном из проектов Википедии, чтобы провести более тщательные тесты.

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

 * Данные Википедии становятся еще более пригодными для повторного использования и доступными для целого нового круга людей.
 * Нет необходимости передавать свой пароль третьим лицам
 * Отменить любое разрешение без необходимости менять свой пароль и не нарушая работу других разрешений.

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

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

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

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


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

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

Критика
Аргумент: Одна проблема, которая была высказана ранее, заключается в том, что OAuth откроет шлюзы для новых людей, и, следовательно, мы увидим рост вандализма.

Ответ: OAuth не делает MediaWiki/Wikimedia более открытой, чем она есть. OAuth предлагает дополнительные меры предосторожности, включая регулирование на основе API, ограничение объема авторизации, а действия редакторов по-прежнему будут напрямую относиться к отдельному пользователю.

 Аргумент:  OAuth 2 требует, чтобы сервер авторизации работал по https, и большинство установленных Wiki (не WMF wiki) не поддерживают https.

Reply: Поддержка OAuth, безусловно, является более продвинутой функцией для платформы MediaWiki, но в наши дни получить сертификат SSL не очень дорого. Потенциальное злоупотребление предложением небезопасной реализации довольно велико, и кажется разумным придерживаться спецификации.

Баги OpenID и OAuth

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

Подходящие расширения

 * 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

Предыдущие дскуссии

 * 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