Что такое oauth авторизация. Настройка клиентской библиотеки. Отличие OAuth от OpenID

​Заботясь о своих клиентах, команда сервиса Invola реализовала прямое подключение к почте по технологии OAuth 2.0.

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

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

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

Что такое OAuth?

Если говорить сухим техническим языком, то это протокол авторизации, позволяющий выдать одному сервису (в данном случае Invola) права на доступ к ресурсам пользователя на другом сервисе (доступ к почте).

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

Говоря проще, можно сказать так: сервис Invola подключается к вашей почте для получения счетов и коммерческих предложений, при этом не требуя логин и пароль, а запрашивая право на доступ. Если вы подтверждаете – приложение получает доступ до тех пор, пока он не будет отозван самим пользователем, либо пока приложение вообще существует и активно.

В коммуникации между Invola и почтовым сервером используется токен доступа access token (шаг 4-5), который автоматически устаревает через час и обновляется по необходимости (автоматически, без участия пользователя, программным обеспечением Invola).

Теперь поговорим о безопасности, и почему авторизация по OAuth предпочтительнее, чем по логину-паролю .

Когда вы предоставляете любому сервису логин и пароль для доступа к аккаунту (mail.ru, gmail.com), вы фактически предоставляете пароль от всей учетной записи (таким образом можно получить доступ, например, к диску, фотоальбомам и другим личным данным).

Предоставляя доступ через OAuth вы сами выбираете, к каким ресурсам аккаунта вы даете доступ . То есть, пользователь сам контролирует к каким ресурсам он готов дать доступ. Рассмотрим пример запрашиваемых прав при подключении к Invola:

"Просмотр и управление почтой " - для автоматического получения счетов и КП, "просмотр адреса " – для получения e-mail ящика, "просмотр профиля " – для получения имени пользователя (требуется на этапе регистрации).

К сожалению, не все почтовые сервера (включая корпоративные) поддерживают авторизацию по технологии OAuth , в частности популярный сервис Яндекс.Почта. Если у вас почта находится на яндексе, подключиться к нашему сервису в данный момент можно только используя логин-пароль.

Немного о безопасности .

Мы очень хорошо понимаем, насколько критичным для бизнеса является утечка конфиденциальных данных или несанкционированный доступ к данным о клиентах, финансовых операциях, личной переписке. Безопасность данных – один из главных приоритетов нашей работы .

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

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

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

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

Шаг 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.

OAuth 2 – это протокол авторизации, который предоставляет приложениям ограниченный HTTP-доступ к учетным записям пользователей. Он передаёт аутентификацию пользователей сервису, на котором размещены учетные записи, и авторизует сторонние приложения и передаёт им доступ к учетной записи пользователя. OAuth 2 обеспечивает авторизацию веб-приложений и мобильных устройств.

Данное руководство ознакомит вас с ролями OAuth 2, типами авторизации, с потоками и случаями использования OAuth 2.

Роли OAuth

В OAuth существует четыре роли:

1. Владелец ресурса
2. Клиент
3. Сервер ресурсов
4. Сервер авторизации

Рассмотрим каждую роль подробнее.

Владелец ресурса: пользователь

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

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

Сервер ресурсов и авторизации: API

Сервер ресурсов хранит защищенные учетные записи пользователей, а сервер авторизации проверяет учётные данные пользователя, а затем выдает токены доступа к приложению.

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

Клиент: приложение

Клиент – это приложение, которое хочет получить доступ к аккаунту пользователя. Прежде чем оно сможет сделать это, пользователь должен авторизоваться в приложении, а API должен подтвердить авторизацию.

Потоки протокола

Роли OAuth взаимодействуют между собой следующим образом:

• Приложение запрашивает авторизацию пользователя, чтобы получить доступ к сервисным ресурсам.
• Если пользователь по запросу приложения прошел авторизацию, приложение получает полномочия.
• Приложение запрашивает токен доступа от сервера авторизации (API).
• Если приложение проходит проверку подлинности и его полномочия действительны, сервер авторизации (API) выдает ему токен доступа. Авторизация завершена.
• Приложение запрашивает ресурс с сервера ресурсов (API) и предоставляет токен доступа для проверки подлинности.
• Если токен доступа действителен, сервер ресурсов (API) обслуживает ресурсы для приложения.

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

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

• Название приложения;
• Сайт приложения;
• URL обратного вызова или URI переадресации (сюда сервис будет перенаправлять пользователя после того, как он прошел (или не прошел) авторизацию; эта часть приложения будет обрабатывать коды авторизации или токены доступа).

ID и секретный ключ клиента

После регистрации приложения сервис предоставит вам учётные данные приложения, которые можно найти в поле client identifier и client secret. Client ID – это общедоступная строка, которая используется API сервиса для определения приложения; также с её помощью создаются URL-ы авторизации. Client Secret позволяет API сервиса подтвердить подлинность приложения, когда оно запрашивает доступ к аккаунту пользователя. Эти конфиденциальные данные хранятся между приложением и API.

Полномочия авторизации

Полномочия авторизации зависят от метода, используемого приложением для запроса авторизации, а также от типов полномочий, поддерживаемых API. OAuth 2 определяет четыре вида полномочий, каждый из которых полезен в различных случаях:

1. Код подтверждения: используется в приложениях серверной стороны.
2. Неявный доступ: используется в веб-и мобильных приложениях (приложениях, которые работают на устройстве пользователя).
3. Предоставление клиенту пароля: применяется в заведомо безопасных приложениях (например, в принадлежащих сервису приложениях).
4. Клиентские полномочия: доступ к API приложения.

Код подтверждения

Код подтверждения – самый распространённый тип полномочий, оптимизированный для приложений серверной стороны, в которых исходный код закрыт, а Client Secret недоступен посторонним. Этот поток основан на редиректе, а это означает, что приложение должно иметь возможность взаимодействовать с агентом пользователя (т.е. веб-браузером пользователя) и получать коды авторизации API, которые направляются через агента пользователя.

Поток с кодом подтверждения выглядит так:

1. Пользователь получает ссылку на код подтверждения.
2. Пользователь авторизуется. Кликая по ссылке, пользователь подтверждает подлинность данных. Если предоставленные данные неправильные, пользователю будет отказано в авторизации.
3. Приложение получает код подтверждения. Сервис перенаправляет агента пользователя к URI, который был указан при регистрации клиента, вместе с кодом подтверждения.
4. Приложение запрашивает токен доступа у API, предоставляя код подтверждения и данные об авторизации, включая client secret.
5. Приложение получает токен доступа, если авторизация валидна.

Поток неявного доступа

Поток неявного доступа используется мобильными приложениями или веб-приложениями, где конфиденциальность client secret гарантировать нельзя. Этот поток также основан на редиректе, но токен доступа получает агент пользователя, после чего он передаётся приложению. Таким образом он может быть виден пользователю или другим приложениям на устройстве пользователя. Кроме того, этот поток не выполняет проверку подлинности приложения, для этого используется URI (который был зарегистрирован в сервисе).

При неявном доступе токены обновления не поддерживаются.

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

1. Пользователь получает ссылку неявного доступа, которая запрашивает токен у API.
2. Пользователь проходит авторизацию, кликнув по ссылке. Если пользователь не может авторизоваться, ему будет отказано в доступе.
3. Агент пользователя получает токен доступа и Redirect URI.
4. Агент пользователя следует Redirect URI.
5. Приложение отправляет сценарий извлечения токена доступа. Приложение возвращает веб-страницу со сценарием, который может извлечь токен доступа из Redirect URI.
6. Приложение получает токен доступа. Авторизация завершена.

Предоставление клиенту пароля

Данный тип подразумевает, что пользователь передаёт учётные данные непосредственно приложению, которое с их помощью получает токен доступа. Этот тип должен поддерживаться только на сервере авторизации. Кроме того, его следует использовать только в случае, если приложению можно доверять (например, оно принадлежит сервису или операционной системе пользователя).

Получив учётные данные пользователя, приложение запрашивает токен доступа у сервера авторизации. Если учётные данные правильные, сервер авторизации предоставит токен доступа. Авторизация завершена.

Клиентские полномочия

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

Приложение запрашивает токен доступа, отправляя свои учетные данные, client ID и client secret. . Если учётные данные правильные, сервер авторизации предоставит токен доступа. Авторизация завершена.

Использование токенов доступа

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

Если токен валидный, API обрабатывает запрос. Если токен недействителен, API выдаст ошибку invalid_request.

Поток с обновляемым токеном

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

Теперь вы знакомы с основами OAuth 2.

В 2010 году началась работа над совершенно новой версией протокола OAuth 2.0 , которая не будет обратно совместимой с OAuth 1.0. В октябре 2012 года структура OAuth 2.0 было опубликована в RFC 6749 , и использование носителя токена в RFC 6750 , оба стандарта отслеживают запросы на комментарии. Дополнительные документы RFC еще разрабатываются.

Предпосылок для создания OAuth 2.0 было несколько. В первую очередь, OAuth достаточно нетривиально использовать на клиентской стороне. Одна из поставленных целей при разработке нового OAuth - упростить разработку клиентских приложений. Во-вторых, несмотря на заявленную в стандарте реализацию трех методов (называемых потоками - flows) получения токена (уникального идентификатора) для авторизации: для веб-приложений, настольных клиентов и мобильных клиентов, фактически все три способа слиты в один. И, в-третьих, протокол оказался плохо масштабируемым. В него планируется добавить :

• 6 новых потоков.

• Токен на предъявителя.

• Упрощенная подпись.

• Короткоживущие токены с долговременной авторизацией.

• Разделение ролей.

Стоит отметить, что, хотя стандарт OAuth 2.0 ещё не утвержден, он уже используется некоторыми сервисами. Например, Graph API социальной сети Facebook поддерживает только OAuth 2.0.

Отличие OAuth от OpenID

Существует ошибочное мнение, что OAuth является расширением протокола OpenID. На самом деле это не так. Хотя OpenID и OAuth имеют много общего, последний является самостоятельным протоколом, никак не связанным с OpenID.

Метка времени и Nonce

Чтобы предотвратить угрозу запросов повторного использования, OAuth используется nonce и метку времени . Термин «nonce» означает что, данное время используется один раз и является уникальным случайным набором букв и цифр, который предназначен для уникальной идентификации каждого подписанного запроса. Имея уникальный идентификатор для каждого запроса, поставщик услуг сможет помешать запросы повторного использования. Это означает, что клиент генерирует уникальную строку для каждого отправляемого на сервер запроса, а сервер отслеживает все использованные nonce для предотвращения их использования во второй раз.

Использование nonce может быть очень дорогостоящим для сервера, так как они требуют постоянного хранения всех полученных nonce. Для того, чтобы реализация была проще, OAuth добавляет метку времени для каждого запроса, который позволяет серверу сохранить только nonce в течение ограниченного времени. Когда приходит запрос с меткой времени, которое раньше, чем сохраненное время, он отвергается как сервер больше не имеет nonce с такого времени.

Полномочия и токены

OAuth используется три вида полномочий: учетные данные клиента (consumer key and secret или client credentials), временные учетные данные (request token and secret или temporary credentials) и токены (access token and secret или token credentials).

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

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

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

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

Как работает OAuth

Схема работы протокола OAuth

Поясним работу протокола OAuth на примере . Допустим, что пользователь (владелец ресурсов) хочет распечатать свои фотографии (ресурсы), загруженные на сайт «photos.example.net» (сервер), при помощи сервиса печати «printer.example.net» (клиент).

1. Клиент посредством протокола HTTPS отправляет серверу запрос, который содержит идентификатор клиента, метку времени, адрес обратного вызова по которому нужно вернуть токен, используемый тип цифровой подписи и саму подпись.
2. Сервер подтверждает запрос и отвечает клиенту токеном доступа (Access Token) и частью разделённого секрета.
3. Клиент передает токен владельцу ресурсов (пользователю) и перенаправляет его на сервер для прохождения авторизации.
4. Сервер, получив от пользователя токен, запрашивает у него его логин и пароль, и в случае успешной аутентификации просит пользователя подтвердить доступ клиента к ресурсам (авторизация), после чего пользователь перенаправляется сервером к клиенту.
5. Клиент передает серверу токен посредством протокола TLS и запрашивает доступ к ресурсам.
6. Сервер подтверждает запрос и отвечает клиенту новым токеном доступа.
7. Используя новый токен, клиент обращается к серверу за ресурсами.
8. Сервер подтверждает запрос и предоставляет ресурсы.

Данный пример описывает поток с кодом подтверждения (Authorization Code Flow). Помимо этого в стандарте OAuth 2.0 описаны следующие потоки:

• Поток неявного доступа (Implicit Grant Flow)

• Поток с обновляемым токеном (Refreshing an Expired Access Token Flow)

• Поток с предоставлением клиенту пароля (Resource Owner Password Credentials Flow)

• Поток клиентских полномочий (Client Credentials Flow)

OAuth поддерживает два метода аутентификации сообщений от клиента: HMAC -SHA1 и RSA -SHA1 . Есть возможность передавать сообщения без подписи, тогда в поле типа подписи указывается «plain text ». Но в этом случае, согласно спецификации, соединение между клиентом и сервером должно устанавливаться через протокол SSL или TLS .

Порталы, использующие OAuth

Дискуссия

В июле 2012 года, Эран Хаммер (Eran Hammer), действующий редактор стандарта OAuth 2.0, объявил об уходе с поста после трех лет работы над новым стандартом, и попросил вычеркнуть своё имя из спецификаций. Он говорил о своих взглядах на своем сайте . Он позже выступил с докладом. .

Примечания

См. также

Ссылки

Wikimedia Foundation . 2010 .

OAuth 2 это фреймворк для авторизации, который позволяет приложениям получать ограниченный доступ к аккаунтам пользователей через HTTP , таким как Fackebook , GitHub и DigitalOcean . Он работает путем делегирования идентификации пользователя сервису, на котором размещена учетная запись пользователя и авторизационным сторонним приложения имеющим доступ к учетной записи пользователя. OAuth 2 предоставляет авторизационные потоки для десктопных, веб приложений и мобильных устройств.

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

Давайте начнём с ролей OAuth 2 !

Роли OAuth

Oauth определяет 4 роли:

• Владелец ресурса
• Клиент
• Сервер ресурса
• Сервер авторизации

Мы разберём каждую роль в следующих подразделах.

Владелец ресурса : Пользователь

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

Сервер ресурса /авторизации : АПИ

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

С точки зрения разработчиков приложений, АПИ сервиса выполняет обе роли, как сервера ресурса так и сервера авторизации. Мы будем перенаправлять к обоим из этих комбинированных ролей, как роль Сервиса так и роль АПИ.

Клиент : Приложение

Клиент это приложение, которое хочет получить доступ к аккаунту пользователя. Перед тем, как оно это сделает, оно должно быть разрешено пользователем и авторизация должна быть проверена АПИ.

Теперь у вас есть представление о том, что из себя представляет роли OAuth, давайте взглянем на диаграмму того, как они в основном взаимодействуют друг с другом:

Вот более подробное объяснение шагов на диаграмме:

1. Приложение запрашивает от пользователя разрешение на доступ к ресурсам сервиса
2. Если пользователь разрешил запрос, то приложение получает предоставление авторизации
3. Приложение запрашивает маркер доступа от сервера авторизации (АПИ сервиса) предоставив удостоверение его подлинности и предоставление авторизации
4. Если идентичность приложения подлинна и предоставление авторизации действительно, то сервер авторизации (АПИ) выдаёт приложению маркер доступа. Авторизация завершена.
5. Приложение запрашивает ресурс от сервера ресурса (АПИ) и предоставляет маркер доступа для подтверждения подлинности
6. Если маркер доступа действителен, сервер ресурса (АПИ) передаёт ресурс приложению

Фактический поток этого процесса будет отличаться в зависимости от типа предоставления авторизации находящегося в использовании — это общая идея. Мы будем изучать различные типы предоставления в следующем разделе.

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

Перед использованием OAuth в Вашем приложении, Вы должны зарегистрировать свое приложение с сервисом. Это делается через регистрационную форму в разделе Разработчика или АПИ веб-сайта сервиса, где Вы будете предоставлять следующую информацию (и вероятно детальную информацию о Вашем приложении):

• Название приложения
• Сайт приложения
• Перенаправление URI или URL обратного вызова

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

Идентификатор клиента и секретный код клиента

Как только ваше приложение зарегистрировано, сервис будет выдавать «учетные данные клиента» в виде идентификатора клиента и секретного кода клиента. Идентификатор клиента это публичная строка, которая используется АПИ сервиса для идентификации приложения, а так же используется для построения авторизационных URL’ов, которые представляются пользователям. Секретный код клиента используется для установки подлинности приложения для АПИ сервиса, когда приложение запрашивает доступ к аккаунту пользователя и должен быть сохранен в секрете между приложением и АПИ.

Предоставление авторизации

В абстрактном потоке протокола выше, первые четыре шага описывают получение предоставления авторизации и маркера доступа. Тип предоставления авторизации зависит от метода используемого приложением для запроса авторизации и типами предоставления поддерживающимися АПИ. OAuth 2 определяет 4 типа предоставления, каждый из которых по своему полезен в разных ситуациях:

• Код авторизации : используется вместе с приложениями на стороне сервера

• Неявность (скрытость) : используется вместе с мобильными приложениями или веб-приложениями (приложения, которые запускаются на устройстве пользователя)

• : используется вместе с доверенными приложениями, такими как те, что находятся в собственности самого сервиса

• Учётные данные клиента : используется с приложениями доступа к АПИ

Теперь мы будем описывать типы предоставлений более детально, их варианты использования и потоки, в следующих разделах.

Тип предоставления : Код авторизации

Тип предоставления кода авторизации является наиболее используемым так как он оптимизирован под приложения на стороне сервера, где исходный код не показан открыто и конфиденциальность секретного кода клиента может быть сохранена. Это поток на основе перенаправления, что означает что приложение должно быть способно взаимодействовать с юзерагентом (т.е. с браузером пользователя) и получать коды авторизации АПИ, которые направляются через юзерагент.

Шаг 1: Ссылка кода авторизации

• https://cloud.digitalocean.com/v1/oauth/authorize — конечная точка авторизации API
• response_type=code — предусматривает что ваше приложение запрашивает предоставление кода авторизации
• client_id=CLIENT_ID — идентификатор клиента приложения (значение по которому АПИ определяет приложение)
• redirect_uri=CALLBACK_URL — место куда сервис перенаправляет браузер после того как код авторизации предоставлен
• scope=read — определяет уровень доступа, который запрашивает приложение

Когда пользователь кликает (нажимает на) по ссылке, они должны сначала залогиниться (войти) в сервисе, для удостоверения их личности (если конечно они уже не залогинились). Затем сервис запросит у них подтверждение на разрешение или запрет доступа приложения к их аккаунту. Вот пример запроса на доступ к аккаунту приложением:

Авторизация приложения

Обзор разрешений (прав доступа)

• Чтение

Авторизовать приложение Запретить

Если пользователь нажимает на «Авторизовать приложение», то сервис перенаправляет браузер на URI переадресации приложения, который был указан при регистрации клиента, вместе с кодом авторизации. Переадресация будет выглядеть так (предполагая, что адрес приложения «dropletbook.com»):

Шаг 4: Приложение получает маркер доступа

Приложение запрашивает маркер доступа от АПИ передавая код авторизации конечной точке маркера АПИ, вместе с подробной информацией об идентификации, включая секретный код клиента. Вот пример запроса через POST к конечной точке маркера DigitalOcean:

Шаг 5: Приложение получает маркер доступа

{«access_token»:»ACCESS_TOKEN»,»token_type»:»bearer»,»expires_in»:2592000,»refresh_token»:»REFRESH_TOKEN»,»scope»:»read»,»uid»:100101,»info»:{«name»:»Mark E. Mark»,»email»:»[email protected] «}}

Теперь приложение авторизовано! Оно может использовать маркер для доступа к аккаунту пользователя через АПИ сервиса, с ограничениями по доступу, пока маркер не истечёт или не будет отменён. Если маркер обновления был передан, то он может быть использован для запроса новых маркеров доступа, если срок действия исходного маркера истёк.

Тип предоставления : Неявность (скрытость)

Тип неявного предоставления используется для мобильных приложений и веб-приложений (т.е. приложений, которые запускаются в браузере), где конфиденциальность секретного кода клиента не гарантируется. Тип неявного предоставления также является потоком на основе переадресации, но маркер доступа даётся браузеру для передачи его приложению, так что он может быть доступен как пользователю, так и другим приложениям на устройстве пользователя. Кроме того, этот поток не проверяет подлинность идентичности приложения и полагается на перенаправление URI (который был зарегистрирован с сервисом), чтобы служить этой цели.

Тип неявного предоставления не поддерживает маркеры обновления.

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

С типом неявного предоставления, пользователю даётся ссылка авторизации, которая запрашивает маркер от АПИ. Эта ссылка выглядит как ссылка кода авторизации, за тем лишь исключением, что она запрашивает маркер вместо кода (обратите внимание, что тип запроса “маркер”):

Примечание

Когда пользователь нажимает на ссылку, они сначала должны войти в сервис, чтобы подтвердить подлинность их личности (если они ещё не залогинились). Затем им будет предложено сервисом разрешить или запретить доступ приложения к их аккаунту. . Вот пример запроса на доступ к аккаунту приложением:

Авторизация приложения

Thedropletbook хотел бы получить разрешение на доступ к вашей учетной записи

Обзор разрешений (прав доступа)

• Чтение

Авторизовать приложение Запретить

Мы видим что ”Thedropletbook App” запрашивает разрешение на доступ к чтению аккаунта “[email protected] ”.

Шаг 3: Браузер получает маркер доступа с переадресацией URI

Шаг 4: Браузер следует за переадресацией URI

Браузер следует за переадресацией URI, но при этом сохраняет маркер доступа.

Шаг 5: Приложение отправляет маркер доступа скрипту извлечения

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

Шаг 6: Маркер доступа передаётся в приложение

Браузер запускает предоставленный скрипт и передаёт извлечённый маркер доступа приложению.

Примечание : DigitalOcean не поддерживает в данное время тип неявного предоставления, так что ссылка указывает на воображаемый сервер авторизации на «oauth.example.com».

Тип предоставления : Владелец ресурса пароля учётных данных

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

Поток пароля учётных данных

После того как пользователь передал свои учётные данные приложению, после этого оно должно запросить маркер доступа у сервера авторизации. POST запрос может выглядеть как-то так:

Если учётные данные пользователя прошли проверку, сервер авторизации возвращает маркер доступа приложению. Теперь приложение авторизовано!

Примечание : DigitalOcean не поддерживает в данное время тип предоставления пароля учётных данных, так что ссылка указывает на воображаемый сервер авторизации на «oauth.example.com».

Тип предоставления : Учётные данные клиента

Тип предоставления учётных данных клиента предоставляет приложению способ доступа к своему личному аккаунту сервиса. Примеры того, когда это может быть полезным, если приложение хочет обновить своё зарегистрированное описание или URI переадресации, или обратиться к другим данным сохранённым в аккаунте сервиса через АПИ.

Поток учётных данных клиента

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

Если учётные данные клиента прошли проверку, сервер авторизации возвращает приложению маркер доступа. С этого момента приложению разрешено использовать её собственный аккаунт!

Примечание : DigitalOcean не поддерживает в данное время тип предоставления учётных данных клиента, так что ссылка указывает на воображаемый сервер авторизации на «oauth.example.com».

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

Как только у приложения появился маркер доступа, оно может использовать маркер для доступа к акаунту пользователя через АПИ, с ограничениями по доступу, пока маркер не истечёт или не будет отменён.

Вот пример АПИ запроса использующего curl . Обратите внимание на то, что он включает маркер доступа:

curl -X POST -H «Authorization: Bearer ACCESS_TOKEN» «https://api.digitalocean.com/v2/$OBJECT» ;

Предполагая, что маркер доступа действителен, АПИ будет обрабатывать запрос в соответствии с своими техническими условиями. Если срок маркера доступа истёк или в противном случае недействителен, АПИ вернёт ошибку “неверный_запрос”.

Поток маркера обновления

После того как срок маркера доступа истёк, использование его для совершения запрос к API приведет к ошибке «Недействительный маркер». На этой стадии, если маркер обновления был включён в запрос, когда исходный маркер доступа был выпущен, он может быть использован для запроса свежего маркера доступа у сервера авторизации. Вот пример POST запроса, использующего маркер обновления для получения нового маркера доступа:

Заключение

На этом мы завершает руководство по OAuth 2. Теперь вы должны иметь хорошее представление о том, как работает OAuth 2 и когда конкретный поток авторизации следует использовать.

Если вы хотите узнать больше об OAuth 2, проверьте эти полезные ресурсы:

• Как использовать идентификацию OAuth с DigitalOcean будучи в качестве пользователя или разработчика
• Как использовать АПИ DigitalOcean версии 2
• Фреймворк авторизации