13-10-2023
OAuth — открытый протокол авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищенным ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль. Например, пользователь, который хочет предоставить сервису социальной сети доступ к книге контактов своего почтового аккаунта, не должен сообщать сети свой пароль от почты. Вместо этого он проходит авторизацию непосредственно в почтовом сервисе, который (с разрешения пользователя или администратора сервиса) предоставляет сервису социальной сети полномочия доступа к адресной книге.
Содержание |
OAuth возник в ноябре 2006 года, когда Блейн Кук (англ. Blaine Cook) разрабатывал реализацию протокола OpenID для сервиса микроблогов Twitter.[1] Совместно с Крисом Мессиной (англ. Chris Messina) он искал путь использовать OpenID для доступа к Twitter API без предоставления сервису пароля. В сотрудничестве с одним из создателей OpenID Девидом Рекордоном (англ. David Recordon) они провели анализ функциональности OpenID, а также проприетарных протоколов авторизации, таких как Flickr Auth, Google AuthSub и Yahoo! BBAuth, после чего пришли к заключению, что существует необходимость в новом открытом протоколе. В апреле 2007 года образовалась группа инженеров, работавших над его созданием. В её работе приняли участие сотрудники компаний Google и AOL (которая в это же время представила свой собственный протокол OpenAuth). Финальная версия ядра протокола OAuth 1.0 была представлена 4 декабря 2007 года. В 2008 году проводилась работа по стандартизации протокола в Инженерном совете Интернета.
15 апреля 2009 года Twitter предложил своим пользователям решение, позволяющее делегировать третьесторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Sign-in with Twitter» и было основано на OAuth. Это событие стало поводом для первого широкого исследования протокола на уязвимости, и через несколько дней был обнаружен потенциальный эксплоит, затрагивающий все существующие реализации OAuth. После этого, 23 апреля сообществом разработчиков было выпущено первое дополнение безопасности к протоколу, которое вошло в обновленную спецификацию OAuth Core 1.0 Revision A, опубликованную 24 июня. В апреле 2010 года был выпущен информационный документ RFC 5849[2], посвященный стандарту OAuth.
В 2010 году началась работа над совершенно новой версией протокола OAuth 2.0[3], которая не будет обратно совместимой с OAuth 1.0. Предпосылок для создания OAuth 2.0 было несколько. В первую очередь, OAuth достаточно нетривиально использовать на клиентской стороне. Одна из поставленных целей при разработке нового OAuth — упростить разработку клиентских приложений. Во-вторых, несмотря на заявленную в стандарте реализацию трех методов (называемых потоками — flows) получения токена (уникального идентификатора) для авторизации: для веб-приложений, настольных клиентов и мобильных клиентов, фактически все три способа слиты в один. И, в-третьих, протокол оказался плохо масштабируемым. В него планируется добавить[4]:
Стоит отметить, что, хотя стандарт OAuth 2.0 ещё не утвержден, он уже используется некоторыми сервисами. Например, Graph API социальной сети Facebook поддерживает только OAuth 2.0.
Существует ошибочное мнение, что OAuth является расширением протокола OpenID. На самом деле это не так. Хотя OpenID и OAuth имеют много общего, последний является самостоятельным протоколом, никак не связанным с OpenID.
OAuth является протоколом авторизации, который позволяет предоставить права на использование какого-то ресурса (например, API какого-либо сервиса). Наличие прав определяется токеном (уникальным идентификатором), который может быть одним и тем же для разных пользователей, или же у одного пользователя в разное время могут быть разные токены. Предоставление прав происходит в обмен на предоставление токена. В общем случае нельзя определить, кому принадлежит токен и кто в настоящий момент пользуется правами.
OpenID является средством аутентификации: с помощью этой системы можно удостовериться, что пользователь — именно тот, за кого себя выдает. Какие действия сможет совершать пользователь, прошедший аутентификацию посредством OpenID, определяется стороной, проводящей аутентификацию.
Поясним работу протокола OAuth на примере[2]. Допустим, что пользователь (владелец ресурсов) хочет распечатать свои фотографии (ресурсы), загруженные на сайт «photos.example.net» (сервер), при помощи сервиса печати «printer.example.net» (клиент).
Данный пример описывает поток с кодом подтверждения (Authorization Code Flow). Помимо этого в стандарте OAuth 2.0 описаны следующие потоки:
OAuth поддерживает два метода аутентификации сообщений от клиента: HMAC-SHA1 и RSA-SHA1. Есть возможность передавать сообщения без подписи, тогда в поле типа подписи указывается «plain text». Но в этом случае, согласно спецификации, соединение между клиентом и сервером должно устанавливаться через протокол SSL или TLS.
Протоколы аутентификации и обмена ключами | |
---|---|
С симметричными алгоритмами | |
С симметричными и асимметричными алгоритмами | |
Протоколы и сервисы, используемые в Internet |
OAuth • OpenID • Windows Live ID |
OAuth.