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

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

Что такое OAuth 2 — обзор

OAuth 2 — это протокол авторизации, предназначенный для организации доступа клиентских приложений к ресурсам, или данным учетных записей, пользователя на другом сервисе. В качестве клиентских приложений выступают веб-сервисы, мобильные и десктопные приложения. В качестве сервисов — mail.ru, GitHub, Bitbucket и др. Протокол используют разработчики сторонних приложений. 

Мы сталкиваемся с этим протоколом, когда:

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

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

Различия протоколов OpenID и OAuth 2

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

Для верификации пользователя OpenID использует ID учетной записи у провайдера, а OAuth — авторизационные ключи (токены) с предопределенным сроком действия и правами доступа.

Используемые роли в OAuth 2

В рамках описываемого протокола выделяются следующие типы ролей:

• владелец (пользователь): авторизует клиентское приложение на доступ к данным своего аккаунта;
• сервер ресурсов/API: здесь располагаются данные пользовательских аккаунтов, а также бизнес-логика авторизации, отвечающая за выдачу новых OAuth-токенов и проверку их подлинности при обращении клиентских приложений к ресурсам. Целесообразно объединять эти роли, так как физически это один сервис;
• клиентское приложение: собственно сервис, которому пользователь делегирует права доступа к своим данным на сервере ресурсов. Пользователь должен авторизовать приложение, а со стороны сервера API оно должно получить подтверждение в виде ключа (токена) доступа. 

Как работает OAuth 2: от запроса на авторизацию до генерации токена

Рассмотрим схему, описывающую принцип действия протокола.

Выделим следующие шаги:

1. Приложение запрашивает у пользователя разрешение на доступ к серверу ресурсов.
2. После получения разрешения приложение сообщает об этом авторизационному серверу, а также предоставляет ему сведения о себе.
3. Сервер авторизации проверяет подлинность разрешения и предоставленных сведений о приложении. В случае успешной проверки генерируется токен доступа.
4. Далее приложение обращается к серверу ресурсов, предоставляя токен в качестве подтверждения пройденной авторизации.
5. Сервер ресурсов проверяет действительность токена и выдает приложению доступ к запрашиваемому ресурсу.

В зависимости от бизнес-логики клиентского приложения последовательность шагов может меняться. Далее рассмотрим наиболее распространенные примеры использования OAuth 2.

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

Вне зависимости от того, с каким именно сервисом выполняется интеграция вашего приложения, его необходимо в первую очередь зарегистрировать. Делается это с помощью специального портала на сайте сервиса, с которым выполняется интеграция (например, https://console.cloud.google.com для Google). 

Заполните все необходимые сведения о приложении:

• тип,
• используемые сервисы,
• название,
• информация о разработчике и пр.

Также в зависимости от архитектуры приложения, возможно, потребуется предоставить callback или redirect url — адрес, на который ваше приложение будет перенаправлять пользователя после успешной авторизации или же отказа от нее. 

На финальном этапе вам будут предоставлены два строковых ключа: client_id (ID клиента) и client_secret (секрет клиента). Первый служит для идентификации приложения, а также генерации авторизационных URL для пользователей — параметр является публичным. Секрет же предназначен для проверки подлинности приложения API сервисом в тот момент, когда оно запрашивает доступ к пользовательскому аккаунту. Секрет должен быть известен только приложению и API.

OAuth для приложений с серверной частью: рассмотрим по шагам

Последовательность шагов приведена на схеме ниже.

1. Пользователь перенаправляется на страницу авторизации, где у него запрашиваются разрешения для приложения на работу с данными его аккаунта.
2. После предоставления необходимых разрешений пользователь попадает на callback URL — адрес, указанный при регистрации приложения, предназначенный для завершения авторизации. При этом происходит подстановка кода авторизации в  GET-параметры адреса.
3. Сервер клиентского приложения формирует POST-запрос к серверу авторизации API с кодом авторизации в качестве параметра.
4. Сервер авторизации проверяет код и возвращает приложению токен доступа (access token).
5. Используя токен, приложение авторизуется на сервере API и получает доступ к запрашиваемым пользовательским ресурсам.

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

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

У нас есть приложение с серверной частью, использующее API mail.ru.

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

> GET /oauth/authorize?response_type=code&client_id=464119&
      redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123 HTTP/1.1
> Host: connect.mail.ru

Значения параметров ID клиента (client_id), секрета клиента (client_secret) и URL страницы подтверждения авторизации (redirect_uri) разработчик получает при регистрации своего приложения на платформе.

Когда пользователь предоставит приложению разрешение на доступ к своему аккаунту, он будет перенаправлен на redirect_uri:

< HTTP/1.1 302 Found
< Location: http://example.com/cb/123?code=DoRieb0y

Рекомендуем в redirect_uri добавлять уникальный идентификатор пользователя для предотвращения CSRF-атак (в приведенном примере это 123). При получении кода авторизации необходимо проверить подлинность идентификатора и его соответствие текущему пользователю. 

Далее необходимо обменять код авторизации на ключ доступа (токен):

> POST /oauth/token HTTP/1.1
> Host: connect.mail.ru
> Content-Type: application/x-www-form-urlencoded
> 
> grant_type=authorization_code&client_id=464119&client_secret=deadbeef&code=DoRieb0y&
  redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123

< HTTP/1.1 200 OK
< Content-Type: application/json
<
< {
<    "access_token":"SlAV32hkKG",
<    "token_type":"bearer",
<    "expires_in":86400,
<    "refresh_token":"8xLOxBtZp8",
< }

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

В результате сервер API возвращает токен доступа (access_token), его тип (token_type), срок жизни (expires_in), а также ключ для обновления токена (refresh_token). Полученные данные можно использовать для работы с пользовательским аккаунтом через API:

> GET /platform/api?oauth_token=SlAV32hkKG&client_id=464119&format=json&method=users.getInfo&
      sig=... HTTP/1.1
> Host: appsmail.ru

OAuth для полностью клиентских приложений

Стороннее приложение может представлять собой лишь графический интерфейс без серверной бизнес-логики и выполнять взаимодействие с сервисом API с помощью кода на клиенте — например, мобильное приложение календаря, заметок и т.д.

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

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

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

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

У нас есть приложение только с клиентской частью, взаимодействующее по API с сервисами Mail.Ru. Рассмотрим процесс авторизации.

Сначала выполним переход на страницу авторизации:

> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1
> Host: connect.mail.ru

После подтверждения делегирования прав произойдет редирект на страницу-заглушку:

< 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

Авторизуемое приложение должно зафиксировать последний редирект и изъять из параметров URL необходимые данные для доступа к сервису по API.

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

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

Пример: имеется некоторое стороннее приложение, работающее с сервисами Mail.Ru по API. При этом в нем применена базовая авторизация.

Отправим запрос с нашими учетными данными и получим данные для вызова API:

> 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",
< }

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

Пример: https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET.

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

Как можно было видеть в предыдущих примерах, вместе с токеном при успешной авторизации возвращается также и ключ для обновления доступа (refresh_token). Он может использоваться для обновления токена по окончании его срока жизни, а также принудительного обновления во избежание компрометации токена при его передаче по открытым каналам. В случае успешного обновления доступа сервер API перевыпустит не только access, но и refresh_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",
< }

Преимущества и недостатки OAuth 2

Рассмотрим подробнее плюсы и минусы протокола авторизации.

Плюсы

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

Минусы

• различия в подходах к реализации у разных сервисов, порождающие необходимость написания отдельного кода под каждый новый сервис;
• если реализована интеграция с семейством приложений, работающих в одной экосистеме (например, Google), существует риск для всех интеграций при компрометации учетных данных либо сбое на стороне сервера API;
• OAuth 2.0 является новым и динамично развивающимся протоколом, в связи с чем возможны некоторые логические противоречия в его спецификации;
• основанная на SSL безопасность протокола может стать проблемой в высоконагруженных проектах.

Пример реализации протокола на PHP

Рассмотрим живой пример проекта клиент-серверного стороннего приложения, взаимодействующего по API с сервисом Google Таблицы.

После регистрации приложения на console.developers.google.com получим файл учетных данных и сохраним его на диске сервера:

Также сохраним файл с информацией о проекте и авторизационными данными:

Установим библиотеку GoogleApiClient для PHP и подготовим код:

Код приведенного класса устанавливает соединение с сервисом API Google Таблиц, используя учетные данные в файле (credentials.json), и обменивает их на токен авторизации, с помощью которого выполняет обращение к содержимому конкретной таблицы (аргументы $sheetRange и $spreadSheetId). При этом реализована проверка жизнеспособности токена для последующих вызовов (метод checkTokenExpired). Полученный токен записывается в файл token.json и доступен для последующих вызовов API через библиотеку:

Далее используем полученный класс для обращения к данным внутри кода проекта:

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

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

Заключение

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

Автор текста: Роман Андреев.