Протокол авторизации OAuth 2

В этой статье мы расскажем о OAuth 2.0: объясним, что такое роли, потоки и токены. Кроме того, мы дадим рекомендации по реализации протокола, которые обеспечат вам безопасный делегированный доступ.

• Что такое OAuth 2
• Какие есть роли в OAuth2
• Как работает OAuth 2
• Регистрация приложения на сервере API
• Разрешение на авторизацию: виды авторизации
  • Вид 1.  «Authorization Code»
  • Вид 2. «Implicit»
  • Вид 3. «Resource Owner Password Credentials»
  • Вид 4. «Client Credentials»
• Практический пример реализации использования протокола
• Заключение

Что такое OAuth 2

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

Клиентскими приложениями могут быть веб-сервисы, мобильные или десктопные приложения, а сервисами могут быть различные платформы (например, mail.ru). 

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

В каких случаях он может использоваться? 

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

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

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

Какие есть роли в OAuth2

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

1. Владелец ресурса – это пользователь, у которого есть основная учетная запись. Он полностью управляет доступом к данным своего ресурса. Например, владелец может разрешить ограниченный доступ к своим данным для других приложений.
2. Ресурсный сервер – это система, которая обеспечивает доступ к данным пользователя. Он содержит информацию обо всех пользователях. 
3. Сервер авторизации – это сервер, который управляет процессом авторизации и выдачей разрешений. Он проверяет логины и пароли пользователей, а также выдает авторизационные токены, которые приложения используют для доступа к данным пользователя. 

Вместе серверы могут быть объединены в единую систему «Сервисы», которую видят внешние приложения через API.

4. Клиент (приложение) – это приложение или программа, которая запрашивает доступ к данным пользователя. Прежде чем получить доступ к данным, она должна пройти процедуру авторизации и получить положительный ответ от API. 

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

Как работает OAuth 2

Последовательность действий в работе клиентского приложения может изменяться в зависимости от требований и логики бизнес-процесса. 

Однако вы можете ознакомиться с основными этапами работы OAuth 2:

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

Весь процесс описан на изображении ниже:

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

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

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

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

На последнем этапе регистрации вам будут предоставлены два ключа: 

1. client_id (идентификатор клиента). Используется для идентификации вашего приложения и для создания авторизационных URL для пользователей. Это открытая информация.
2. client_secret (секрет клиента). Необходим для проверки подлинности вашего приложения API сервисом в момент, когда оно запрашивает доступ к аккаунту пользователя. Этот секрет должен быть известен только вашему приложению и сервису API.

Разрешение на авторизацию: виды авторизации 

Система OAuth 2 предоставляет четыре различных вида запроса авторизации, и их выбор зависит от конкретных сценариев использования:

1. Authorization Code (Код авторизации). Этот метод чаще всего используется в серверных приложениях, где безопасность имеет большое значение. Приложение запрашивает код авторизации, который затем обменивается на токен доступа.
2. Implicit (Неявный). Подходит для мобильных приложений, включая их веб-версии. В этом случае приложение получает токен доступа непосредственно после авторизации пользователя, не требуя дополнительного обмена кодом.
3. Resource Owner Password Credentials (Учетные данные владельца). Включает в себя предоставление учетных данных (логина и пароля) доверенным приложениям, которые имеют полный доступ к аккаунту пользователя. Этот метод полезен для приложений, которые интегрируются напрямую в онлайн-сервис.
4. Client Credentials (Учетные данные клиента). Используется, когда приложение работает от имени самого приложения, а не от имени конкретного пользователя. Он обеспечивает доступ к ресурсам через API без привлечения конечного пользователя.

Теперь давайте рассмотрим каждый из этих видов более подробно.

Вид 1.  «Authorization Code»

«Код авторизации» – это один из наиболее распространенных способов авторизации. Он предполагает, что исходный код приложения и секрет клиента хранятся на безопасном сервере, который недоступен посторонним. 

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

Шаг 1. Формирование ссылки с кодом авторизации

Например, предоставьте пользователю примерно следующую ссылку:

Где:

• «https://cloud.sweb/v1/oauth/authorize» – это точка входа для авторизации через API;
• «client_id» – идентификатор, который помогает сервису понять, какое приложение отправило запрос к API;
• «redirect_uri» – ссылка, по которой система направит браузер пользователя после получения кода авторизации;
• «response_type=code» указывает на то, что приложение запросило доступ, используя авторизационный код;
• «scope=read» – разрешает доступ только для чтения данных.

Шаг 2. Процесс авторизации

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

Шаг 3. Передача кода авторизации приложению

Если пользователь выбирает вариант «Авторизовать приложение», система перенаправляет браузер по ссылке, которую мы указали при регистрации пользователя:

Шаг 4. Получение токена доступа от приложения

Далее, например, через POST-запрос приложение отправляет на сервер код авторизации и данные для аутентификации, включая секрет клиента:

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

При успешной авторизации система API возвращает токен доступа. 

В результате вы получите примерно следующий вывод:

Таким образом, приложение будет успешно подключено к серверу.

Вид 2. «Implicit»

Вид авторизации «Неявный» – это метод, который часто используется в мобильных приложениях и веб-ресурсах, которые доступны через браузер на мобильных устройствах. 

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

Шаг 1. Формирование ссылки для авторизации

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

Шаг 2. Запрос авторизации пользователя

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

Шаг 3. Передача токена доступа браузеру 

Если пользователь выбирает «Авторизовать приложение», происходит перенаправление с использованием токена доступа:

Шаг 4. Переход по перенаправлению

Браузер пользователя или любой другой пользовательский агент автоматически следует по указанному пути. В ходе этого процесса сохраняется токен доступа.

Шаг 5. Извлечение токена доступа

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

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

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

Токен будет действителен в течение определенного времени или до его отзыва.

Вид 3. «Resource Owner Password Credentials»

Вид «Учетные данные владельца ресурса» предполагает, что пользователь вводит свои учетные данные (логин и пароль) непосредственно в приложении. После этого приложение самостоятельно отправляет эти данные на сервер, чтобы получить доступ к аккаунту или сервисам. 

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

Процесс авторизации выглядит следующим образом:

1. Пользователь вводит свои учетные данные при запросе приложения.
2. Приложение создает запрос к серверу, включая в него логин и пароль пользователя, а также идентификатор клиента:

3. Если введенные данные корректны, сервер автоматически возвращает запрошенный токен доступа.
4. Теперь у приложения есть доступ к аккаунту или сервисам пользователя, а авторизация и аутентификация успешно завершена.

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

Вид 4. «Client Credentials»

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

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

В этом случае процесс авторизации следующий:

1. Приложение запрашивает токен доступа, отправляя идентификационные данные и секрет клиента на сервер, который предназначен для подтверждения авторизации. 

Примерный запрос выглядит так:

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

Метод «Учетные данные клиента» часто используется, когда приложение работает от своего имени (как клиент), а не от имени конкретного пользователя. 

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

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

После успешного получения токена доступа ваша программа получит возможность взаимодействовать с аккаунтом через API с учетом установленных ограничений (например, «только для чтения»). Эта возможность доступна вплоть до момента истечения срока действия токена или запроса на его принудительный отзыв. 

Давайте рассмотрим процесс более подробно:

1. Ваша программа может отправлять запросы к удаленному сервису, используя полученный токен доступа. Пример запроса с использованием утилиты curl:

Если у вас есть действительный токен, удаленный API обработает ваш запрос. 
Если же произойдет ошибка (например, из-за просроченного токена или поврежденного файла), интерфейс вернет сообщение об ошибке 404 «Invalid Request»:

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

Для этого пропишите:

В ответ на этот запрос ваше приложение получит обновленный токен доступа. Это позволит вам продолжать взаимодействие с удаленными сервисами без необходимости в повторной авторизации.

Заключение

Таким образом, мы рассмотрели различные способы применения протокола OAuth 2 в различных типах приложений. 
Хотите опробовать OAuth 2 на надежной облачной платформе? У Spaceweb вы найдете все необходимое для эффективной работы с протоколом OAuth 2. 
Spaceweb предлагает разнообразные варианты хостинга, включая виртуальный хостинг, VPS/VDS и выделенные серверы. Благодаря этому, у вас есть возможность выбрать именно то, что подходит вашим потребностям.