TOC

Введение в OAuth 2

Вступление

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

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

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

Роли OAuth

OAuth определяет четыре роли:

  • Владелец ресурса

  • клиент

  • Ресурсный сервер

  • Сервер авторизации

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

Владелец ресурса: User

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

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

На сервере ресурсов размещаются защищенные учетные записи пользователей, а сервер авторизации проверяет подлинность user, а затем выдает маркеры доступа к application.

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

Клиент: Application

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

Абстрактный протокольный поток

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

изображение: https: //assets.digitalocean.com/articles/oauth/abstract_flow.png [Абстрактный поток протокола]

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

  1. Application запрашивает авторизацию для доступа к ресурсам службы от user

  2. Если user авторизовал запрос, application получает разрешение на авторизацию

  3. Application запрашивает токен доступа у authorization server (API), предоставляя аутентификацию своей собственной личности и разрешение на авторизацию

  4. Если идентификация приложения аутентифицирована, а разрешение авторизации является действительным, authorization server (API) выдает маркер доступа к приложению. Авторизация завершена.

  5. Application запрашивает ресурс у resource server (API) и представляет токен доступа для аутентификации.

  6. Если токен доступа действителен, ресурсный сервер (API) передает ресурс application

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

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

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

  • Имя приложения

  • Сайт приложения

  • Перенаправить URI или URL обратного вызова

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

Идентификатор клиента и Секрет клиента

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

Авторизация Грант

В приведенном выше _Abstract Protocol Flow, первые четыре этапа охватывают получение разрешения на авторизацию и токена доступа. Тип предоставления авторизации зависит от метода, используемого приложением для запроса авторизации, и от типов предоставления, поддерживаемых API. OAuth 2 определяет четыре типа предоставления, каждый из которых полезен в разных случаях:

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

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

  • * Учетные данные пароля владельца ресурса *: используются с доверенными приложениями, например, принадлежащими самой службе

  • * Учетные данные клиента *: используется с доступом к API приложений

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

Тип гранта: Код авторизации

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

Теперь опишем поток кода авторизации:

изображение: https: //assets.digitalocean.com/articles/oauth/auth_code_flow.png [Поток кода авторизации]

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

Сначала пользователю дается ссылка на код авторизации, которая выглядит следующим образом:

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=&redirect_uri=&scope=

Вот объяснение компонентов ссылки:

  • * https: //cloud.digitalocean.com/v1/oauth/authorize*: конечная точка авторизации API

  • * client_id = *: client ID приложения (как API идентифицирует приложение)

  • * redirect_uri = *: где служба перенаправляет агента пользователя после предоставления кода авторизации

  • * response_type = *: указывает, что ваше приложение запрашивает предоставление кода авторизации

  • * scope = *: указывает уровень доступа, который запрашивает приложение

Шаг 2: Пользователь авторизует приложение

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

изображение: https: //assets.digitalocean.com/articles/oauth/authcode.png [Ссылка на код авторизации]

На этом снимке экрана показан экран авторизации DigitalOcean, и мы видим, что «Thedropletbook App» запрашивает авторизацию для «чтения» доступа к учетной записи «[email protected]».

Шаг 3: приложение получает код авторизации

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

https://dropletbook.com/callback?code=

Шаг 4. Приложение запрашивает токен доступа

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

https://cloud.digitalocean.com/v1/oauth/token?client_id=&client_secret=&grant_type=authorization_code&code=&redirect_uri=

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

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

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

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

Тип гранта: неявный

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

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

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

изображение: https: //assets.digitalocean.com/articles/oauth/implicit_flow.png [неявный поток]

Шаг 1: Ссылка на неявную авторизацию

С неявным типом предоставления пользователю предоставляется ссылка авторизации, которая запрашивает токен из API. Эта ссылка выглядит так же, как ссылка на код авторизации, за исключением того, что она запрашивает token вместо кода (обратите внимание на response type «token»):

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=token&client_id=&redirect_uri=&scope=

Шаг 2: Пользователь авторизует приложение

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

изображение: https: //assets.digitalocean.com/articles/oauth/authcode.png [Ссылка на код авторизации]

Мы видим, что «Thedropletbook App» запрашивает авторизацию для «чтения» доступа к учетной записи «[email protected]».

Шаг 3: Пользователь-агент получает токен доступа с URI перенаправления

Если пользователь нажимает «Авторизовать приложение», служба перенаправляет агента пользователя на URI перенаправления приложения и включает фрагмент URI, содержащий маркер доступа. Это будет выглядеть примерно так:

https://dropletbook.com/callback#token=

Шаг 4: Пользователь-агент следует за URI перенаправления

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

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

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

Шаг 6: токен доступа передан приложению

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

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

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

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

Поток паролей

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

https://oauth.example.com/token?grant_type=password&username=&password=&client_id=

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

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

Тип гранта: учетные данные клиента

Тип предоставления * client credentials * предоставляет приложению способ доступа к своей учетной записи службы. Примеры того, когда это может быть полезно, включают в себя, если приложение хочет обновить свое зарегистрированное описание или перенаправить URI, или получить доступ к другим данным, хранящимся в своей учетной записи службы, через API.

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

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

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

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

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

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

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

Вот пример запроса API с использованием + curl +. Обратите внимание, что он включает токен доступа:

curl -X POST -H "Authorization: Bearer ""https://api.digitalocean.com/v2/"

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

Обновить токен

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

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

https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=&client_secret=&refresh_token=

Заключение

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

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

Related