Как работает oauth 2. Пример использования маркера доступа

​Заботясь о своих клиентах, команда сервиса 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. Открытие встроенного браузера со страницей авторизации
  2. У пользователя запрашивается подтверждение выдачи прав
  3. В случае согласия пользователя, браузер редиректится на страницу-заглушку во фрагменте (после #) URL которой добавляется access token
  4. Приложение перехватывает редирект и получает access token из адреса страницы
Этот вариант требует поднятия в приложении окна браузера, но не требует серверной части и дополнительного вызова сервер-сервер для обмена authorization code на access token .
Пример
Открываем браузер со страницей авторизации:
> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > Host: connect.mail.ru

После того, как пользователь выдаст права, происходит редирект на стандартную страницу-заглушку, для 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 и использовать его для обращения к защищенным ресурсам.

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

Авторизация по логину и паролю представляет простой POST-запрос, в результате которого возвращается access token . Такая схема не представляет из себя ничего нового, но вставлена в стандарт для общности и рекомендуется к применению только, когда другие варианты авторизации не доступны.
Пример
> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=password&client_id=31337&client_secret=deadbeef&username=api@corp.mail.ru& password=qwerty < HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"SlAV32hkKG", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"8xLOxBtZp8", < }
Описание в спецификации

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

Обычно, access token имеет ограниченный срок годности. Это может быть полезно, например, если он передается по открытым каналам. Чтобы не заставлять пользователя проходить авторизацию после истечения срока действия access token "а, во всех перечисленных выше вариантах, в дополнение к access token "у может возвращаться еще refresh token . По нему можно получить access token с помощью HTTP-запроса, аналогично авторизации по логину и паролю.
Пример
> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp8 < HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"Uu8oor1i", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"ohWo1ohr", < }

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

Например, вы могли бы использовать веб-приложение (скажем, от Нью-Йорк Таймс) для импорта интересных статей в ваш Facebook или Твиттер. Или вы могли бы использовать приложение для iPhone Quora, с помощью которого пользователи могут получать доступ к доске ваших новостей на том же Facebook или Google+.

Его можно настроить с учетом данных вашего профиля: добавлять / приглашать к Quora пользователей, которые находятся в вашем списке друзей. Вопрос в том, как эти приложения получают доступ к вашему аккаунту Facebook, Twitter или Google+, а особенно к конфиденциальной информации?

Прежде чем приложение сможет это сделать, оно должно предоставить некую форму грантов аутентификации и авторизации ресурсам сервера.

Введение в OAuth 2.0

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

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

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

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

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

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

  • Ресурс владельца : приложение, которое способно предоставлять доступ к защищенному ресурсу. Как правило, конечным пользователям;
  • Клиент : приложение, которое отправляет запросы к защищенному ресурсу от имени его владельца и с его разрешения. Это могут быть серверные, мобильные или настольные приложения;
  • Сервер ресурса : сервер защищенного ресурса, способный принимать и отвечать на запросы к ресурсу;
  • Авторизация на сервере : выдача сервером клиенту грантов / маркеров доступа после успешной аутентификации у ресурса владельца и получения от него разрешения;
  • Маркер доступа : маркеры доступа к учетным данным, которые клиент предоставляет серверу ресурса для получения возможности использовать защищенные ресурсы. Обычно это строка параметров, определяющих границы доступа, продолжительности сессии и другие атрибуты. Она также может содержать данные для прохождения авторизации в той или иной форме;
  • Обновление маркера : Хотя это и не предусмотрено по умолчанию, маркеры доступа в идеале должны иметь срок действия (сессии), который может составлять от нескольких минут до нескольких часов. Как только время действия маркера доступа истекло, клиент может запросить сервер об авторизации и выдаче нового маркера доступа с помощью обновления маркера.

В чем была проблема OAuth 1.0?

Главным недостатком OAuth 1.0 была слишком большая сложность данной версии.

На самом деле никаких особых проблем не было! Twitter по-прежнему отлично работает с OAuth 1.0 и просто добавил еще и поддержку версии 2.0. OAuth 1.0 был хорошо продуманной версией фреймворка, которая обеспечивала надежный обмен закрытой информацией, и это делало возможным обмен секретной информацией без подключения SSL.

Причина, почему потребовалась разработка обновления заключается в основном в сложности, с которой была сопряжена работа версии. Ниже приведены некоторые сферы, где OAuth 1.0 не отвечал всем современным требованиям:

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

    В OAuth 2.0 удалось эту сложность обойти. Просто отсылая маркеры по SSL и решая эту задачу на сетевом уровне. OAuth 2.0 не требуется никаких сигнатур;

  • Переадресация встроенных приложений : С развитием встроенных приложений браузеров для мобильных устройств веб-потоки OAuth 1.0 оказались просто неэффективны.

    Так, для них обязательно использование таких агентов как сам интернет-браузер. В OAuth 2.0 потоки были переориентированы именно на работу с встроенными приложениями;

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

OAuth 2.0 в деталях

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

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

Возможные потоки OAuth

OAuth 2.0 добавляет в таблицу порядка пяти новых потоков, что обеспечивает разработчикам гибкость в реализации решений. Они могут использовать любой из них, в зависимости от типа клиента, задействованного в процессе обмена данными:

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

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

  • Поток веб-сервера : Обеспечивает использование гранта кода авторизации. Он представляет собой поток, основанный на принципе перенаправлений, для которого необходимо взаимодействие с агентом конечного пользователя.

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

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

    В качестве примера клиента для такого рода взаимодействий можно привести операционную систему устройства или приложение с обширными правами доступа. Он также может использоваться для переноса существующих клиентов через протокол HTTP или схемы Digest Authentication в OAuth путем преобразования записанных учетных данных в маркер доступа;

  • Поток утверждения : Ваш клиент может выдавать утверждение, например SAML утверждения, взамен на предоставленный маркер доступа;
  • Поток идентификационной информации клиента : OAuth используется в основном для делегированного доступа, но бывают случаи, когда клиент является одновременно и владельцем ресурса или уже ему были предоставлены права доступа сверх обычных потоков OAuth . Здесь просто происходит обмен предоставленных идентификационных данных клиента на маркер доступа.

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

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

Поток веб-сервера

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

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

Аутентификация и авторизация клиента

Клиент от имени владельца ресурса инициирует поток путем перенаправления к конечной точке авторизации, используя при этом: параметр response_type в качестве кода; идентификатор клиента, который был получен в процессе регистрации клиента; URL-адрес перенаправления; запрошенный объем полномочий (опционально) и текущее состояние (если требуется).

Чтобы получить более наглядное представление о том, как осуществляется весь процесс, на скриншоте ниже графически представлено, как будет выглядеть обработка стандартного запроса / ответа:


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

Как это показано на рисунке ниже:

Обмен кода авторизации на маркер

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


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

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

При этом в заголовке Authorization запроса прилагается маркер доступа. В качестве примера CURL-запроса на получение в блог данных с Google Blogger API с учетом идентификатора может послужить следующий код:

$ curl https://www.googleapis.com/blogger/v3/blogs/5223788876950011016 -H "Authorization: OAuth ya29.AHES6ZRTj1GNxAby81Es-p_YPWWNBAFRvBYVsYj2HZJfJHU"

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

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


Затем сервер ресурса проверяет передаваемые данные (маркер доступа) и в случае успешной проверки, отправляет запрашиваемую информацию.
Данные примеры иллюстрируют принципы работы OAuth2.0 Playground . Подобным образом, как правило, реализуется взаимодействие данной версии с Google.

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

Обновление маркера доступа

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

К нему прилагаются идентификатор клиента и секретный код, а также параметр grant_type в качестве refresh_token.


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

Так в чем же проблема OAuth 2.0?

Хороший (положительный момент).

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

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
  • Фреймворк авторизации