OAuth
•Для решения проблемы распределённой авторизации в 2007-2010 годах был разработан протокол OAuth (RFC 5849)
•Протокол рассчитан на широкий класс программ – десктопные программы, браузеры, мобильные приложения
•Типичный пример – сервер адресных книг синхронизирующий контакты в телефоне, на GoogleMail, на mail.ru и т.д.
•Логика работы OAuth не привязана к HTTP, но в RFC описана только такая реализация
Терминология-1
• В процессе авторизации OAuth участвуют три (и более) стороны:
Пользователь – владелец ресурса; Сервер – поставщик услуги; Клиент – потребитель услуги
• Например: Фотохостинг – сервер;
Сервис печати фотографий – клиент; Владелец учётной записи на фотохостинге – пользователь
Терминология-2
•В процессе авторизации OAuth стороны представляются временными именами – токенами, достоверность которых подтверждается соответствующими секретами.
•Используются три вида токенов и соответствующих секретов:
Токен клиента – выдаётся при регистрации клиента на сервере (идентифицирует клиента, не даёт никаких прав);
Токен запроса – временный токен, который используется для идентификации сеанса пользователя при запросе доступа;
Токен доступа – подтверждает текущие права клиента на доступ к API сервера
•Как правило, токены и секреты – длинные случайные уникальные строки
Терминология
Consumer: потребитель; скрипт обработки формы импорта контактов в социальной сети.
Service Provider: поставщик данных; GMail, содержащий в себе данные адресной книги, интересные для Consumer-а.
User: пользователь, имеющий аккаунт как у Consumer-а, так и у Service Provider-а.
Protected Resource: личные данные; контакты из адресной книги на GMail (т.е. ресурсы Service Provider-а).
Provider API: API GMail, позволяющий любому скрипту получить контакты из адресной книги GMail.
Задача OAuth — сделать так, чтобы User имел возможность работать на сервисе Consumer (в соцсети) с защищенными данными Service Provider-а (GMail), вводя пароль к этим данным исключительно на Service Provider-e и оставаясь при этом на сайте Consumer-а. Не так уж и сложно, верно?
Наглядный пример
•Пример из руководства по OAuth c сайта http://hueniverse.com
•В примере участвуют :
Jane – девушка, вернувшаяся из турпоездки Faji – сервис хранения туристических фотографий
Beppa – сервис фотопечати
•Предполагается, что Beppa для интеграции Faji получила от последнего токен и секрет клиента
Jane имеет пароль на Faji
Jane имеет пароль на Beppa, Beppa имеет токен от Faji
Клиент в фоне получает от сервера временный токен
Браузер Jane направляют на Faji, добавив в параметры временный токен
