OAuth ВКонтакте: использования в корыстных целях. Как это работает? Пример использования маркера доступа

Популярный протокол, который позволяет социальным сервисам интегрироваться между собой и дает безопасный способ обмена персональной информацией. OAuth может связать между собой 2 сервиса, каждый из которых имеет свою пользовательскую базу - именно их я в данном случае называю «социальными». Когда начинаешь работать с OAuth, первое ощущение - что протокол весьма сложен и избыточен. В этой статье я попытаюсь объяснить основы OAuth человеческим языком.

Пример кросс-авторизации

• Consumer : потребитель; скрипт обработки формы импорта контактов в социальной сети.
• Service Provider : поставщик данных; GMail, содержащий в себе данные адресной книги, интересные для Consumer-а.
• User : пользователь, имеющий аккаунт как у Consumer-а, так и у Service Provider-а.
• Protected Resource : личные данные; контакты из адресной книги на GMail (т.е. ресурсы Service Provider-а).
• Provider API : API GMail, позволяющий любому скрипту получить контакты из адресной книги GMail.

Чем OAuth отличается от OpenID?

1. OpenID - протокол для ускоренной регистрации. OpenID позволяет пользователю без ввода пароля получить аккаунт на каком-либо сервисе, если он уже зарегистрирован где-то еще в интернете. (И потом можно без ввода пароля входить на сервис, будучи авторизованным «где-то».) Например, если у вас есть аккаунт на Яндексе, вы сможете «входить» с его помощью на любой сервис, поддерживающий OpenID-авторизацию.
2. OAuth - протокол для авторизованного доступа к стороннему API. OAuth позволяет скрипту Consumer-а получить ограниченный API-доступ к данным стороннего Service Provider-а, если User дает добро. Т.е. это средство для доступа к API.

План этой статьи

1. Рассмотрим проблемы, которые возникают при «ручной» реализации кросс-авторизации.
2. Поговорим о том, что такое «приложение» и кто такой Consumer.
3. Коснемся основ криптографии.
4. Обозначим демо-приложение, которое мы будем писать в этой статье.
5. Определимся с тестовым сервером OAuth, на котором будем экспериментировать.
6. Пройдем по всем шагам протокола OAuth и приведем исходники скрипта.

Об изобретении велосипедов

Во-первых, напишем саму форму импорта контактов с GMail:Далее попросим разработчиков GMail сделать так, чтобы при переходе пользователя по URI /auth.php ему бы выдавалась форма авторизации (в нашем веломире GMail написан на PHP). После успешного ввода пароля пользователь должен редиректиться на сайт, чей URL указан в параметре retpath. Также дополнительно в URL должен передаваться некоторый секретный ключ, который уже можно использовать для доступа к API GMail.

Итак, после ввода пароля пользователь будет возвращаться к нам на сайт по следующему адресу:А мы из скрипта /import.php обратимся к API GMail, передадим в него ключ Y49xdN0Zo2B5v0RR и загрузим контакты:Ну что же, давайте теперь считать грабли (потому что шишки считать будет уже поздно).

Грабли первые: подмена адреса возврата retpath

Грабли вторые: «подслушивание» секретного ключа

Грабли третьи: слишком много редиректов

Грабли четвертые: плохая идентификация Consumer-а

Фундамент OAuth

Приложение = Consumer + доступ к API

Token = Key + Secret

Итак, если Consumer и Provider каким-то образом договорятся между собой о Shared Secret, они могут открыто обмениваться в URL соответствующими ключами (Key), не опасаясь, что перехват этих ключей будет опасен. Но как защитить URL с Key от подделки?

Сообщение = Документ + Цифровая подпись

Аналогично, цифровая подпись добавляется к некоторому блоку данных, удостоверяя: тот, кто сформировал эти данные, не выдает себя за другого. Цифровая подпись не шифрует документ, она лишь гарантирует его подлинность! Поставить подпись позволяет тот самый Shared Secret, который известен получателю и отправителю, но более никому.

Как это работает? Пусть наш $sharedSecret = 529AeGWg, и мы сообщили его шепотом на ухо принимающей стороне. Мы хотим передать сообщение «Мой телефон 1234567» с гарантированной защитой от фальсификации злоумышленником.

1. Consumer добавляет цифровую подпись к сообщению, в общем виде - $transfer = $message . "-" . md5($message . $sharedSecret); // $transfer = "Мой телефон 1234567" . "-" . md5("Мой телефон 1234567" . "529AeGWg")
2. Service Provider принимает данные, разбивает их обратно на 2 части - $message и $signature - и проделывает точно такую же операцию: $signatureToMatch = md5($message . $sharedSecret); // $signatureToMatch = md5("Мой телефон 1234567" . "529AeGWg"); Дальше остается только сравнить получившееся значение $signatureToMatch с тем, что было в полученных данных $signature и рапортовать о подделке, если значения не совпали.

Демонстрация работы OAuth на примере простого приложения

1. Скрипт, реализующий клиентскую часть протокола. Я написал как раз такой небольшой PHP-скрипт (ссылка на zip-архив). Это виджет, который можно вставлять на PHP-сайты.
2. Тестовый сервер OAuth, на котором мы сможем экспериментировать. Для этой цели удобно использовать РуТвит: там есть страница http://rutvit.ru/apps/new , которая позволяет добавить тестовое приложение за 30 секунд. (Кстати, URL возврата в форме можно не указывать - мы все равно передаем его из тестового скрипта.)

Вы можете вставить данный виджет на любой PHP-сайт, просто скопировав его код и подправив верстку. Выводятся все твиты с сервиса РуТвит , помеченные указанным хэш-тэгом, а также имеется возможность добавлять новые твиты (тут-то как раз и задействуется OAuth). Виджет использует API и OAuth-авторизацию РуТвита, которые, кстати говоря, совпадают со стандартом API Twitter-а.Вы можете запустить этот скрипт на своем тестовом сервере. Для этого нужно выполнить три действия:

1. Скачайте код скрипта и разверните его в любую удобную директорию на веб-сервере.
2. Зарегистрируйте новое тестовое приложение на OAuth-сервере.
3. После регистрации приложения замените параметры OA_CONSUMER_KEY и OA_CONSUMER_SECRET в скрипте на значения, полученные от сервера.

Регистрация приложения и его параметры

После регистрации приложения вам выдается 5 параметров, которые требуются для работы с OAuth. Вот как они могут выглядеть:

Здесь Consumer key и Consumer secret - это своеобразные «логин + пароль» вашего приложения (помните выше разговор о токенах? это как раз один из них). Напомню, что Consumer secret - это Shared Secret, известный только отправителю и получателю, но никому больше. Остальные 3 значения задают служебные URL, смысл которых мы сейчас рассмотрим.

OAuth = Fetch Request Token + Redirect to Authorization + Fetch Access Token + Call API

И мы вскрыли ряд проблем с безопасностью, что наводит на мысль: вызовов должно быть больше. Так и происходит в OAuth: добавляются еще промежуточные запросы от скрипта Consumer-а к Provider-у, оперирующие токенами. Давайте их рассмотрим.

1. Обработка отправки формы. Это не часть OAuth, а часть нашего приложения. Прежде чем обращаться к API Provider-а, мы должны получить от пользователя заказ-наряд на это действие. Вот пример такого «заказа»:
2. Fetch Request Token (внутренний запрос).
   • Скрипт Consumer-а обращается к Request token URL Provider-а: например, api.rutvit.ru/oauth/request_token . В запросе передается Consumer key - «логин приложения», а сам запрос подписывается при помощи Consumer secret - «пароля приложения», что защищает его от подделки.
   • В ответ Provider генерирует и возвращает «заполненный мусором» токен, который называется Request Token. Он нам еще пригодится, поэтому мы должны сохранить его где-нибудь - например, в сессионной переменной $S_REQUEST_TOK.
3. Redirect to Authorization (через редирект в браузере). Теперь у нашего приложения есть уникальный Request Token. Требуется получить у пользователя разрешение на использование этого токена, т.е. попросить его авторизовать Request Token .
   • Consumer редиректит браузера на специальный Authorize URL Provider-а: например, api.rutvit.ru/oauth/authorize . В параметрах передается Request Token Key.
   • Provider выводит форму авторизации для своего пользователя и, если он авторизовался, редиректит браузер назад. Куда именно? А мы указываем это в параметре oauth_callback.
4. Fetch Access Token (внутренний запрос). Итак, браузер вернулся в наше приложение после серии редиректов. Это значит, что авторизация на Provider-е прошла успешно, и Request Token разрешен к работе. Однако в OAuth для безопасности каждый токен имеет свое собственное, строго ограниченное назначение. Например, Request Token используется только для получения подтверждения от пользователя, и больше ни для чего. Для доступа к ресурсам нам нужно получить новый токен - Access Token - или, как говорят, «обменять Request Token на Access Token».
   • Consumer обращается к Access token URL - например, api.rutvit.ru/oauth/access_token , - и просит выдать ему Access Token взамен имеющегося у него Request Token-а. Запрос подписывается цифровой подписью на основе Request Token secret.
   • Provider генерирует и возвращает Access Token, заполненный «мусором». Он также помечает в своих таблицах, что для этого Access Token-а разрешен доступ к API. Наше приложение должно сохранить у себя Access Token, если оно собирается использовать API в дальнейшем.
5. Call API (внутренний запрос). Ну что же, теперь у нас есть Access Token, и мы можем передавать его key при вызове методов API.
   • Consumer генерирует запрос к API Provider-а (например, используя POST-запрос согласно REST-идеологии). В запросе передается Access Token Key, а подписывается он при помощи Shared Secret этого токена.
   • Provider обрабатывает API-вызов и возвращает данные приложению.

Конец скрипта: вывод виджета

Полезные ссылки по OAuth

• rutvit

Шаг 1. Регистрация сайта

Переходим по ссылке http://api.mail.ru/sites/my/add и регистрируем наш сайт. Далее скачиваем и заливаем на ftp файл receiver.html, который нужен для верификации нашего сайта.
После регистрации нам выдадут 3 параметра:

• Приватный ключ
• Секретный ключ

Нас будет интересовать только ID и Секретный ключ (Приватный ключ нужен для модели клиент-сервер). Сохраним их в конфигурационном файле нашего скрипта под следующими именами.

$APP_ID; $APP_SECRET;

Шаг 2. Получение Code

Для получения Code нужно обратиться по адресу connect.mail.ru/oauth/authorize , передав ему $_GET параметры:

• client_id - ID сайта
• response_type - 3 варианта на выбор. token - доступ к API будет предоставлен только через javascript, code_and_token - доступ к API через сервер и javascript, code - доступ к API через сервер. В нашем случае это будет code .
• redirect_uri - Адрес страницы получения response_type
• scope - Привилегии приложения. Параметр необязателен для заполнения и в нашем случае избыточен. Если вы решили запросить привилегии, то учтите, что далеко не все пользователи захотят передать вам их приватные данные, поэтому просто для авторизации параметр scope использовать не надо.

Для удобства разделим логику генерации ссылки на получение code и его обработки:
example.com/login.php - генерируем ссылку для получения code (по-сути ссылка для авторизации).
example.com/auth.php - обработка code.

Итоговый запрос будет выглядеть так:

$redirect_uri = urlencode("http://example.com/auth.php"); $login_url = "https://connect.mail.ru/oauth/authorize?client_id={$APP_ID}&response_type=code&redirect_uri={$redirect_uri}";

Перейдя по этому адресу неавторизованный на Mail.ru пользователь увидит:

Если пользователь авторизован на Mail.ru, то он увидит такое же окно, но без ввода логина и пароля.
Теперь у пользователя 2 варианта действий: разрешить и запретить. Запретив, пользователь будет перенаправлен на страницу указанную в redirect_uri с указанием ошибки.

Если всё прошло как надо и пользователь разрешил сайту доступ к своим данным, то пользователь будет перенаправлен на страницу redirect_uri (http://example.com/auth.php), с $_GET параметром code.
Сохраним его под именем

$APP_CODE;

Шаг 3. Получение token и uid

Для этого надо обратиться по адресу connect.mail.ru/oauth/token , передав ему параметры:

• client_id ($APP_ID)
• client_secret ($APP_SECRET)
• grant_type (authorization_code)
• code ($APP_CODE)
• redirect_uri ($redirect_uri из шага 2)

Все параметры обязательтны. redirect_uri должен точно совпадать с тем, который мы использовали на 2-ом шаге.

Запрос на получения token может быть выполнен только через POST запрос, поэтому cURL в помощь:

$ch = curl_init(); $url = "https://connect.mail.ru/oauth/token"; $fields = Array("client_id" => $APP_ID, "client_secret" => $APP_SECRET, "grant_type" => "authorization_code", "code" => $APP_CODE, "redirect_uri" => urlencode(redirect_uri)); foreach($fields as $key => $value){ $fields_string .= $key . "=" . $value . "&"; } rtrim($fields_string, "&"); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $fields_string); $result = curl_exec($ch); curl_close($ch); $arr = json_decode($result, true); //или $arr = (array) json_decode($result). Кстати кто-нибудь знает, есть ли разница? $token = $arr["access_token"]; $uid = $arr["x_mailru_vid"];

Шаг 4. Получаем пользовательские данные

После получения token и uid сайт получает долгожданный доступ к API Mail.ru по адресу www.appsmail.ru/platform/api .
Но не всё так просто, каждый запрос к API должен быть подписан. Подпись (в нашем случае) представляет собой хэш, рассчитанный по алгоритму md5 из отсортированной в алфавитном порядке строки из передаваемых API параметров без разделителя & и Секретного ключа .
Например:

Md5("app_id=423004method=friends.getsession_key=be6ef89965d58e56decdfacb9b62bdaa" . $APP_SECRET);

Mail.ru предусматривает 2 варианта подписи: клиент-сервер и сервер-сервер. Отличие заключается в большей безопасности 2-го подхода. Его мы и будем использовать. Для этого в запросе к API надо указывать secure=1 .

Выполним запрос на получение анкетной информации пользователя Mail.ru, воспользовавшись методом users.getInfo .

$request_params = Array("app_id" => $APP_ID, "uids" => $uid, "method" => "users.getInfo", "secure" => 1, "session_key" => $token); //Параметры обязательно должны быть отсортированы в алфавитном порядке ksort($request_params); $params = ""; foreach ($request_params as $key => $value) { $params .= "$key=$value"; } //В модели сервер-сервер подпись выглядит так $sig = md5($params . $APP_SECRET); //Формируем запрос $url = "http://www.appsmail.ru/platform/api?method=users.getInfo&app_id={$APP_ID}&session_key={$token}&sig={$sig}&uids={$uid}&secure=1"; $response = file_get_contents($url); $info = (array) json_decode($response); $info = $info; //весь результат print_r($info);

Вот и всё. Таким образом мы получили необходимые нам данные для занесения пользователя в базу данных. Весь дальнейший процесс уже неоднократно был описан, например . Так что не вижу смысла его описывать.

PROFIT!!1 Всем добра. Если статья окажется интересной, то могу так же разобрать процесс серверной oAuth 2.0 авторизации для Vkontakte и Facebook.

Если вы пользуетесь Почтой Mail.Ru - можете не бояться за безопасность своих данных. Благодаря OAuth   — авторизации .

В этой статье мы хотим рассказать всю правду об этой технологии и о том, почему это важно.

Что такое протокол OAuth ?

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

Почему использовать сборщик писем в Почте Mail.Ru безопасно?

Обычно при настройке сборщика нужно вводить имя, адрес ящика и пароль. Чтобы обеспечить защищенную передачу ваших данных, Почта Mail.Ru давно использует шифрование этих данных с помощью протоколов SSL . А чтобы избавить от необходимости передачи паролей, мы реализовали сбор писем с использованием OAuth . Этот протокол позволяет программе не запрашивать и не хранить логины и пароли .

Как это работает?

Допустим вы решили настроить сборщик писем с почты Яндекса в вашем почтовом ящике Mail.Ru. Благодаря протоколу OAuth Почта Mail.Ru не будет запрашивать ваш логин и пароль от почты Яндекс, а будет запрашивать только право на доступ .

Просто нажмите «Добавить ящик» и Почта получит доступ до тех пор, пока он не будет вами отозван.

Но мы о вашем пароле не узнаем.

Полезный совет!

И напоследок, если вы решили настроить сборщик писем с вашего ящика Mail.Ru на стороннем почтовом сервисе – убедитесь, что в нем используется протокол OAuth . Если нет, мы не рекомендуем вам рисковать безопасностью своих данных.

Надеемся, что эта статья была полезной для вас. Если у вас возникли вопросы - задавайте в комментариях.

1. Открытие встроенного браузера со страницей авторизации
2. У пользователя запрашивается подтверждение выдачи прав
3. В случае согласия пользователя, браузер редиректится на страницу-заглушку во фрагменте (после #) URL которой добавляется access token
4. Приложение перехватывает редирект и получает access token из адреса страницы

Пример

После того, как пользователь выдаст права, происходит редирект на стандартную страницу-заглушку, для Mail.Ru это connect.mail.ru/oauth/success.html :
< HTTP/1.1 302 Found < Location: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer& expires_in=86400&refresh_token=yaeFa0gu

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

Авторизация по логину и паролю

Пример

Восстановление предыдущей авторизации

Пример

Во время создания приложения потребуется указать redirect_uri, который будет использован во время авторизации OAuth.

https://connect.ok.ru/oauth/authorize?client_id ={clientId}&scope ={scope}&response_type ={{response_type}}&redirect_uri ={redirectUri}&layout ={layout}&state ={state}

2. Разрешение прав доступа

Если пользователь ранее выдал приложению все права, указанные в параметре scope, то окно автоматически закрывается и дополнительное подтверждение от пользователя не требуется.

После перехода по сформированному URL пользователь будет должен ввести свой логин и пароль, если ранее он этого не сделал. После входа на сайт ему будет предложено авторизовать приложение и подтвердить запрошенные права:

3. Получение code

После подтверждения авторизации пользователь будет перенаправлен на указанный при открытии диалога авторизации redirect_uri, в GET-параметрах которого будет передан ключ доступа code, а также state в случае, если он был указан на этапе 1:

{redirect_uri}?code ={code}&state ={state}

Полученный параметр code действителен в течение 2 минут.

{redirect_uri}#error ={error}&state ={state}

4. Получение access_token

Для получения access_token необходимо совершить POST-запрос с сервера вашего сайта к API на URL:

code ={code}&client_id ={client_id}&client_secret ={client_secret}&redirect_uri ={redirect_uri}&grant_type ={grant_type}

В ответе от сервера приходит json, содержащий запрошенный access_token или информацию об ошибке.

Вид ответа в случае успеха:

• access_token – токен доступа, используемый для формирования запроса к API;
• token_type – на данный момент возвращается только session;
• refresh_token – токен обновления, который можно использовать в дальнейшем для упрощённой процедуры авторизации. Действителен в течение 30 суток;
• expires_in – время действия токена доступа в секундах.

Вид ответа в случае ошибки

• error – код ошибки;
• error_description – описание ошибки.

5. Использование refresh_token Имея токен обновления refresh_token, можно получить access_token по упрощённой процедуре, сделав один POST-запрос на URL:

https://api.ok.ru/oauth/token.do?refresh_token ={refresh_token}&client_id ={client_id}&client_secret ={client_secret}&grant_type ={grant_type}

Формат ответа аналогичен получению access_token, но без refresh_token.

Возможные ошибки