OAuth 2 — протокол для авторизации, целью которого является настройка ограничений доступа. Это можно делать в том числе на Гитхабе и подобных сервисах. Протокол делегирует процесс аутентификации сервису, где находится пользовательский аккаунт, и обеспечивает доступ к нему какого-либо иного сервиса. Это универсальный протокол, стабильно работающий в сети, на десктопах и под мобильными ОС.
Данный материал подготовлен для тех, кому нужно получить первое представление об OAuth 2. Мы рассмотрим роли, виды авторизации и ряд других особенностей этого протокола, чтобы вы могли пользоваться этим сервисом, точно зная, что делаете, и осознавая те риски, которые несут те или иные методы авторизации, распространенные при работе с этим протоколом.
В протоколе реализованы определенные виды ролей, в соответствии с которыми работают механизмы авторизации:
В дальнейшем, чтобы избегать путаницы, будем использовать эти принятые обозначения: владелец для обозначения пользователя, клиент для обозначения приложения и сервер, выполняющий двойную роль: хранилища и API.
Можно выделить шесть последовательных этапов его работы:
Заметим, что операции не всегда выполняются именно в такой последовательности, поскольку многое зависит от того, какое разрешение на авторизацию используется, однако большинство сеансов в OAuth 2 следуют этой схеме. А о видах разрешений мы поговорим ниже.
Перед началом работы клиент должен быть зарегистрирован, что делается через API (либо используется раздел developer
). Там указываются имя клиентского приложения, сайт, а также redirect
(редирект) либо callback URL
. Редиректом называется URL, куда попадает владелец после попытки авторизоваться.
При положительном ответе OAuth 2 создаст клиентский ID и секрет. ID — это общедоступная запись, необходимая для клиентской идентификации и создания URL, чтобы можно было авторизовать владельца. А client secret
нужен для клиентской проверки подлинности при запросе входа в профиль владельца. client secret
— скрытая информация, которую «знают» лишь сам клиент, а также сервер.
В OAuth 2 есть несколько типов авторизации:
Остановимся на этих типах немного подробнее и приведем примеры ссылок и ответов сервера.
При таком решении код и секрет не находятся в открытом доступе. В этом процессе используется редирект, поэтому приложение должно работать через сетевой агент (допустим, веб-браузер), через который оно будет получать коды для авторизации. Разберем этот процесс поэтапно.
Владелец получает ссылку такого вида (рассмотрим абстрактный пример 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
предназначается для последующего создания нового токена по истечении прав текущего.
Это наиболее распространенный вариант работы для мобильных и браузерных приложений, особенностью которых является уязвимость 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 разумно задействовать, если авторизуемое приложение — это либо часть ОС владельца, либо часть сервиса.
Запрос принимает такой вид:
https://oauth.anyapplication.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID
Теперь при правильных (то есть действительных) учетных параметрах API передаст токен.
Запрос может понадобиться, если, например, необходимо обновить регистрационные данные или редирект. Клиент отправляет серверу свои данные, включая также айди и секрет:
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. Теперь вы сможете пользоваться этим сервисом, точно зная, что делаете, и понимая риски, которые несут те или иные типы авторизации.