OAuth - безопасный протокол кросс-авторизации веб

OAuth - безопасный протокол
кросс-авторизации веб-сайтов
Игумнов А.С.
Веб-сервисы - 1 этап
• Доступ к документам (возможно ,
создаваемым динамически)
HTTP, HTML
Веб-сервисы - 2 этап
• HTML+JS – стандарт для разработки
пользовательского интерфейса
• HTTP – способ вызова удалённых
процедур
HTTP, HTML,
JavaScript
URL – как способ передачи
параметров
http://parallel.uran.ru/news/2011/08/?user=u&p=1
Сервис
Позиционные
параметры
Имя
процедуры
SESSION
Переменнные
состояния
Именованные
параметры
COOKIE
Веб-сервисы - 3 этап
• XML, JSON – формализация форматов
данных
• SOAP, OpenID, OAuth – протоколы для
распределённых приложений
HTTP, XML
Современная ситуация
Редирект
Аутентификация
OpenID
Сервер аутенификации
www.auth.com
Авторизация
OAuth
Сервер приложений
Сервер данных
www.company.com
www.data.com
Аутентификация
• Целью аутентификации является присвоение
пользователю некоего уникального имени
• Классическая схема – запрос данных в
локальной базе или каталоге AD
• Современная схема – протокол OpenID,
позволяющий пользователю на любом
сервисе использовать имя (URI),
зарегистрированное на любом другом
сервисе
Авторизация
• Целью авторизации является
ограничение доступа к API сервера
• В децентрализованной среде
классическая авторизация затруднена
• Клиентом может выступать сервиспосредник
• Пароли (и имена) пользователя на
клиенте и сервере могут отличаться
Проблемы доверия
• Пользователь должен уметь делегировать
свои полномочия на одном сервисе другому
сервису (например, сервер приложений
должен получить доступ к серверу данных)
• При этом, пользователь хочет
контролировать объём делегируемых
полномочий и не хочет сообщать серверу
приложений свой пароль на сервере данных
OAuth
• Для решения проблемы распределённой
авторизации в 2007-2010 годах был
разработан протокол OAuth (RFC 5849)
• Протокол рассчитан на широкий класс
программ – десктопные программы,
браузеры, мобильные приложения
• Типичный пример – сервер адресных книг
синхронизирующий контакты в телефоне, на
GoogleMail, на mail.ru и т.д.
• Логика работы OAuth не привязана к HTTP, но
в RFC описана только такая реализация
Терминология-1
• В процессе авторизации OAuth участвуют три
(и более) стороны:
Пользователь – владелец ресурса;
Сервер – поставщик услуги;
Клиент – потребитель услуги
• Например:
Фотохостинг – сервер;
Сервис печати фотографий – клиент;
Владелец учётной записи на фотохостинге пользователь
Терминология-2
• В процессе авторизации OAuth стороны
представляются временными именами – токенами,
достоверность которых подтверждается
соответствующими секретами.
• Используются три вида токенов и соответствующих
секретов:
Токен клиента – выдаётся при регистрации клиента
на сервере (идентифицирует клиента, не даёт
никаких прав);
Токен запроса – временный токен, который
используется для идентификации сеанса
пользователя при запросе доступа;
Токен доступа – подтверждает текущие права
клиента на доступ к API сервера
• Как правило, токены и секреты – длинные случайные
уникальные строки
Наглядный пример
• Пример из руководства по OAuth c сайта
http://hueniverse.com
• В примере участвуют :
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
Ссылки
• http://hueniverse.com/oauth/ - популярное
изложение протокола (англ.)
• http://dklab.ru/chicken/nablas/57.html пример применения в PHP (рус.)
• http://rutwit.ru/apps/new - общедоступный
интерфейс регистрации приложений на
сервере rutwit.ru