OAuth – авторизация сервисов на сервисах

У многих дорогих авто в комплекте есть специальный ключ, который вы можете дать парковщику. С этим ключом нельзя проехать больше нескольких километров, нельзя открыть багажник или посмотреть адресную книгу телефона в машине. Это замечательная идея.
Описание с сайта oauth.net
OAuth – стандарт для аутентификации и получения доступа одними сервисами к данным других. Эта идея не нова. Похожие системы существуют у многих крупных и не очень сервисов. Google AuthSub, AOL OpenAuth, BBAuth Yahoo, Facebook Auth. Но пока никто не создавал стандарт, который позволит существенно повысить взаимодействие между сервисами в сети.
4 декабря 2007 года была принята спецификация OAuth 1.0.
OAuth предназначен для предоставления пользователем доступа к своим данным на одном сервисе другому сервису. Если вы хотите дать некой социальной сети доступ к адресной книге вашего почтового сервиса чтобы он мог поискать ваших знакомых, вам не обязательно предоставлять свой логин и пароль для почты этому сервису. Ведь можно предоставить доступ только к адресной книге и ни к чему больше. Именно для таких целей OAuth и создаётся.
Принцип его работы достаточно простой (и он во многом повторяет принцип работы систем API, ссылки на которые даны выше). Если один сервис (клиент) хочет получить доступ к вашим данным на другом сервисе (сервере), поддерживающем OAuth, то он запрашивает у сервера ключ, перенаправляет вас на сервер чтобы вы разрешили доступ к данным (авторизировав полученный ключ) и далее с помощью авторизированного ключа может получить данные, которые он запрашивал, и запрос на которые вы подтвердили.
В принципе, после авторизации клиент может не только запрашивать ваши данные, но и изменять данные на сервере. Т.е. делать всё, что позволит ему пользователь и сервис, предоставляющий API.
Преимущество такого стандарта перед существующими API в том, что сервисам, которые хотят предоставлять свои данные по требованию, будет проще это API писать (т.к. существуют серверные библиотеки на разных языках), а сервисам, которые хотят данные получать, будет проще это сделать благодаря стандартизации процесса.
Стандарт не определяет сам процесс получения данных. Он определяет только процедуру авторизации. Остальное остаётся на усмотрение сервиса, предоставляющего данные. Также на его усмотрение он может потребовать различных механизмов проверки подлинности (подписи). Существуют рекомендованные механизмы (HMAC-SHA1, RSA-SHA1), но можно использовать и другие.
Список сервисов, поддерживающих OAuth, пока невелик. Обновлённую версию можно найти в вики.
Набор библиотек для OAuth внушительнее, чем список использующих его сервисов. Доступны библиотеки на PHP, Ruby, Python, Java, C# и Perl. Ссылки на них можно найти здесь: http://oauth.net/code/
У OAuth, как и OpenID, на мой взгляд, большое будущее. Стандартизация механизма обмена данными между сервисами требовалась уже давно.
Метки: OAuth, идентификация
декабря 10, 2007 at 11:54 пп
полезную работу делают, только зачем еще один стандарт :) ведь есть OpenID.
декабря 11, 2007 at 2:09 дп
OpenID для других целей…
У них даже есть отдельный раздел в about: “OAuth – не расширение OpenID” =)
декабря 11, 2007 at 8:04 пп
А какая организация приняла этот стандарт? Я не смог найти.
декабря 11, 2007 at 8:46 пп
Его приняла OAuth Working Group.
декабря 27, 2007 at 3:51 пп
# c0der Says:
# зачем еще один стандарт :) ведь есть OpenID.
В OpenID нет варианта авторизации одного сервиса на другом. Он только может авторизовать пользователя при участии браузера. В этом смысле OpenID “для другого”.
Однако, суть OpenID в том, что это ЕДИНЫЙ пароль. Кроме того, это узнаваемый брэнд, и идея в том что для любых нужд идентификации пользователю достаточно ввести url в поле рядом со знакомым серо-оранжевым значком.
Если для поста комментариев надо вводить в поле c пометкой OpenID, для автозаполнения анкеты – вводить тот же самый url в поле с пометкой Attribute Exchange, а для интеграции сервисов – в поле с пометкой oAuth, то пользователь запутается.
Поэтому, вообще, странно, почему они не оформили oAuth расширением OpenID. Было бы логично реализовать oAuth в рамках OpenID Attribute Exchange, появившегося в OpenID 2.0.