Oauth что это такое

Что такое OAuth?

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

Цель этой статьи – показать вам, как веб-сайт или приложение принимают запросы на вход от пользователей, которые их посещают. У этих платформ есть необходимые полномочия? Есть ли у них право подтверждать вашу личность и получать доступ к некоторым вашим данным от вашего имени? OAuth объясняет весь этот процесс и помогает его упростить. Прочитайте статью до конца, чтобы узнать, как онлайн-проверки стали автоматизированными и как так получилось, что для их завершения требуется всего один клик.

Что такое OAuth?

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

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

Примеры OAuth

Один из распространенных примеров протокола OAuth связан с большинством устройств Android. Когда вы покупаете смартфон Android, то вам необходимо войти в свою учетную запись электронной почты, чтобы получить доступ к большинству функций телефона.

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

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

Хорошим примером здесь может послужить ситуация, когда вас перенаправляют на другой веб-сайт, и вы получаете сообщение с текстом «Эй, вы хотите получить доступ к нашему сайту с учетными данными другого сайта?» Давайте условно назовем веб-сайт, запрашивающий доступ пользователя, получателем, а платформу, на которой вы в данный момент вошли в систему, — отправителем. Когда вы пытаетесь войти на сайт-получатель, вам необходимо будет узнать, заходите ли вы на сайт под тем же именем, что и на сайте-отправителе.

Facebook – один из наиболее распространенных примеров платформ, которые используют данный протокол. Когда вы используете приложение на Facebook, оно запросит доступ к информации и фотографиям вашего профиля. В таком случае Facebook является отправителем ваших данных для получения доступа и изображений. Приложение здесь является получателем, и как пользователь вы намерены пользоваться услугами принимающей платформы. Нажимая кнопку «Разрешить», вы предоставляете получателю доступ к вашим изображениям, а OAuth существенно упрощает весь этот процесс.

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

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

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

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

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

• Шаг 1: пользователь показывает свое намерение получить доступ
• Шаг 2: получатель получает разрешение. Учетные цифровые идентификационные данные будут отправлены вместе с этим разрешением, которые будут использоваться для выявления подделки и проверки источника запроса на права доступа.
• Шаг 3: пользователь перенаправляется к поставщику услуг или отправителю.
• Шаг 4: пользователь дает разрешение.
• Шаг 5: получатель получает маркер доступа.
• Шаг 6: получатель получает доступ к защищенному ресурсу.

SAML vs OAuth

Многие люди очень легко могут указать на сходства между SAML и OAuth, но их концепции все же очень разные. SAML, также известный как язык разметки утверждений безопасности, представляет собой альтернативный стандарт проверки личности пользователя, который многие организации используют для поддержки функций системы единого входа (SSO). SAML – это функция, позволяющая организациям контролировать тех, кто отвечает за корпоративные ресурсы.

Между SAML и OAuth есть множество различий. SAML использует XML для отправки сообщений, а OAuth – технологию JSON. OAuth разработан для того, чтобы упростить работу с мобильными устройствами, а SAML – для обеспечения повышенного уровня безопасности. Последнее различие является основным. OAuth в основном полагается на API. Именно поэтому многие мобильные приложения, современные веб-сайты, игровые приставки и Интернет вещей используют данный протокол. Как правило, OAuth предлагает пользователям больше возможностей. Чтобы провести аутентификацию пользователя, SAML сбрасывает cookie сессию в браузере пользователя, которая позволяла человеку получать доступ к определенным веб-страницам. Такой вариант отлично подходит для краткосрочного доступа, но не очень подходит для случаев, когда вам необходимо входить в сеть многократно.

OpenID vs OAuth

Если говорить простым языком, то OpenID используется для аутентификации, а OAuth – для авторизации.

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

Оба протокола могут использоваться для выполнения похожих задач, но это вовсе не означает, что они взаимозаменяемы. OpenID обеспечивает подтверждение личности, в то время как OAuth имеет более общее направление использования. Когда клиент использует OAuth, сервер выдает маркер доступа третьей стороне, этот маркер используется для доступа к защищенному ресурсу, а источник проверяет этот маркер. Здесь еще стоит обратить внимание на то, что личность владельца маркера не проверяется.

Сравнение

SAML 2.0

OAuth2

OpenID Connect

Открытый стандарт аутентификации и авторизации

17 февраля 2022 г. Базовое понимание Oauth 2.0

Сегодня, в мире социальных медиа, каждый из нас использует десятки приложений и вебсайтов ежедневно. Oauth 2.0 призван упростить процесс авторизации и, как следствие, сделать жизнь пользователей проще и безопаснее. Возникает вопрос — каким образом?

Oauth 2.0 — что это такое?

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

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

Термин «провайдер» подразумевает сервис, который владеет данными пользователя и, с разрешения пользователя, предоставляет сторонним сервисам (клиентам) безопасный доступ к этим данным. Приложение, желающее получить данные пользователя — это клиент.

Для примера взята форма логина/регистрации на Aliexpress. В данном случае на форме присутствует выбор из нескольких провайдеров — Google, Facebook, Вконтакте и Twitter.

Вы жмете «войти через Facebook» или «войти через Google», Вас перенаправляют на страницу выбора аккаунта, Вы выбираете свою учетную запись и все — Вы уже залогинились.

Спецификация OAuth 2.0 определяет протокол делегирования, который предоставляет клиентам безопасный доступ к ресурсам пользователя на сервисе-провайдере. Такой подход избавляет пользователя от необходимости вводить пароль за пределами сервиса-провайдера: весь процесс сводится к нажатию кнопки «Согласен предоставить доступ к . ». Идея в том, что имея один хорошо защищенный аккаунт, пользователь может использовать его для аутентификации на других сервисах, не раскрывая при этом своего пароля.

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

Общая схема OAuth 2.0 :

1. Клиент запрашивает авторизацию у владельца ресурса.
2. Клиент получает грант авторизации.
3. Клиент запрашивает токен доступа путем аутентификации с помощью сервера авторизации и предоставление гранта авторизации.
4. Сервер авторизации аутентифицирует клиента, проверяя грант авторизации и, если он действителен, выдает токен доступа (access token) и рефреш токен (refresh token).
5. Клиент запрашивает защищенный ресурс у провайдера и аутентифицируется, представляя токен доступа.
6. Провайдер проверяет токен доступа и, если он действителен, обслуживает запрос.

Итак, мы видим, что конечная цель — это получить access и refresh токены. Дальше клиент общается с провайдером данных, пока у access токена не кончится срок годности. Затем, чтобы получить доступ к данным провайдера снова, клиенту нужно воспользоваться refresh токеном и отправить запрос на генерацию новой пары access/refresh токенов.

Зачем вообще нужен refresh токен?

Представим ситуацию, когда некто завладел Вашим access токеном и получил доступ к защищенным данным. Именно поэтому у токенов есть срок годности. У access токена он обычно маленький — от нескольких секунд, до нескольких дней, у refresh токена — побольше. Так вот доступ к данным у злоумышленника будет до тех пор, пока токен доступа не протухнет. Допустим, этот некто завладел еще и refresh токеном и воспользовался им раньше чем Вы, тем самым получив новый access токен. В таком случае Вы не можете получить данные с провайдера, но для решения этой проблемы Вам будет достаточно разлогиниться и залогиниться заново — и все! Все старые токены станут недействительными или удаляться (зависит от реализации). После этой процедуры Вы получаете новые access/refresh токены и можете спокойно продолжить работу, а плохой парень, со старыми токенами, остался с носом.

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

Из плюсов OAuth 2.0 протокола можно выделить следующее:

• Обращение к ресурсам происходит по HTTP/HTTPS с указанием токена в заголовках. Это позволяет использовать OAuth практически в любых решения: мобильных и десктоп приложениях, сайтах, и даже в плагинах для браузеров.
• Возможность авторизации пользователя.
• Популярность — большинство компаний используют его в своих API.
• Простота реализации и большое количество “литературы”.
• Наличие готовых решений, которые можно изменять под свои нужды.

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

Реализацию OAuth 2.0 подхода на php можно найти на GitHub в нескольких популярных бандлах:

• knpuniversity/oauth2-client-bundle
• hwi/HWIOAuthBundle
• FriendsOfSymfony/FOSOAuthServerBundle

Немного о JWT

JSON Web Token — открытый стандарт для создания токена в json формате. Такой токен состоит из трех частей, разделенных точками: заголовок(header), набор полей (payload) и сигнатура. Первые два блока представлены в json-формате и дополнительно закодированы. Для заголовка есть один обязательный ключ — alg, указывающий алгоритм подписи. Набор полей payload содержит произвольные пары ключ/значения. Также существуют необязательные зарезервированные ключи (ознакомиться).

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

Пример

У нас есть некий ключ SECRET_KEY, его знает только сервер и приложение — клиент (получает его во время установки).

$SECRET_KEY = "stFalcon"; $header = ''; $payload = ''; $unsignedToken = \sprintf("%s.%s", base64_encode($header), base64_encode($payload)); $signature = hash_hmac('sha256', $unsignedToken, $SECRET_KEY);p>ol> $tokenEncoded = \sprintf("%s.%s.%s", base64_encode($header), base64_encode($payload), base64_encode($signature));

В результате имеем готовый токен —

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImFsZXgiLCJhZG1pbiI6dHJ1ZX0=.MTI5MGZmYTkwMGM2YmE0ODIzNGQ2ZGI4OGYxZTM2NGY5Y2VhYzExN2NiZGNjODA0YmNhN2NhNmM1ZWUzMDQ3NA==

Теперь проверим токен на валидность —

$tokenDecodedArr = explode('.', $tokenEncoded); $externalHeader = $tokenDecodedArr[0]; $externalPayload = $tokenDecodedArr[1]; $externalSignature = $tokenDecodedArr[2]; if ( base64_decode($externalSignature) === hash_hmac('sha256' , \sprintf("%s.%s", $externalHeader, $externalPayload), $SECRET_KEY) ) { echo 'matched'; } else { echo 'don’t mathe'; }

Таким образом мы проверяем совпадают ли подписи, если да — JWT валидный, т.е. пришел от проверенного источника. Если подписи не совпадают, значит что-то пошло не так — возможно, это является признаком потенциальной атаки.

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

Заключение

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

Вам также может понравиться
Интуитивные жесты в дизайне мобильного приложения
IoT: что это и как разработать приложение для продуктов Интернета вещей?
Процесс создания простого бота Телеграм для отслеживания времени

• web-development ,
• mobile-development

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

OAuth 2.0 (RFC 6749) является фреймворком для авторизации, позволяющим получить сторонним приложениям ограниченный доступ к ресурсам HTTP-сервиса.

Стандарт OAuth 2.0 определяет следующие четыре роли:

• владелец ресурса — сущность, обладающая правом на выдачу доступа к защищенным ресурсам. В случае, если владелец является человеком, его называют конечным пользователем;
• сервер ресурсов — сервер, содержащий защищаемые ресурсы и обладающий возможностью получения и формирования ответа на запросы к защищаемым ресурсам посредством использования маркера доступа;
• клиент — приложение, осуществляющее доступ к защищенным ресурсам от имени Владельца. Термин «клиент» явно не определяет какое-либо конкретное исполнение (будь то сервер, персональный компьютер или мобильное приложение);
• сервер авторизации — сервер, осуществляющий выпуск маркеров доступа для клиентских приложений после успешной аутентификации и авторизации Владельца ресурсов.

Соответствие сущностей DSS ролям OAuth 2.0 имеет следующий вид:

• в качестве владельца ресурсов выступает Пользователь КриптоПро DSS;
• в качестве сервера ресурсов выступают компоненты DSS, содержащие данные Пользователя (например, Сервис Подписи, Сервис Аудита, Хранилище Документов и т.п.)
• клиентом является приложение, осуществляющее операции в DSS. Приложением может являться браузер, толстый клиент или мобильное приложение.
• ЦИ DSS выступает в роли сервера авторизации.

Согласно OAuth, Клиентское Приложение запрашивает доступ к ресурсу, находящемуся в ведении Пользователя. Вместо использования учетных данных Пользователя, Приложение получает маркер доступа — строку, включающую в себя атрибуты доступа к ресурсу. Данные маркеры выпускаются Центром Идентификации КриптоПро DSS с разрешения Пользователя (после его аутентификации).

Протокол OAuth обладает возможностью аутентификации не только Пользователя, но и клиентского приложения, осуществляющего доступ к ресурсам. Для этого протокол предусматривает такие параметры как client_id и client_secret .

сlient_id — это идентификатор клиентского приложения, используемый Центром Идентификации для поиска информации о клиенте.

client_secret является аналогом пароля для клиентского приложения и используется для аутентификации клиентского приложения на ЦИ DSS. Компрометация секрета приводит к компрометации всех клиентских приложений, использовавших client_id , связанный с данными секретом.

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

1. Клиентское приложение запрашивает авторизацию у Пользователя.
2. Приложение получает разрешение на авторизацию (access grant), которое представляет из себя данные, описывающее авторизацию Приложения Пользователем. Разрешение на авторизацию может быть представлено одним из четырех типов, описанных в протоколе;
3. Приложение запрашивает маркер доступа у Центра Идентификации, передавая ему разрешение на авторизацию, полученное от Пользователя;
4. Центр Идентификации аутентифицирует клиента и проверяет валидность разрешения на авторизацию. В случае положительного исхода сервер формирует маркер доступа и передает его клиенту;
5. Приложение запрашивает доступ к защищенному ресурсу (например, Сервису Подписи) и аутентифицируется на нем посредством маркера доступа, полученного ранее.
6. Сервер с защищаемым ресурсом валидирует маркер доступа и в случае положительного исхода предоставляет доступ к запрашиваемым ресурсам.

Протокол определяет следующие типы разрешения на авторизацию:

• код авторизации (authorization code);
• неявный (implicit);
• учетные данные владельца ресурса (resource owner);
• учетные данные клиента (не используется КриптоПро DSS).

Работа с ЦИ DSS по протоколу OAuth 2.0 может быть описана одним из представленных ниже сценариев (подробнее). При этом, все сценарии можно разбить на два класса: требующие взаимодействия с пользователем через браузер и не требующие.

Под взаимодействием с пользователем понимается непосредственное взаимодействие Пользователя DSS c Веб-Интерфейсом Центра Идентикации в рамках авторизации клиентского приложения, в то время как сценарии без взаимодействия с Пользователем могут выполняться по схеме Service-Service.

К сценариям, требующим обязательное взаимодействие с пользователям, относятся:

• Авторизация с использованием кода авторизации
• Авторизация с использованием типа разрешения Implicit

К сценариям которые могут выполняться без интерактивного взаимодействия с пользователям относят:

• Авторизация с аутентификацией по сертификату с использованием кода авторизации
• Авторизация с использованием учетных данных владельца ресурса
• Получение операторского делегирующего маркера доступа к ресурсу.

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:

Рекомендуем в 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

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

В результате сервер 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

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

Авторизуемое приложение должно зафиксировать последний редирект и изъять из параметров 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

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

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

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

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

> 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

Преимущества и недостатки 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), где вашему приложению можно с легкостью добавлять новые интеграции, используя те же учетные данные.

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

Принципы работы протокола DHCP