Введение в OAuth 2

OAuth 2 — протокол для авторизации, целью которого является настройка ограничений доступа. Это можно делать в том числе на Гитхабе и подобных сервисах. Протокол делегирует процесс аутентификации сервису, где находится пользовательский аккаунт, и обеспечивает доступ к нему какого-либо иного сервиса. Это универсальный протокол, стабильно работающий в сети, на десктопах и под мобильными ОС.

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

Роли OAuth 2

В протоколе реализованы определенные виды ролей, в соответствии с которыми работают механизмы авторизации:

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

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

Как устроен протокол

Можно выделить шесть последовательных этапов его работы:

1. Запрос клиентом у владельца авторизации с целью доступа к ресурсному серверу.
2. Получение разрешения (в случае успеха).
3. Отправка запроса на сервер для последующего формирования токена.
4. При успешном подтверждении подлинности клиента и актуальности представленных параметров формируется токен.
5. Далее клиент посылает запрос ресурса, отправляя авторизационный токен.
6. При валидности токена сервер выдает доступ к запрошенному ресурсу.

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

Как выполняется регистрация клиента

Перед началом работы клиент должен быть зарегистрирован, что делается через API (либо используется раздел developer). Там указываются имя клиентского приложения, сайт, а также redirect (редирект) либо callback URL. Редиректом называется URL, куда попадает владелец после попытки авторизоваться.

При положительном ответе OAuth 2 создаст клиентский ID и секрет. ID — это общедоступная запись, необходимая для клиентской идентификации и создания URL, чтобы можно было авторизовать владельца. А client secret нужен для клиентской проверки подлинности при запросе входа в профиль владельца. client secret — скрытая информация, которую «знают» лишь сам клиент, а также сервер.

Виды авторизации и их подробный обзор

В OAuth 2 есть несколько типов авторизации:

• Authorization Code (далее AC) — задействуется при авторизации на стороне API;
• Implicit или неявный тип — по этому сценарию работают приложения, находящиеся на устройствах или подключающиеся из сети;
• Resource Owner Password Credentials (далее ROPC), то есть учетная информация владельца — для доверенных клиентов, которые в некоторых случаях являются элементами собственно OAuth 2;
• Client Credentials (далее CC), то есть учетная информация клиента — задействуется при запросе доступа непосредственно к API.

Остановимся на этих типах немного подробнее и приведем примеры ссылок и ответов сервера.

Тип AC, с отправкой кода

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

Этап первый. Получение ссылки

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

https://anyapplication.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read 

• Вся часть, которая находится между https и authorize,— это эндпоинт API.
• response_type=code — собственно тип, в конкретном случае AC.
• client_id — это клиентский ID.
• redirect_uri — редирект для перенаправления после завершения процесса.
• scope=read — значит, что будет выдан доступ на чтение, если вся операция пройдет штатно.

Этап второй. Авторизация

При нажатии на ссылку владельцу необходимо быть авторизованным. OAuth 2 предложит ему авторизовать клиента (Authorize Application) или отказать последнему (Deny).

Этап третий. Отправка кода

При положительном ответе OAuth 2 направит агент по редиректу, а ссылка примет вот такой вид:

https://anyapplication.com/callback?code=AUTHORIZATION_CODE 

Этап четвертый. Запрос

Теперь отправляется код и сопутствующие параметры:

https://anyapplication.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL 

Этап пятый. Получение токена

При положительном ответе выдается токен (либо же API обновит его), а ответ принимает такой вид:

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2431000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Vasiliy P. Vasiliy","email":"vasiliy@anyapplication.com"}}

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

Тип Implicit, неявный

Это наиболее распространенный вариант работы для мобильных и браузерных приложений, особенностью которых является уязвимость client secret. Здесь токен принимает сетевой агент, передающий его затем клиенту. В результате авторизационный токен оказывается доступным не только для владельца, но и для иного ПО, которое установлено на устройстве. Из других особенностей Implicit отметим отсутствие проверки клиента на подлинность. Теперь рассмотрим процесс поэтапно.

Этап первый. Формирование ссылки

Владелец получает ее в таком виде:

https://anyapplication.com/v1/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read 

Изменение по отношению к AC одно: в типе пересылаемого запроса указывается токен.

Этап второй. Авторизация

При нажатии на ссылку владельцу необходимо быть авторизованным. OAuth 2 предложит ему авторизовать клиента (Authorize Application) или отказать ему (Deny).

Этап третий. Получение токена

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

https://anyapplication.com/callback#token=ACCESS_TOKEN 

После этого агент с сохраненным токеном следует по редиректу.

Этап четвертый. Извлечение скрипта

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

Этап пятый. Передача доступа

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

Тип ROPC, учетная информация владельца

Это один из видов непосредственного доступа, когда данные передаются прямо. Имя владельца и его пароль используются для создания токена. ROPC разумно задействовать, если авторизуемое приложение — это либо часть ОС владельца, либо часть сервиса.

Запрос принимает такой вид:

https://oauth.anyapplication.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

Теперь при правильных (то есть действительных) учетных параметрах API передаст токен.

Тип CC, информация клиента

Запрос может понадобиться, если, например, необходимо обновить регистрационные данные или редирект. Клиент отправляет серверу свои данные, включая также айди и секрет:

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

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

Операции с токеном доступа

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

curl -X POST -H "Authorization: Bearer ACCESS_TOKEN""https://api.anyapplication.com/v2/$OBJECT"

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

https://anyapplication.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

Подводим итоги

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