Механизм настройки для управления маркерами OAuth.

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

Использование OAuth

Как описано в разделе Основные сведения о маркерах OAuth, процесс аутентификации OAuth выполняется в три шага. Эти шаги описаны в следующих разделах.

Получение маркера запроса   Авторизация маркера запроса   Получение маркера доступа

Шаг 1. Получение маркера запроса

Для получения маркера запроса отправьте подписанный запрос наhttps://www.google.com/accounts/OAuthGetRequestToken. Включите в запрос следующие параметры. Обратите внимание на то, что необязательным параметром является только oauth_version; все остальные параметры обязательны.

Предусмотрены три способа задания этих параметров.

• Включение параметров в заголовок Authorization запросов GET или POST. Пример запроса, приведенный ниже, показывает, как задать эти значения в заголовке Authorization. Обратите внимание, что параметр scope не может быть задан в заголовке. Параметр "scope" можно указывать в виде параметра URL запроса или в теле запроса POST.

• Указание параметров в теле запроса POST. Если выбран этот метод, необходимо задать значение заголовка запросаContent-Type равным application/x-www-form-urlencoded.

• Включение параметров в URL запроса GET.

Дополнительные сведения см. в разделе Спецификация OAuth (раздел 5.2).

Пример запроса

В примере запрашивается маркер, необходимый для доступа к аккаунтам Календаря и Picasa пользователя.

POST /accounts/OAuthGetRequestToken HTTP/1.1

Host: https://www.google.com

Content-Type: application/x-www-form-urlencoded

Authorization: OAuth

oauth_consumer_key="example.com",

oauth_signature_method="RSA-SHA1",

oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",

oauth_timestamp="137131200",

oauth_nonce="4572616e48616d6d65724c61686176",

oauth_version="1.0"

scope=http://gdata.youtube.com

Об ответе

Если запрос выполнен успешно, то Google отвечает сообщением HTTP 200, которое содержит маркер запроса и секретную часть маркера. Приложению необходимо выполнить синтаксический анализ, выделив маркер из ответа.

Если не удалось успешно обработать запрос, то Google возвращает сообщение HTTP 400 (Запрос отклонен). Такой ответ может указывать на то, что запрос имеет неверный формат, в нем содержатся неподдерживаемые параметры, отсутствуют необходимые параметры, использован неподдерживаемый метод подписи или имеются какие-то другие ошибки в формате или содержании. Этот ответ может также указывать на то, что у Google есть основания полагать, что запрашивающий – злоумышленник.

В следующем примере показан успешный ответ на запрос маркера.

oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=ZXhhbXBsZS5jb20

Шаг 2. Авторизация маркера запроса

После получения маркера запроса перенаправьте пользователя наhttps://www.google.com/accounts/OAuthAuthorizeToken. Добавьте в URL следующие параметры запроса.

Пример запроса

В следующем примере показан запрос для авторизации маркера.

https://www.google.com/accounts/OAuthAuthorizeToken?oauth_token=ab3cd9j4ks73hf7g&oauth_callback=http%3A%2F%2Fwww.example.com

Об ответе

Если Google примет этот запрос, то пользователь будет перенаправлен на страницу входа в YouTube. После входа пользователя служба аутентификации отображает страницу, информирующую его о том, что приложению требуется доступ к аккаунту пользователя на YouTube. На странице запрашивается подтверждение пользователя на доступ приложения к его аккаунту.

Если пользователь предоставил приложению доступ, то он перенаправляется на URL обратного вызова, заданный в запросе на авторизацию маркера. Если пользователь запретил доступ, то он будет перенаправлен на страницу, содержащую ссылки на сайт и на YouTube.

Следующий URL показывает формат перенаправления на URL обратного вызова с авторизованным маркером запроса. Авторизованный маркер запроса имеет то же значение, что и неавторизованный маркер, отправленный в запросе. Значением является текстовая строка длиной до 256 байт.

http://www.example.com/ytapi.html?oauth_token=CKF50YzIHxCT85KMAg

Шаг 3. Обмен маркера запроса на маркер доступа

После авторизации маркера запроса пользователя приложение может обменять этот маркер на маркер доступа. Маркер доступа позволяет отправлять удостоверенные запросы к API YouTube от имени конкретного пользователя. Время действия маркеров доступа не ограничено, они работают как маркеры сеанса AuthSub.

Чтобы заменить авторизованный маркер запроса маркером доступа, отправьте подписанный запрос HTTP наhttps://www.google.com/accounts/OAuthGetAccessToken со следующими параметрами запроса. Обратите внимание, что все эти параметры, кроме oauth_token, также используются (в том же контексте) в запросах для получения маркера запроса. Единственным необязательным параметром является oauth_version, все остальные обязательны.

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

Пример запроса

Следующий пример меняет маркер запроса на маркер доступа.

POST /accounts/OAuthGetAccessToken HTTP/1.1

Host: https://www.google.com

Content-Type: application/x-www-form-urlencoded

Authorization: OAuth

oauth_consumer_key="example.com",

oauth_token="CKF50YzIHxCT85KMAg",

oauth_signature_method="RSA-SHA1",

oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",

oauth_timestamp="137131200",

oauth_nonce="4572616e48616d6d65724c61686176",

oauth_version="1.0"

Об ответе

Если запрос маркера доступа обработан успешно, то Google отвечает сообщением HTTP 200, которое содержит маркер доступа и секретную часть маркера. В следующем примере показан образец ответа, содержащего маркер доступа OAuth.

oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=ZXhhbXBsZS5jb20

Google может отклонить запрос маркера, если он имеет неверный формат или есть основания полагать, что запрашивающий – злоумышленник. В этом случае возвращается код ответа HTTP 400 ("Запрос отклонен").

Подписание запросов, использующих аутентификацию OAuth

Все запросы на получение или использование маркера OAuth должны быть подписаны. Это требование относится к вызовам для получения маркера запроса и маркера доступа, а также ко всем запросам к API данных YouTube, которые требуют аутентификации, например запросам на добавление видео или его рейтинга.

Следующие шаги описывают процедуру формирования подписи запросов, в которых используется аутентификация OAuth.

1. Параметр oauth_signature_method служит для указания алгоритма подписи запроса. Google поддерживает алгоритмы формирования подписи RSA-SHA1 и HMAC-SHA1.

2. Создайте подпись base string, состоящую из трех элементов запроса, разделенных амперсандами (&). Обратите внимание, что все имена параметров, а также их значения должны быть закодированы согласно спецификации OAuth (раздел 5.1).

   • Первый элемент определяет метод HTTP-запроса (GET, POST и т. д.).

   • Второй элемент задает базовый URL для этого запроса, который не должен включать параметры. Например, если URL запроса равен http://gdata.youtube.com/feeds/api/videos?q=football&orderby=published&v=2, то базовый URL будет равен http://gdata.youtube.com/feeds/api/videos.

   • Третий элемент содержит нормализованную строку параметра и его значения. Эта строка должна включать все параметры запроса, заданные в URL запроса, а также все параметры OAuth, кроме oauth_signature. Способ нормализации строки определяется спецификацией OAuth (раздел 9.1.1).

3. Создайте oauth_signature с использованием указанного oauth_signature_method.

   • Если используется алгоритм RSA-SHA1, то сформируйте подпись с помощью закрытого ключа, соответствующего сертификату, который был добавлен на Google во время регистрации.

   • Если используется алгоритм HMAC-SHA1, создайте подпись с использованием значения "consumer secret", сформированного во время регистрации. Это значение отображается на странице регистрации вашего домена.

В спецификации OAuth (приложение A.5) приведен пример запроса, который может быть использован для проверки подписи HMAC-SHA1. Пример включает базовую строку подписи и ключ HMAC-SHA1, а также сформированный дайджест (подпись) HMAC-SHA1.

Примечание. Дополнительную информацию о подписи запросов OAuth см. в спецификации OAuth (раздел 9).

Схема процесса

На следующем рисунке показаны шаги аутентификации пользователя по протоколу OAuth. Подобно аутентификации AuthSub и ClientLogin аутентификация OAuth может использоваться или с прямым добавлением, или с добавлением через браузер.

На этом рисунке показаны следующие шаги.

1. Пользователь щелкает ссылку на вашем сайте, чтобы выполнить операцию API, требующую аутентификации.

2. Ваше приложение проверяет наличие сохраненного маркера доступа OAuth для этого пользователя. Если маркер доступа имеется, ваше приложение переходит к шагу 14. Если маркер доступа отсутствует, ваше приложение переходит к шагу 3.

3. Ваше приложение передает подписанный запрос на получение маркера запроса службе аутентификации OAuth Google.

4. Google в ответ на запрос выдает неавторизованный маркер запроса, который приложение извлекает из ответа путем синтаксического анализа.

5. Ваше приложение перенаправляет пользователя к службе аутентификации аккаунтов YouTube. URL перенаправления определяет неавторизованный маркер запроса и URL обратного вызова.

6. Браузер пользователя выполняет переадресацию, посылая запрос службе аутентификации аккаунтов YouTube.

7. Служба аутентификации аккаунтов YouTube отображает страницу Подтверждение доступа, предлагая пользователю войти в свой аккаунт YouTube и разрешить либо запретить вашему приложению выполнять операции API для этого аккаунта.

8. Пользователь выполняет вход и разрешает аккаунту доступ к вашему приложению.

9. Если пользователь разрешает доступ, YouTube снова перенаправляет пользователя на URL обратного вызова, который был включен в URL на шаге 6. Пользователь может запретить аккаунту доступ, и в этом случае YouTube выведет страницу со ссылками для перехода обратно к вашему приложению и на веб-сайт YouTube.

10. Браузер пользователя обрабатывает перенаправление и отправляет запрос на ваш URL обратного вызова. URL перенаправления содержит значение авторизованного маркера запроса. (Значение авторизованного маркера запроса такое же, как у неавторизованного.)

11. Ваше приложение отправляет службе аутентификации OAuth YouTube подписанный запрос обмена маркера запроса на маркер доступа.

12. YouTube в ответ на запрос выдает маркер доступа.

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

14. Приложение отправляет запрос API с использованием маркера доступа для аутентификации запроса.

Социальные сети широко используются людьми по всему миру. Web-сайты, подобные Facebook и Twitter, становятся все более и более популярными, но, к сожалению, учитывая сложности взаимодействия между ними, эти Web-сайты похожи на изолированные острова, разбросанные в океане. Несмотря на то, что многие из этих сайтов предоставляют API для представления некоторых своих данных, агрегировать много таких Web-сайтов в для mashup-сайте непросто. Например, необходимо управлять пользовательскими учетными записями для различных Web-сайтов, поэтому для облегчения работы пользователей требуется в некотором роде единая регистрация (single sign-on). Пользователи не всегда охотно предоставляют свои пароли стороннему Web-сайту.

В данной серии статей описывается открытый протокол OAuth, позволяющий пользователям предоставлять свои частные данные различным Web-сайтам вместе со своими полномочиями, но показывать эти данные только исходному Web-сайту, где они хранятся. В этой первой статье дается введение в OAuth с примером настольного приложения, позволяющего пользователям обновлять свой Twitter-статус, используя OAuth. Во второй части данной серии статей будет рассказано, как разработать более практичное Web-приложение Twitter-клиента, использующее OAuth. В последней статье речь пойдет о том, как развернуть разработанное во второй части Web-приложение в среде Google App Engine (GAE).

Для работы с данной статьей необходимо иметь опыт Web-разработки с использованием технологии Java™ Servlet/JSP. В качестве Web-контейнера был выбран Apache Tomcat, а вся разработка проводится в среде Eclipse. Однако вы сможете адаптировать данную информацию для предпочитаемых вами инструментальных средств. Отметим, что для компилирования исходного кода необходим JDK 5+.

Введение в oAuth

Протокол OAuth позволяет пользователям предоставлять частные ресурсы, хранящиеся на Web-сайте, другим сайтам, не показывая информацию о полномочиях (например, имя пользователя и пароль) Web-сайтам, отличным от сайта, хранящего данные. Web-сайт, применяющий OAuth в качестве одного из своих протоколов аутентификации, улучшает защищенность и секретность для пользователей. В OAuth есть три ключевых игрока: пользователь (user), потребитель (consumer) и поставщик сервиса (service provider) (см. врезку). Типичный сценарий работы OAuth можно описать следующим образом (полное описание OAuth приведено в спецификации "OAuth Core 1.0a" и "Руководстве для начинающих", ссылки на которые приведены в разделе Ресурсы):

Ключевые игроки oAuth

• Пользователь: лицо, имеющее учетную запись у поставщика сервиса.

• Потребитель: Web-сайт или приложение, использующее OAuth для доступа к поставщику сервиса.

• Поставщик сервиса: Web-приложение, предоставляющее доступ через протокол OAuth.

Web-сайт PHOTO (поставщик сервиса) хранит некоторые частные фотографии пользователя (пользователь). Но этот сайт не предоставляет сервис печати. Поэтому, когда пользователь захочет распечатать свои фотографии, он может перейти на Web-сайт PRINTER (потребитель), предоставляющий сервис печати. Но Web-сайт PRINTER не имеет фотографий пользователя. Следовательно, должен существовать поток данных от сайта PHOTO к PRINTER. Вот здесь может помочь OAuth. Если сайт PHOTO позволяет выполнять аутентификацию с использованием OAuth, то при желании пользователя распечатать фотографии (хранящиеся на сайте PHOTO) сайт PRINTER направит его на сайт PHOTO для предоставления доступа к фотографиям. Здесь пользователь может быть аутентифицирован с использованием обычной пары имя-пароль. После аутентификации на сайте PHOTO пользователю может быть выдан запрос на разрешение доступа сайту PRINTER для чтения фотографий. (Это разрешение может быть установлено заранее, и этот шаг может пропускаться.) После этого пользователь будет направлен на сайт PRINTER. Теперь сайт PRINTER имеет разрешение на чтение пользовательских фотографий с сайта PHOTO и сможет распечатать их по требованию пользователя. На всех шагах сайт PRINTER не имеет информации о полномочиях пользователя, зарегистрированной на сайте PHOTO. Таким образом, частные данные пользователя защищаются лучше. На рисунке 1 продемонстрирован описанный выше процесс в виде упрощенной схемы последовательности действий.

Рисунок 1. OAuth-взаимодействия между пользователем, потребителем и поставщиком сервиса

(Подробное описание данного рисунка.)

Спецификация OAuth Core 1.0 была завершена в конце 2007 года. На время написания данной статьи последней версией является 1.0a, в которой исправлена проблема системы защиты, связанная с атаками фиксирования сессии в потоке подтверждения маркера запроса OAuth. Сегодня OAuth принят самыми крупными игроками на интернет-рынке, такими как Google и Yahoo.

Разработка настольного клиентского приложения для Twitter

Twitter, один из наиболее успешных примеров социальных сетей, привлек большое количество пользователей. Не только люди, но также и компании используют Twitter для быстрого обновления своего статуса. Например, IBM developerWorks использует Twitter для информирования людей о новостях сайта. Не удивительно, что Twitter поддерживает OAuth, поэтому я рассмотрю его в данной статье. Сначала я расскажу, как разработать простое клиентское приложение для Twitter, использующее OAuth. Если у вас еще нет учетной записи на Twitter, зарегистрируйтесь на сайте http://twitter.com и продолжите работу с данной статьей.

Регистрация настольного приложения на Twitter: MyTtDesktopClient

В настоящее время Twitter поддерживает два типа аутентификации: Basic Auth и OAuth. Хотя Basic Auth прост в использовании, имена пользователей и пароли не защищены во время передачи по протоколу HTTP, поэтому я не буду рассматривать его в данной статье. Чтобы иметь возможность использовать OAuth с Twitter, необходимо сначала зарегистрировать приложение наhttp://twitter.com/oauth_clients. Я зарегистрировал свое приложение со следующей информацией.

• Application Name (название приложения): MyTtDesktopClient.

• Description (описание): настольное клиентское приложение для Twitter, использующее OAuth.

• Application Website (Web-сайт приложения): введите домашнюю страницу вашего приложения.

• Application Type (тип приложения): Client – мы собираемся разработать настольное клиентское приложение.

• Default Access type (тип доступа по умолчанию): Read & Write (чтение и запись) – мы хотим предоставлять пользователям доступ по записи.

• Use Twitter for login (использовать ли Twitter для регистрации): No (нет) – мы не собираемся использовать Twitter для аутентификации.

Отмечу, что необходимо выбрать тип приложения Client, а не Browser. (Во второй части данной серии статей я рассмотрю пример Web-приложения.) Также не забудьте указать доступ Read & Write, в противном случае ваше приложение сможет только читать данные с Twitter.

После успешной регистрации вы получите ключ потребителя (consumer key), секретную информацию (consumer secret) и три URL-адреса (URL маркера запроса (request token), URL маркера доступа (access token) и URL авторизации). Теперь все готово для реальной работы.

Разработка и тестирование MyTtDesktopClient

Я буду использовать Twitter4J, Java-библиотеку для TwitterAPI с открытыми исходными кодами (см. раздел Ресурсы). Twitter4J охватывает много функций, поэтому мы можем сосредоточиться на логике, не касаясь низкоуровневых API-вызовов к Twitter. Дополнительным преимуществом Twitter4J является то, что она поддерживает OAuth, что значительно облегчает нашу работу. Давайте начнем с метода updateStatus(String status) класса myttdesktopclient.OAuthTwitterClient, приведенного в листинге 1. Исходный код доступен по ссылке, приведенной в разделе Загрузка. Не забудьте поместить ваши ключ и секретную информацию (эти параметры были предоставлены вам после регистрации клиентского приложения на Twitter) вOAuthTwitterClient.java.

Листинг 1. Метод updateStatus(String status) класса myttdesktopclient.OAuthTwitterClient

public void updateStatus(String status) throws TwitterException, IOException {

Twitter twitter = new Twitter();

twitter.setOAuthConsumer(consumerKey, consumerSecret);

RequestToken requestToken = twitter.getOAuthRequestToken();

AccessToken accessToken = null;

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

while (accessToken == null) {

System.out.println("Open the following URL and grant access to

your account:");

System.out.println(requestToken.getAuthorizationURL());

// Скопируйте URL авторизации в ваш браузер

// http://twitter.com/oauth/authorize?oauth_token=xxxxxxxxxxxxxxxxxxxxxxxx

// Войдите в Twitter, предоставьте доступ

// Получите PIN, например 738805

// Отметим, что вы можете использовать HttpClient для этого

System.out.println("Copy the PIN displayed in your browser, then

hit ENTER: ");

String pin = br.readLine();

accessToken = twitter.getOAuthAccessToken(requestToken, pin);

}

// Запомнить маркер запроса для последующей ссылки

int userId = twitter.verifyCredentials().getId();

storeAccessToken(userId, accessToken);

Status twitterStatus = twitter.updateStatus(status);

System.out.println("Successfully updated the status for user with ID "

+ userId + " to [" + twitterStatus.getText() + "].");

}

Метод updateStatus(String status) сначала создает объект Twitter, затем устанавливает ключ и секретную информацию. После этого из Twitter извлекается маркер запроса. Затем метод выводит URL для авторизации пользователя с целью предоставления доступа к данным, хранящимся на Twitter. Теперь скопируйте и поместите URL-адрес, выданный кодом, в браузер и нажмите клавишуEnter; появится запрос авторизации от MyTtDesktopClient (см. рисунок 2). Отмечу, что мы собираемся авторизоваться на сайте Twitter, и наше настольное приложение не знает о том, как это происходит.

Рисунок 2. Предоставление доступа к MyTtDesktopClient

При авторизации запроса Twitter возвращает PIN, как показано на рисунке 3.

Рисунок 3. Twitter возвращает PIN в MyTtDesktopClient

Теперь скопируйте и поместите этот PIN в окно терминала, в котором работает ваш код, и нажмите клавишу Enter. Вы должны увидеть информацию, аналогичную приведенной в листинге 2. Как видно из листинга 1, настольное клиентское приложение интересуется только выходными данными процесса авторизации. Если он успешен (в данном случае Twitter возвращает PIN), предоставляется маркер доступа, благодаря которому клиентское приложение может обновить свой Twitter-статус от имени пользователя. Это ключевой момент OAuth. Секретные данные о пользователе (имя и пароль) приложению MyTtDesktopClient. не предоставляются. Если вы зарегистрируетесь в Twitter, то увидите последнее обновление "Studying OAuth" (см. рисунок 4). Отмечу, что сообщение ниже последнего статуса указывает на то, что он был обновлен приложением MyTtDesktopClient.

Листинг 2. Выходная информация MyTtDesktopClient

Open the following URL and grant access to your account:

http://twitter.com/oauth/authorize?oauth_token=matzsp0Q8k5GfhX2DQoQaHEipBH3g3ieqzPg5QyYek

Copy the PIN displayed in your browser, then hit ENTER:

1944867

Storing access token for 23741179...Done

Successfully updated the status for user with ID 23741179 to [Studying OAuth].

Рисунок 4. Статус Twitter обновлен приложением MyTtDesktopClient

Отмечу, что в листинге 1 перед обновлением статуса Twitter маркер доступа сохраняется путем вызова метода storeAccessToken. Причина этого заключается в том, что в настоящее время маркер доступа от Twitter не имеет даты истечения срока годности. Следовательно, нет необходимости получать доступ снова при повторном использовании нашего клиентского приложения пользователем. Это улучшает процесс работы с пользователем. В данном примере маркер доступа сохраняется в обычном текстовом файле (plain text) для пользователя. Его можно извлекать для последующего использования. Взгляните на методыstoreAccessToken и loadAccessToken в исходном коде (см. ссылку в разделе Загрузка). Новый метод обновленияupdateStatus(int userId, String status) использует сохраненный маркер доступа (см. листинг 3). В методе mainзакомментируйте строку tt.updateStatus("Studying OAuth"); и удалите символы комментирования в строкеtt.updateStatus(23741179, "Studying OAuth again");. Замените число 23741179 вашим собственным Twitter ID. Повторно скомпилируйте и запустите код. Статус Twitter обновится без процесса авторизации.

Листинг 3. Метод updateStatus(int userId, String status) класса myttdesktopclient.OAuthTwitterClient

public void updateStatus(int userId, String status)

throws TwitterException, IOException {

Twitter twitter = new Twitter();

twitter.setOAuthConsumer(consumerKey, consumerSecret);

AccessToken accessToken = loadAccessToken(userId);

twitter.setOAuthAccessToken(accessToken);

Status twitterStatus = twitter.updateStatus(status);

System.out.println("Successfully updated the status for user with ID "

+ userId + " to [" + twitterStatus.getText() + "].");

}

Резюме

В этой первой статье серии я представил протокол OAuth. На примере приложения MyTtDesktopClient мы познакомились с основными принципами использования OAuth. Особенностью здесь является то, что данные о пользовательских полномочиях, хранящиеся у поставщика сервисов (имя пользователя и пароль в Twitter), не предоставляются потребителю - приложениюMyTtDesktopClient. Во второй части данной серии я продемонстрирую, как разработать более практичное Web-приложение, позволяющее пользователям взаимодействовать с Twitter по протоколу OAuth.

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

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

Вернемся в 2005-й год и представим, что мы пишем социальную сеть. В ней имеется форма импорта контактов из адресной книги GMail. Что нужно для доступа к контактам GMail? Конечно, логин и пароль от ящика. Но если мы попросим ввести их на нашем сайте, пользователь заподозрит неладное. Где гарантия, что мы не сохраняем на сервере введенные пароли? Поэтому нам хочется, чтобы пароль вводился только на сайте GMail, и после этого доступ к контактам через API GMail предоставлялся нашей социальной сети (возможно, на время).

Договоримся о терминах.

• 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 отличается от OpenId?

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 и приведем исходники скрипта.

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

Хороший способ понять что-то — сделать это самому, наступив попутно на все разложенные грабли. Сейчас мы будем изобретать велосипед: попробуем представить, как бы мы решали задачу взаимодействия Consumer-а и Service Provider-а без всяких стандартизированных протоколов.

Во-первых, напишем саму форму импорта контактов с GMail:

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

Итак, после ввода пароля пользователь будет возвращаться к нам на сайт по следующему адресу:

А мы из скрипта /import.php обратимся к API GMail, передадим в него ключ Y49xdN0Zo2B5v0RR и загрузим контакты:

Ну что же, давайте теперь считать грабли (потому что шишки считать будет уже поздно).

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

Ну конечно же, вы догадались, что злоумышленник на своем сайте первым делом разместит ссылку

и заставит вас на нее кликнуть. В результате он получит секретный ключ, который вернул GMail, а значит, и ваши контакты:

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

Предположим, мы как-то защитили retpath, и он теперь может указывать только на наш сайт. Но проблема с параметром secret остается.

Secret можно подсмотреть из-за спины или перехватить методом прослушивания WiFi-трафика. Или на вашем сайте когда-нибудь найдется XSS-уязвимость, позволяющая "утянуть" секретный ключ. Имея значение secret, злоумышленник сможет прочитать вашу адресную книгу. Значит, нужно обезопасить secret от перехвата (в идеале — вообще его не передавать через URL).

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

Если для каждого вызова API требуется разный secret, то нам придется организовывать столько редиректов на сайт Service Provider-а, сколько у нас вызовов. При интенсивном использовании API это работает очень медленно, да и неудобно порядком...

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

GMail, конечно, хочет знать, кто пользуется его API. Разрешить доступ одним сайтам и запретить — другим... Значит, при формировании запроса в форме импорта контактов Consumer (сайт) должен "представляться" Service Provider-у (GMail-у). В нашем случае эту функцию частично выполняет retpath (имя сайта в нем), но данный способ не универсален, т.к. механизм "представления" должен быть задействован еще и при вызове API-методов. 

Фундамент oAuth

Примечательно, что "подводных граблей" осталось еще много. Я не буду их здесь описывать, потому что эти грабли лежат в Марианской впадине (глубоко, 10920 м). На описание уязвимостей пришлось бы потратить с десяток страниц. Так что я сразу перейду к описанию OAuth, где все проблемы уже решены.

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

При работе с OAuth важно, что термин Consumer не ограничивается смыслом "сайт". Consumer — это некоторое приложение, а уж где оно размещено, не так важно. Примеры Consumer-ов из реальной жизни:

• Скрипт формы импорта контактов из GMail (см. пример выше).

• Приложение для iPhone, позволяющее писать сообщения в Twitter.

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

Но из одного OAuth каши не сваришь. Действительно, все, что дает OAuth, — это возможность авторизоваться на удаленном сервисе (Service Provider) и делать автризованные запросы к API. Не важно, как устроен этот API: это может быть чистый SOAP, REST-подход т. д. Главное, чтобы каждый метод API принимал на вход специальные параметры, передаваемые согласно протоколу OAuth.

Token = Key + Secret

Один из принципов OAuth гласит, что никакие секретные ключи не должны передаваться в запросах открытыми (выше в примере мы рассматривали, почему). Поэтому протокол оперирует понятием Token. Токен очень похож на пару логин + пароль: логин — открытая информация, а пароль — известен только передающей и принимающей стороне. В терминах OAuth аналог логина называется Key, а аналог пароля — Secret. Ситуация, когда Secret известен только отправителю и получателю, но более никому, называется Shared Secret.

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

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

"Цифровая подпись" — звучит страшно, но на самом деле это достаточно очевидная вещь. Когда вы ручкой подписываетесь на каком-либо документе, вы удостоверяете, что этот документ написан вами, а не кем-то другим. Ваша подпись как бы "добавляется" к документу и идет с ним в "одном комплекте".

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

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

1. Consumer добавляет цифровую подпись к сообщению, в общем виде —

2. $transfer = $message . "-" . md5($message . $sharedSecret);

// $transfer = "Мой телефон 1234567" . "-" . md5("Мой телефон 1234567" . "529AeGWg")

3. Service Provider принимает данные, разбивает их обратно на 2 части — $message и $signature — и проделывает точно такую же операцию:

4. $signatureToMatch = md5($message . $sharedSecret);

// $signatureToMatch = md5("Мой телефон 1234567" . "529AeGWg");

Дальше остается только сравнить получившееся значение $signatureToMatch с тем, что было в полученных данных $signature и рапортовать о подделке, если значения не совпали.

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

Чтобы "вживую пощупать" 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 в скрипте на значения, полученные от сервера.

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

Поговорим о том, откуда появляются приложения и как Service Provider о них узнает. Все достаточно просто: Service Provider имеет специальную форму регистрации приложений, которой может воспользоваться любой желающий. Вот пример такой формы:

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

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

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

В примере с GMail мы использовали 2 вида удаленных вызовов: а) редирект через браузер; б) обращение к API изнутри скрипта.

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

1. Обработка отправки формы. Это не часть OAuth, а часть нашего приложения. Прежде чем обращаться к API Provider-а, мы должны получить от пользователя заказ-наряд на это действие. Вот пример такого "заказа":

   скопировать код в буфер обмена Листинг 9: Обработка отправки формы

   // 1. Запрошена отправка формы. Определяем, с какого шага начинать: // либо с OAuth, либо с отправки сообщения через API. case 'form_is_sent': { // Сохраняем сообщение в сессию, оно нам понадобится позже. $S_MSG = $_POST['msg']; if ($S_ACCESS_TOK && $S_ACCESS_TOK->secret) { // Пользователь уже отправлял комментарии в текущей сессии. $action = 'send_msg'; } else { // Авторизация еще не проведена, запускаем процедуру OAuth. $action = 'fetch_request_token'; } break; }

2. Fetch Request Token (внутренний запрос).

   • Скрипт Consumer-а обращается к Request token URL Provider-а: например, http://api.rutvit.ru/oauth/request_token. В запросе передается Consumer key — "логин приложения", а сам запрос подписывается при помощи Consumer secret — "пароля приложения", что защищает его от подделки.

   • В ответ Provider генерирует и возвращает "заполненный мусором" токен, который называется Request Token. Он нам еще пригодится, поэтому мы должны сохранить его где-нибудь — например, в сессионной переменной $S_REQUEST_TOK.

     скопировать код в буфер обмена Листинг 10: Fetch Request Token

     // 2. Запрошено получение Request Token. // Обращаемся к Service Provider через сокет и получаем токен. case 'fetch_request_token': { // Формируем запрос на получение Request Token. $consumer = new OAuthConsumer(OA_CONSUMER_KEY, OA_CONSUMER_SECRET); $req = OAuthRequest::from_consumer_and_token( $consumer, NULL, "GET", "http://api.rutvit.ru/oauth/request_token" ); // Добавляем в запрос цифровую подпись, чтобы не подделали. $req->sign_request(new OAuthSignatureMethod_HMAC_SHA1(), $consumer, NULL); // Получаем Request Token и отправляем его на авторизацию. $parsed = OAuthUtil::parse_parameters(file_get_contents($req->to_url())); $S_REQUEST_TOK = new OAuthToken($parsed['oauth_token'], $parsed['oauth_token_secret']); // Переходим к следующему состоянию. $action = 'authorize_request_token'; break; }

3. Redirect to Authorization (через редирект в браузере). Теперь у нашего приложения есть уникальный Request Token. Требуется получить у пользователя разрешение на использование этого токена, т.е. попросить егоавторизовать Request Token.

   • Consumer редиректит браузера на специальный Authorize URL Provider-а: например, http://api.rutvit.ru/oauth/authorize. В параметрах передается Request Token Key.

   • Provider выводит форму авторизации для своего пользователя и, если он авторизовался, редиректит браузер назад. Куда именно? А мы указываем это в параметре oauth_callback.

     скопировать код в буфер обмена Листинг 11: Redirect to Authorization

     // 3. Авторизация (подтверждение пользователем) Request Token's через редирект. // Переадресуем браузер на Service Provider для продтверждения доступа пользователем. // При возврате обратно в GET-параметрах будет action=fetch_access_token. case 'authorize_request_token': { // На этот URL вернется браузер после подтверждения. $callbackUrl = "http://{$_SERVER['HTTP_HOST']}{$_SERVER['SCRIPT_NAME']}" . "?action=fetch_access_token"; // Передаем callback-URL в параметрах (протокол OAuth 1.0; в 1.0a - уже не так!). $authUrl = "http://api.rutvit.ru/oauth/authorize" . "?" . "&oauth_token={$S_REQUEST_TOK->key}" . "&oauth_callback=" . urlencode($callbackUrl); // Браузерный редирект. header("Location: $authUrl"); exit(); }

4. Fetch Access Token (внутренний запрос). Итак, браузер вернулся в наше приложение после серии редиректов. Это значит, что авторизация на Provider-е прошла успешно, и Request Token разрешен к работе. Однако в OAuth для безопасности каждый токен имеет свое собственное, строго ограниченное назначение. Например, Request Token используется только для получения подтверждения от пользователя, и больше ни для чего. Для доступа к ресурсам нам нужно получить новый токен — Access Token — или, как говорят, "обменять Request Token на Access Token".

   • Consumer обращается к Access token URL — например, http://api.rutvit.ru/oauth/access_token, — и просит выдать ему Access Token взамен имеющегося у него Request Token-а. Запрос подписывается цифровой подписью на основе Request Token secret.

   • Provider генерирует и возвращает Access Token, заполненный "мусором". Он также помечает в своих таблицах, что для этого Access Token-а разрешен доступ к API. Наше приложение должно сохранить у себя Access Token, если оно собирается использовать API в дальнейшем.

     скопировать код в буфер обмена Листинг 12: Fetch Access Token

     // 4. Обмен Request Token на Access Token и запись Access Token в сессию. // Сюда вернулись из редиректа после подтверждения доступа пользователем. case 'fetch_access_token': { $consumer = new OAuthConsumer(OA_CONSUMER_KEY, OA_CONSUMER_SECRET); $req = OAuthRequest::from_consumer_and_token( $consumer, $S_REQUEST_TOK, "GET", "http://api.rutvit.ru/oauth/access_token", array() // доп. параметры ); $req->sign_request(new OAuthSignatureMethod_HMAC_SHA1(), $consumer, $S_REQUEST_TOK); // Выполняем запрос и записываем Access Token в сессию. $parsed = OAuthUtil::parse_parameters(file_get_contents($req->to_url())); $S_ACCESS_TOK = new OAuthToken($parsed['oauth_token'], $parsed['oauth_token_secret']); // Переход к отправке сообщения. $action = 'send_msg'; break; }

5. Call API (внутренний запрос). Ну что же, теперь у нас есть Access Token, и мы можем передавать его key при вызове методов API.

   • Consumer генерирует запрос к API Provider-а (например, используя POST-запрос согласно REST-идеологии). В запросе передается Access Token Key, а подписывается он при помощи Shared Secret этого токена.

   • Provider обрабатывает API-вызов и возвращает данные приложению.

скопировать код в буфер обмена Листинг 13: Call API

// 5. Отправляем сообщение. // Оборачиваем URL API в OAuth-контейнер. case 'send_msg': { $consumer = new OAuthConsumer(OA_CONSUMER_KEY, OA_CONSUMER_SECRET); $req = OAuthRequest::from_consumer_and_token( $consumer, $S_ACCESS_TOK, 'POST', 'http://api.rutvit.ru/statuses/update.xml', array('status' => "#" . TAG . " " . iconv(ENCODING, "UTF-8", $S_MSG)) ); $req->sign_request(new OAuthSignatureMethod_HMAC_SHA1(), $consumer, $S_ACCESS_TOK); // Отправляем POST-запрос. $h = curl_init(); curl_setopt($h, CURLOPT_URL, $req->get_normalized_http_url()); curl_setopt($h, CURLOPT_POST, true); curl_setopt($h, CURLOPT_RETURNTRANSFER, true); curl_setopt($h, CURLOPT_POSTFIELDS, $req->to_postdata()); $resp = curl_exec($h); $code = curl_getinfo($h, CURLINFO_HTTP_CODE); // При успехе - редирект обратно на страницу с виджетом. if ($code != 200) { e($resp); exit(); } header("Location: {$_SERVER['SCRIPT_NAME']}"); exit(); }

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

Окончание скрипта должно быть понятно и без подробных разъяснений.

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

• Официальный сайт OAuth.

• OAuth.php by Andy Smith.

• Реализация протокола OAuth на всевозможных языках программирования.

• Beginner's Guide to OAuth: статья про OAuth на английском, очень рекомендую к прочтению.

• Оригинал этой статьи на dklab.ru

См. также:

• http://rutvit.ru/apps/new: регистрация приложения на OAuth-сервере РуТвита.

• Полный исходный код примеров этой статьи.

Сингапурский студент открыл «новую» уязвимость в OAuth

Спустя месяц после обнаружения уязвимости Heartbleed в библиотеке OpenSSL, другой открытый протокол оказался подверженным атаке. На этот раз дыры были найдены в популярном инструменте OAuth, который используется для идентификации пользователей множеством популярных сайтов и компаний, включая Google, Facebook, Microsoft и LinkedIn. ЦП разобрался в том, насколько это опасно.

• 35

— редакция ЦП тестирует кнопки UpToLike

Студент из Сингапура по имени Ван Цзин обнаружил, что используя небольшую брешь в безопасности сайтов, использующих протокол OAuth для авторизации пользователей, можно получить доступ к личным данным пользователя. Он назвал этот метод взлома Covert Redirect («Тайное перенаправление»). Например, если пользователь нажмёт на фишинговую ссылку, то получит стандартное окно авторизации Facebook с просьбой разрешить подключение приложения. После авторизации доступа, пользователь будет перенаправлен на страницу злоумышленника, который таким образом сможет получить доступ к данным пользователя на Facebook.

Логотип уязвимости, предложенный Ваном

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

Ван Цзин рассказывает, что поставил в известность представителей Facebook: там ему сказали, что компания «осознаёт риски, связанные с OAuth 2.0», но «ошибка не может быть исправлена в краткосрочной перспективе». Также Ван обратился в Google, LinkedIn и Microsoft. В компании Google объяснили, что осведомлены о проблеме, а в LinkedIn 13 марта 2014 года даже опубликовали целый пост об этом. В Microsoft провели расследование и заявили, что уязвимость существует на доменах третьих сторон, а не на их собственных.

Список сайтов, которые, по мнению Ван Цзина, могут быть подвержены уязвимости

Исправить это не так просто. Если все сторонние приложения будут строго использовать «белый список», то атаки станут невозможными. В действительности, однако, большое число сторонних приложений не делают этого по разным причинам. Это делает системы, основанные на OAuth 2.0, крайне уязвимыми.

— Ван Цзин

Издание CNET сообщает, что сотрудники LinkedIn и PayPal в разное время публиковали официальные заявления об этой или похожей уязвимости.

Демонстрация работы Covert Redirect

После того, как информация о Covert Redirect начала распространяться по сети, многие издания поспешно окрестили уязвимость «новым Heartbleed». Другие СМИ и компании поспешили успокоить взволнованных представителей IT-индустрии, утверждая, что несколько преждевременно поднимать шум по этому поводу.

Представители Symantec пишут, что некорректно называть это «уязвимостью», Covert Redirect — брешь в безопасности. В отличие от Heartbleed, который позволяет напрямую воздействовать на сервер, в случае с Covert Redirect злоумышленнику требуется использовать поддающееся атаке приложение (которых не так много), а также убедить пользователя вступить во взаимодействие. В этом посте на примере связки Facebook и приложения ESPN подробно описывается, как именно хакер может перехватить токен пользователя, изменив параметр redirect_uri. Чтобы избежать такого, разработчику нужно убрать со своего сайта открытые переадресации и занести проверенные адреса в «белый список».

Крупные издания (например, Mashable и ZDNet) утверждают, что на данный момент не имеет смысла раздувать скандал по поводу Covert Redirect. В частности, Кристина Уоррен пишет на Mashable, что Covert Redirect раскручивают «как по учебнику», используя красивый сайт и даже логотип, а в действительности это не является новым открытием и не несёт такой опасности, как Heartbleed. Об этом (или очень похожем) методесообщалось ещё в феврале 2013 года, но широкую огласку он получает только сейчас.

Специалист по безопасности Егор Хомяков объясняет, что ничего страшного в этом нет:

Для начала, это известный баг Facebook Connect, другие провайдеры не подвержены уязвимости (автор утверждает, что подвержены), потому что Connect позволяет вам подменить значения параметров response_type и redirect_uri.

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