OAuth - безопасный протокол кросс-авторизации веб-сайтов Игумнов А.С.

Веб-сервисы - 1 этап Доступ к документам (возможно, создаваемым динамически) HTTP, HTML

Веб-сервисы - 2 этап HTML+JS – стандарт для разработки пользовательского интерфейса HTTP – способ вызова удалённых процедур HTTP, HTML, JavaScript

URL – как способ передачи параметров Сервис Имя процедуры Позиционные параметры Именованные параметры SESSIONCOOKIE Переменнные состояния

Веб-сервисы - 3 этап XML, JSON – формализация форматов данных SOAP, OpenID, OAuth – протоколы для распределённых приложений HTTP, XML

Современная ситуация Сервер аутенификации Сервер приложений Сервер данных Редирект Аутентификация OpenID Авторизация OAuth

Аутентификация Целью аутентификации является присвоение пользователю некоего уникального имени Классическая схема – запрос данных в локальной базе или каталоге AD Современная схема – протокол OpenID, позволяющий пользователю на любом сервисе использовать имя (URI), зарегистрированное на любом другом сервисе

Авторизация Целью авторизации является ограничение доступа к API сервера В децентрализованной среде классическая авторизация затруднена Клиентом может выступать сервис- посредник Пароли (и имена) пользователя на клиенте и сервере могут отличаться

Проблемы доверия Пользователь должен уметь делегировать свои полномочия на одном сервисе другому сервису (например, сервер приложений должен получить доступ к серверу данных) При этом, пользователь хочет контролировать объём делегируемых полномочий и не хочет сообщать серверу приложений свой пароль на сервере данных

OAuth Для решения проблемы распределённой авторизации в годах был разработан протокол OAuth (RFC 5849) Протокол рассчитан на широкий класс программ – десктопные программы, браузеры, мобильные приложения Типичный пример – сервер адресных книг синхронизирующий контакты в телефоне, на Googl , на mail.ru и т.д. Логика работы OAuth не привязана к HTTP, но в RFC описана только такая реализация

Терминология-1 В процессе авторизации OAuth участвуют три (и более) стороны: Пользователь – владелец ресурса; Сервер – поставщик услуги; Клиент – потребитель услуги Например: Фотохостинг – сервер; Сервис печати фотографий – клиент; Владелец учётной записи на фотохостинге - пользователь

Терминология-2 В процессе авторизации OAuth стороны представляются временными именами – токенами, достоверность которых подтверждается соответствующими секретами. Используются три вида токенов и соответствующих секретов: Токен клиента – выдаётся при регистрации клиента на сервере (идентифицирует клиента, не даёт никаких прав); Токен запроса – временный токен, который используется для идентификации сеанса пользователя при запросе доступа; Токен доступа – подтверждает текущие права клиента на доступ к API сервера Как правило, токены и секреты – длинные случайные уникальные строки

Наглядный пример Пример из руководства по OAuth c сайта В примере участвуют : Jane – девушка, вернувшаяся из турпоездки Faji – сервис хранения туристических фотографий Beppa – сервис фотопечати Предполагается, что Beppa для интеграции Faji получила от последнего токен и секрет клиента

Jane имеет пароль на Faji

Jane имеет пароль на Beppa, Beppa имеет токен от Faji

Клиент в фоне получает от сервера временный токен

Браузер Jane направляют на Faji, добавив в параметры временный токен

На основе данных токена Jane информируют, кому и какие права она временно передаёт

Jane с её временным токеном возвращают на Beppa

Beppa в фоне обращается к Faji и, если авторизация прошла успешно, меняет временный токен на токен доступа, и с его помощью извлекает данные

Страница Jane обновляется, на ней отображаются доступные для печати снимки

Криптография В протоколе OAuth приняты меры по обеспечению криптографической надёжности, однако авторы рекомендуют передавать каждую конкретную реализацию на анализ экспертам. Реальные имена и пароли по сети не передаются. Передаваемые данные подписываются либо симметричным ключом (HMAC) либо несимметричным (RSA) Для предотвращения атак типа запись-повтор, используется внедрение в подпись даты и/или уникального идентификатора запроса.

Другие проблемы с безопасностью Токен и секрет, хранящиеся на сервере, достаточно защищены, однако в случае взлома сервера могут быть использованы злоумышленниками Токен и секрет, встроенные в приложение, тиражируются вместе с приложением и ненадёжны по определению Сервис может делить выдаваемые токены по уровням доверия и ограничивать доступ к API для ненадёжных клиентов.

Заключение Протокол неплохо обкатан и используется в Google и Twitter Использование криптографии делает его достаточно устойчивым к взлому Есть библиотеки для разных языков, в том числе для perl, php, python Если хочется разработать собственное API для удалённого персонифицированного доступа к сервису – стоит вспомнить про OAuth

Ссылки - популярное изложение протокола (англ.) - пример применения в PHP (рус.) - общедоступный интерфейс регистрации приложений на сервере rutwit.ruhttp://rutwit.ru/apps/new