Рассмотрим типичную ситуацию. Вы нашли в интернете интересный ресурс (пусть это будет к примеру портал онлайн-курсов coursera.org), но чтобы им полноценно воспользоваться, нужно создать личный аккаунт и войти в него. Вас не особо радует необходимость «стопятьсот» раз проходить нудную процедуру регистрации: придумывать логин и пароль, вводить личные данные, потом как-то это все запоминать.
Тем не менее, скрепя сердце, вы нажимаете «Войти» и в открывшейся форме обнаруживаете вдруг решение в виде кнопок входа через аккаунты социальной сети. Выбираете любимую соцсеть, например Facebook. Кликаете, после чего вас перебрасывает на форму авторизации. Там вы указываете свои логин и пароль в Facebook. Далее вам предложат разрешить доступ приложению ресурса к вашему аккаунту. Подтверждаете. И все — вы каким-то магическим образом вошли на ресурс, используя регистрационные данные от Facebook. Никаких новых паролей, имен пользователя, заполнения прочих полей не потребовалось.
Для реализации подобных сценариев (а также множества аналогичных) и предназначен стандарт OAuth 2.0.
Содержание:
Что такое OAuth 2.0?
История создания
Отличие от OpenID
Как работает OAuth 2.0?
Зачем нужен Authorization Code
Зачем нужен refresh токен?
Преимущества и недостатки OAuth 2.0
Итоги
OAuth 2.0 (RFC 6749) является открытым фреймворком авторизации, позволяющим получить сторонним приложениям ограниченный доступ к ресурсам HTTP-сервиса.
OAuth появился в ноябре 2006 года, во время разработки Блейном Куком (англ. Blaine Cook) протокола OpenID для сервиса микроблогов Twitter. Совместно с Крисом Мессиной (англ. Chris Messina) он искал способ использования OpenID для доступа к Twitter API без предоставления сервису пароля. В сотрудничестве с одним из создателей OpenID Дэвидом Рекордоном (англ. David Recordon) они провели анализ функциональности OpenID, а также нескольких других проприетарных протоколов авторизации, и пришли к заключению о необходимости в новом, универсальном и открытом протоколе.
В апреле 2007 года образовалась группа инженеров, работавших над его созданием. В ее работе приняли участие сотрудники компаний Google и AOL. Финальная версия ядра протокола OAuth 1.0 была представлена 4 декабря 2007 года. 15 апреля 2009 года Twitter предложил пользователям решение, позволяющее делегировать сторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Войти через Twitter» и основано на OAuth.
В апреле 2010 года был выпущен информационный документ RFC 5849, посвященный стандарту OAuth. В 2010 году началась работа над новой версией протокола OAuth 2.0. В октябре 2012 года структура OAuth 2.0 была опубликована в RFC 6749, а использование носителя токена регламентировано в RFC 6750. Вторая версия была несовместима с первой.
Для создания OAuth 2.0 был ряд оснований. Во-первых, нужно было упростить разработку клиентских приложений. Во-вторых, несмотря на заявленную в стандарте реализацию трех методов получения токена (уникального идентификатора) для авторизации — для веб-приложений, настольных клиентов и мобильных клиентов — фактически все три способа были слиты в один. В-третьих, протокол оказался плохо масштабируемым.
В результате в новый протокол было внесено несколько важных изменений:
На данный момент OAuth 2.0 используется большим количеством ведущих сервисов, таких как Google, Instagram, Facebook, «ВКонтакте» и другие.
Часто можно услышать такой вопрос. А зачем нужен OAuth, если существует OpenID? Хотя OAuth и OpenID имеют много общего, между ними есть принципиальная разница:
Стандарт OAuth 2.0 определяет следующие четыре роли:
Общая схема взаимодействия выглядит следующим образом:
В описанном выше примере взаимодействуют два приложения (клиент, сервер авторизации совмещенный с сервером ресурсов) и конечный пользователь.
Таким образом имеется:
Итак, чтобы запросить токен доступа, клиент получает авторизацию от владельца ресурса. Разрешение выражается в виде гранта авторизации (authorization grant
), который клиент использует для запроса токена доступа (access token
). OAuth определяет четыре типа предоставления:
authorization code
),implicit
),Также предоставляется механизм расширения для определения дополнительных типов грантов. Рассмотрим их подробнее.
Код авторизации (авторизация для приложений, имеющих серверную часть).
Пример
Примеры приводятся для 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
client_id
и client_secret
— значения, полученные при регистрации приложения на платформе. После того, как пользователь выдаст права, происходит перенаправление на указанный redirect_uri
:
< HTTP/1.1 302 Found < Location: http://example.com/cb/123?code=DoRieb0y
Используем полученный code
(код авторизации) для получения токена доступа, выполняя запрос с сервера:
> 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", < }
Обратите внимание, что в последнем запросе используется поле client_secret
, который в данном случае хранится на сервере приложения, и подтверждает, что запрос не подделан.
В результате последнего запроса получаем токен доступа (access_token
), время его жизни (expires_in
), тип ключа, определяющий как его надо использовать, и токен обновления. Полученные данные можно использовать для доступа к защищенным ресурсам.
> GET /platform/api?oauth_token=SlAV32hkKG&client_id=464119&format=json&method=users.getInfo& sig=... HTTP/1.1 > Host: appsmail.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
Здесь приложение должно перехватить последний редирект, получить из адреса acess_token
и использовать его для обращения к защищенным ресурсам.
Учетные данные владельца ресурса (Авторизация по логину и паролю)
Авторизация по логину и паролю представляет простой POST
-запрос, в результате которого возвращается токен доступа. Данная схема вставлена в стандарт для общности и рекомендуется к применению тогда, когда другие варианты авторизации не доступны.
Пример
> 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", < }
Учетные данные клиента
Клиент может запросить токен доступа, используя только свои учетные данные, например когда запрашивает доступ к защищенным ресурсам, находящимся под его контролем. Данный вариант тривиален и подробно рассматриваться не будет.
Восстановление предыдущей авторизации
Обычно, токен доступа имеет ограниченный срок годности. Чтобы не заставлять пользователя проходить авторизацию после истечения срока его действия, во всех перечисленных выше вариантах в дополнение к токену доступа может возвращаться еще токен обновления. По нему можно получить новый токен доступа с помощью 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", < }
Возникает вопрос: почему бы сразу не отдать клиенту токен доступа, с которым можно обращаться к ресурсам? Зачем сначала получать код авторизации, а потом его обменивать на токен доступа? Вроде бы лишний шаг.
Дело в том, что это безопаснее. Канал между приложениями (клиентом и сервером ресурсов) безопасный (back сhannel
). А канал запросов, проходящих через браузер (front channel
), — нет. Код авторизации проходит через браузер: он возвращается в url
при перенаправлении обратно на клиент. Для обращения к ресурсам прошедший через браузер код авторизации не очень подходит. Его относительно легко может перехватить злоумышленник. Поэтому он заменяется на токен доступа, пересылаемый через безопасный канал (back сhannel
). Кроме того, без секрета клиента (client-secret
, который также передается по back сhannel
) токен доступа не получить, что обеспечивает дополнительную безопасность.
Допустим, кто-то завладел вашим токеном доступа и получил доступ к защищенным данным. Именно поэтому у токенов есть срок годности. У токена доступа он обычно небольшой — от нескольких секунд до нескольких дней, у токена обновления — много больше. Так вот: доступ к данным у злоумышленника будет до тех пор, пока токен доступа не «протухнет», то есть недолго.
Допустим, этот некто завладел также и токеном обновления и получил новый токен доступа. Вам будет достаточно разлогиниться и залогиниться заново. Все старые токены станут недействительными или удалятся (зависит от реализации). После этой процедуры вы получаете новые токены и можете спокойно продолжить работу, а злоумышленник со старыми токенами остался с носом.
Из плюсов протокола OAuth 2.0 можно выделить следующее:
Из минусов:
jwt
-токена, но далеко не все сервисы его поддерживают.Итак, OAuth 2.0 — это гибкая технология для делегирования прав доступа к приложениям. Сценариев использования OAuth 2.0 огромное количество, это может быть как упрощенный вход на сторонние сайты, так и автоматизация чтения статистики из соцсети или выполнения удаленных вычислений. Что угодно, что требует сквозной авторизации для доступа к своим ресурсам.
В целом, OAuth 2.0 исправляет недостатки OAuth 1.0, но имеет ряд своих недостатков. На данный момент он все еще находится в развитии. Следующая ожидаемая версия стандарта — OAuth 2.1.
Закрепить озвученный материал можно в этом тематическом видео:
Сегодня мы поговорим о том, как выбрать лучшие курсы Power BI в Украине, особенно для…
В 2023 году во всех крупнейших регионах конкуренция за вакансию выросла на 5–12%. Не исключением…
Unicorn Hunter/Talent Manager Лина Калиш создала бесплатный трекер поиска работы в Notion, систематизирующий все этапы…
Edtech-стартап Mate academy принял решение отправить своих работников в десятидневный отпуск – с 25 декабря…
Служба безопасности Украины задержала в Киеве 46-летнего программиста, который за деньги устанавливал шпионские программы и…
IT-специалист Джордан Катлер создал и выложил на Github подборку разнообразных ресурсов, которые помогут достичь уровня…