Oauth токенов что это

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?

OAuth, или Open Authorization (открытая авторизация) — это протокол авторизации на базе открытого стандарта для делегирования доступа. Это безопасный метод, позволяющий пользователям предоставлять поставщикам услуг (т. е. веб-сайтам и приложениям) доступ к их информации без предоставления им паролей.

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

Что такое токены OAuth?

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

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

Процесс OAuth

Запрос доступа

Анна отправляет на YouTube (ресурс) запрос на размещение видео непосредственно в ленте Twitter (поставщик услуг). Затем YouTube запрашивает у Twitter разрешение на доступ.

Обмен токена запроса и секретного ключа

Twitter предоставляет YouTube токен запроса и секретный ключ.

Аутентификация

YouTube перенаправляет Анну для входа в систему Twitter. Анна предоставляет Twitter свои учетные данные и подтверждает, что запрос от YouTube был инициирован пользователем.

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

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

Доступ предоставлен

Теперь Анна может безопасно использовать YouTube для размещения видео непосредственно в своей ленте Twitter.

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

OAuth 1.0 и OAuth 2.0

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

Хотя эта проблема решена в OAuth 2.0, в новой версии преднамеренно не определяется и не поддерживается шифрование, подпись, проверка клиента или привязка канала, а вместо этого требуется, чтобы специалисты по внедрению использовали для этой цели другой протокол безопасности, например HTTPS/TLS.

Ниже приводятся различия между OAuth 1.0 и 2.0.

OAuth и SAML: в чем разница?

SAML — это вариант языка XML, который описывает концепцию, позволяющую одному устройству выполнять как аутентификацию, так и авторизацию от имени одного или нескольких устройств.

С появлением простых форматов кодирования данных, таких как JSON, протокол OAuth стал использоваться и для мобильных устройств. Хотя Oauth — относительно новый протокол, возникший в результате необходимости замены SAML, оба протокола крайне важны для безопасного единого входа (SSO).

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

Что такое OAuth? Определение термина OAuth

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

Немного истории

OAuth 1.0
OAuth возник еще в ноябре 2006, когда Блейн Кук занимался разработкой реализации OpenID для Твиттера. Вместе с Крисом Мессиной, Блейн искал путь к использованию OpenID для доступа к Twitter API без предоставления сервису пароля. Сотрудничая с одним из разработчиков OpenID Девидом Рекордоном, Кук провел анализ функциональности OpenID и протоколов авторизации, таких как Yahoo! BBAuth, Google AuthSub, Flickr Auth. Был сделан вывод, что необходим новый открытый протокол. Так, в апреле 2007 года образовалась группа разработчиков, которые занялись его созданием. В группе приняли участие сотрудники компаний AOL и Google. Финальную версию протокола OAuth 1.0 была представлена 4 декабря 2007 года, а в 2008 году начались работы по стандартизации протокола.

OAuth 2.0
В 2010 году началась работа над новой версией протокола OAuth 2.0. Главной целью новой версии – упрощение разработки клиентский приложений.

Отличие OAuth от OpenID

Мнение, что OAuth – это расширение протокола OpenID, ошибочно. Хотя OpenID и OAuth имеют много общего, OAuth является протоколом самостоятельным и никак не связанным с OpenID.

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

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

Схема работы OAuth

Например, пользователь хочет распечатать свои фото, которые загружены на сайт foto.primer.ru с помощью сервиса печати print.primer.ru

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

Помогло? Делись!

Реклама:

Представляем
систему управления сайтами
NetCat

CMS NetCat — профессиональная коммерческая система управления Интернет-сайтами, один из лидеров на российском рынке веб-разработок.
Наша компания является сертифицированным партнером и рекомендуемым разработчиком сайтов на NetCat во Владивостоке.
В настоящее время большинство новых сайтов мы создаем на основе ее программной платформы.

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