OAuth - это открытый стандарт делегирования доступа , который обычно используется пользователями Интернета как способ предоставить веб-сайтам или приложениям доступ к своей информации на других веб-сайтах, но без предоставления им паролей. [1] [2] Этот механизм используется такими компаниями, как Amazon , [3] Google , Facebook , Microsoft и Twitter, чтобы пользователи могли обмениваться информацией о своих учетных записях со сторонними приложениями или веб-сайтами.
Как правило, OAuth предоставляет клиентам «безопасный делегированный доступ» к ресурсам сервера от имени владельца ресурса. Он определяет процесс, позволяющий владельцам ресурсов разрешать доступ третьих лиц к ресурсам своего сервера без предоставления учетных данных. Разработанный специально для работы с протоколом передачи гипертекста (HTTP), OAuth позволяет выдавать токены доступа сторонним клиентам сервером авторизации с одобрения владельца ресурса. Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов. [4]
OAuth - это служба, дополняющая OpenID и отличная от нее . OAuth не имеет отношения к OATH , который является эталонной архитектурой для аутентификации, а не стандартом для авторизации. Однако OAuth напрямую связан с OpenID Connect (OIDC), поскольку OIDC - это уровень аутентификации, построенный на основе OAuth 2.0. OAuth также не имеет отношения к XACML , который является стандартом политики авторизации. OAuth можно использовать вместе с XACML, где OAuth используется для согласия владения и делегирования доступа, тогда как XACML используется для определения политик авторизации (например, менеджеры могут просматривать документы в своем регионе).
История
OAuth появился в ноябре 2006 года, когда Блейн Кук разрабатывал реализацию Twitter OpenID . Между тем, Ma.gnolia требовалось решение, позволяющее членам с OpenID разрешать виджетам панели мониторинга доступ к их сервису. Кук, Крис Мессина и Ларри Халф из Magnolia встретились с Дэвидом Рекордоном, чтобы обсудить использование OpenID с API Twitter и Magnolia для делегирования аутентификации. Они пришли к выводу, что открытых стандартов для делегирования доступа к API не существует. [5]
Дискуссионная группа OAuth была создана в апреле 2007 года, чтобы небольшая группа разработчиков могла написать проект предложения по открытому протоколу. ДеВитт Клинтон из Google узнал о проекте OAuth и выразил заинтересованность в поддержке его усилий. В июле 2007 года команда разработала начальную спецификацию. Эран Хаммер присоединился и координировал многие работы по OAuth, создав более формальную спецификацию. 4 декабря 2007 г. был выпущен окончательный проект OAuth Core 1.0. [6]
На 73-м заседании инженерной группы Интернета (IETF) в Миннеаполисе в ноябре 2008 г. было проведено совещание OAuth BoF для обсуждения включения протокола в IETF для дальнейшей работы по стандартизации. На мероприятии присутствовало много людей, и было широко поддержано официальное учреждение рабочей группы OAuth в рамках IETF.
Протокол OAuth 1.0 был опубликован в апреле 2010 года как информационный запрос на комментарии RFC 5849 .
С 31 августа 2010 года все сторонние приложения Twitter должны использовать OAuth. [7]
Платформа OAuth 2.0 была опубликована как RFC 6749, а использование токена носителя как RFC 6750, оба стандарта отслеживают запросы на комментарии , в октябре 2012 года.
OAuth 2.0
OAuth 2.0 не имеет обратной совместимости с OAuth 1.0. OAuth 2.0 обеспечивает определенные потоки авторизации для веб-приложений, настольных приложений, мобильных телефонов и интеллектуальных устройств . Спецификация и связанные с ней RFC разрабатываются рабочей группой IETF OAuth; [8] основная структура была опубликована в октябре 2012 года.
Facebook «s Graph API поддерживает только OAuth 2.0. [9] Google поддерживает OAuth 2.0 в качестве рекомендуемого механизма авторизации для всех своих API . [10] Microsoft также поддерживает OAuth 2.0 для различных API-интерфейсов и свою службу Azure Active Directory [11], которая используется для защиты многих API-интерфейсов Microsoft и сторонних производителей.
Платформа OAuth 2.0 [12] и Bearer Token Usage [13] были опубликованы в октябре 2012 года.
Платформа авторизации OAuth 2.1 находится на стадии разработки. [14]
Безопасность
OAuth 1.0
23 апреля 2009 г. было объявлено об уязвимости безопасности фиксации сеанса в протоколе 1.0. Это влияет на процесс авторизации OAuth (также известный как «трехсторонний OAuth») в OAuth Core 1.0, раздел 6. [15] Версия 1.0a протокола OAuth Core была выпущена для решения этой проблемы. [16]
OAuth 2.0
В январе 2013 года Инженерная группа Интернета опубликовала модель угроз для OAuth 2.0. [17] Среди перечисленных угроз одна называется «Open Redirector»; В начале 2014 года Ван Цзин описал вариант этого под названием «Скрытое перенаправление». [18] [19] [20] [21]
OAuth 2.0 был проанализирован с использованием формального анализа веб-протокола. Этот анализ показал, что в настройках с несколькими серверами авторизации, один из которых ведет себя злонамеренно, клиенты могут запутаться в том, какой сервер авторизации использовать, и могут пересылать секреты на злонамеренный сервер авторизации (AS Mix-Up Attack). [22] Это побудило к созданию нового интернет-проекта передового опыта, который устанавливает новый стандарт безопасности для OAuth 2.0. [23] Если принять меры против атаки AS Mix-Up Attack, безопасность OAuth 2.0 была доказана с использованием сильных моделей злоумышленников с использованием формального анализа. [22]
Была обнаружена одна реализация OAuth 2.0 с многочисленными недостатками безопасности. [24]
В апреле и мае 2017 года около миллиона пользователей Gmail (менее 0,1% пользователей по состоянию на май 2017 года) подверглись фишинг-атаке на основе OAuth, получив электронное письмо от коллеги, работодателя или друга, желающего поделиться документ в Google Docs. [25] Те, кто щелкнул ссылку в письме, получили указание войти в систему и разрешить потенциально вредоносной сторонней программе под названием «Google Apps» доступ к их «учетной записи электронной почты, контактам и онлайн-документам». [25] В течение «примерно одного часа» [25] фишинговая атака была остановлена Google, который посоветовал тем, кто предоставил «Google Apps» доступ к своей электронной почте, отозвать такой доступ и изменить свои пароли.
Использует
OAuth можно использовать в качестве механизма авторизации для доступа к защищенным каналам RSS / ATOM . Доступ к RSS / ATOM-каналам, требующим аутентификации, всегда был проблемой. Например, RSS-канал с защищенного сайта Google не мог быть доступен с помощью Google Reader . Вместо этого можно было бы использовать трехсторонний протокол OAuth для авторизации этого RSS-клиента для доступа к каналу с сайта Google.
Его также можно использовать как средство входа в систему без создания учетной записи на каком-либо сайте, а также все преимущества хоста системы OAuth.
OAuth и другие стандарты
OpenID против псевдо-аутентификации с использованием OAuth
OAuth - это протокол авторизации , а не протокол аутентификации . Использование OAuth как метода аутентификации может называться псевдо-аутентификацией. [ необходима цитата ] На следующих диаграммах показаны различия между использованием OpenID (специально разработанного как протокол аутентификации) и OAuth для авторизации.
Коммуникационный поток в обоих процессах похож:
- (Не изображено) Пользователь запрашивает доступ к ресурсу или сайту из приложения.
- Сайт видит, что пользователь не аутентифицирован. Он формулирует запрос для поставщика удостоверений, кодирует его и отправляет пользователю как часть URL-адреса перенаправления.
- Браузер пользователя запрашивает URL-адрес перенаправления для поставщика удостоверений, включая запрос приложения.
- При необходимости провайдер идентификации аутентифицирует пользователя (возможно, запрашивая его имя пользователя и пароль).
- Как только провайдер удостоверений убедится, что пользователь достаточно аутентифицирован, он обрабатывает запрос приложения, формулирует ответ и отправляет его обратно пользователю вместе с URL-адресом перенаправления обратно в приложение.
- Браузер пользователя запрашивает URL-адрес перенаправления, который возвращается в приложение, включая ответ поставщика удостоверений.
- Приложение декодирует ответ поставщика удостоверений и, соответственно, продолжает работу.
- (Только OAuth). Ответ включает маркер доступа, который приложение может использовать для получения прямого доступа к службам поставщика удостоверений от имени пользователя.
Ключевое отличие состоит в том, что в случае использования аутентификации OpenID ответ от провайдера идентификации является подтверждением идентичности; в то время как в сценарии использования авторизации OAuth поставщик удостоверений также является поставщиком API , а ответ поставщика удостоверений - токеном доступа, который может предоставлять приложению постоянный доступ к некоторым API поставщика удостоверений от имени пользователя. Маркер доступа действует как своего рода «служебный ключ», который приложение может включать в свои запросы к провайдеру удостоверений, которые подтверждают, что у него есть разрешение от пользователя на доступ к этим API .
Поскольку провайдер идентификации обычно (но не всегда) аутентифицирует пользователя как часть процесса предоставления токена доступа OAuth, возникает соблазн рассматривать успешный запрос токена доступа OAuth как сам метод аутентификации. Однако, поскольку OAuth не был разработан с учетом этого варианта использования, такое предположение может привести к серьезным недостаткам безопасности. [26]
OAuth и XACML
XACML - это основанная на политике структура авторизации управления доступом на основе атрибутов . Это обеспечивает:
- Контроль доступа архитектура .
- Язык политик, с помощью которого можно выразить широкий спектр политик управления доступом, включая политики, которые могут использовать согласие, обрабатываемое / определяемое через OAuth.
- Схема запрос / ответ для отправки и получения запросов авторизации.
XACML и OAuth можно комбинировать вместе для обеспечения более комплексного подхода к авторизации. OAuth не предоставляет язык политик для определения политик управления доступом. XACML может использоваться в качестве языка политики.
Если OAuth фокусируется на делегированном доступе (я, пользователь, предоставляю Twitter доступ к моей стене Facebook) и авторизации, ориентированной на идентификацию, XACML использует подход на основе атрибутов, который может учитывать атрибуты пользователя, действия, ресурса и контекст (кто, что, где, когда, как). С помощью XACML можно определять такие политики, как
- Менеджеры могут просматривать документы в своем отделе
- Менеджеры могут редактировать документы, которыми они владеют, в черновом режиме.
XACML обеспечивает более детальный контроль доступа, чем OAuth. Гранулярность OAuth ограничена грубой функциональностью (областями), предоставляемой целевой службой. В результате часто имеет смысл объединить OAuth и XACML вместе, где OAuth предоставит вариант использования делегированного доступа и управление согласием, а XACML предоставит политики авторизации, которые работают с приложениями, процессами и данными.
Наконец, XACML может прозрачно работать с несколькими стеками ( API , веб-SSO, ESB, собственные приложения, базы данных ...). OAuth ориентирован исключительно на приложения на основе HTTP.
Полемика
Эран Хаммер ушел из своей роли ведущего автора проекта OAuth 2.0, вышел из рабочей группы IETF и удалил свое имя из спецификации в июле 2012 года. Хаммер назвал причиной своего ухода конфликт между корпоративной культурой и сетью, отметив, что IETF - это сообщество, которое «занимается корпоративными сценариями использования» и «не способно к простому». «Сейчас предлагается проект протокола авторизации, - отметил он, - это корпоративный путь», открывающий «совершенно новые рубежи для продажи консалтинговых услуг и интеграционных решений». [27]
Сравнивая OAuth 2.0 с OAuth 1.0, Хаммер отмечает, что он стал «более сложным, менее совместимым, менее полезным, более неполным и, что наиболее важно, менее безопасным». Он объясняет, как архитектурные изменения для несвязанных токенов 2.0 от клиентов, удалены все подписи и криптография на уровне протокола и добавлены истекающие токены (поскольку токены не могут быть отозваны), усложняя обработку авторизации. Многочисленные элементы были оставлены неуказанными или неограниченными в спецификации, потому что «в соответствии с характером этой рабочей группы, ни одна проблема не является слишком мелкой, чтобы на ней застрять или оставить открытой для решения каждой реализации». [27]
Позже Дэвид Рекордон также удалил свое имя из спецификаций по неустановленным причинам. Дик Хардт взял на себя роль редактора, и структура была опубликована в октябре 2012 года [12].
Смотрите также
- Список поставщиков OAuth
- Переносимость данных
- IndieAuth
- Mozilla Persona
- OpenID
- SAML
- XACML
- Доступ, управляемый пользователем
Рекомендации
- ^ Уитсон, Гордон. «Понимание OAuth: что происходит, когда вы заходите на сайт с помощью Google, Twitter или Facebook» . Лайфхакер . Архивировано 24 апреля 2014 года . Дата обращения 15 мая 2016 .
- ^ Генри, Гэвин (январь 2020 г.). «Джастин Ричер на OAuth» . Программное обеспечение IEEE . 37 (1): 98–100. DOI : 10.1109 / MS.2019.2949648 . ISSN 0740-7459 .
- ^ «Amazon & OAuth 2.0» . Архивировано 8 декабря 2017 года . Проверено 15 декабря 2017 года .
- ^ «RFC 6749 - Структура авторизации OAuth 2.0» . Архивировано 14 мая 2016 года . Дата обращения 15 мая 2016 .
- ^ «Введение» . oauth.net . Архивировано 21 ноября 2018 года . Проверено 21 ноября 2018 .
- ^ «OAuth Core 1.0» . 4 декабря 2007 года архивации с оригинала на 25 ноября 2015 года . Проверено 16 октября 2014 года .
- ^ Крис Крам (31 августа 2010 г.). «Приложения Twitter переходят на OAuth сегодня» . WebProNews.com . Архивировано 31 июля 2017 года . Проверено 31 июля 2017 года .
- ^ «Протокол веб-авторизации (oauth)» . Инженерная группа Интернета . Архивировано 2 июля 2014 года . Проверено 8 мая 2013 года .
- ^ «Аутентификация - разработчики Facebook» . Facebook для разработчиков . Архивировано 23 января 2014 года . Проверено 5 января 2020 года .
- ^ «Использование OAuth 2.0 для доступа к API Google | Платформа идентификации Google» . Разработчики Google . Архивировано 4 января 2020 года . Проверено 4 января 2020 года .
- ^ «Протоколы v2.0 - поток кода авторизации OAuth 2.0» . Документы Microsoft . Архивировано 29 июня 2020 года . Проверено 29 июня 2020 .
- ^ а б Хардт, Дик (октябрь 2012 г.). «RFC6749 - Структура авторизации OAuth 2.0» . Инженерная группа Интернета . Архивировано 15 октября 2012 года . Проверено 10 октября 2012 года .
- ^ Джонс, Майкл; Хардт, Дик (октябрь 2012 г.). «RFC6750 - Структура авторизации OAuth 2.0: использование токена-носителя» . Инженерная группа Интернета . Архивировано 15 октября 2012 года . Проверено 10 октября 2012 года .
- ^ Лоддерстедт, Торстен; Хардт, Дик; Пареки, Аарон. «Платформа авторизации OAuth 2.1» . tools.ietf.org . Дата обращения 22 ноября 2020 .
- ^ «Рекомендации по безопасности OAuth: 2009.1» . oauth.net . 23 апреля 2009 года архивация с оригинала на 27 мая 2016 года . Проверено 23 апреля 2009 года .
- ^ «OAuth Core 1.0a» . oauth.net . Архивировано 30 июня 2009 года . Проверено 17 июля 2009 года .
- ^ Лоддерстедт, Торстен; Макглойн, Марк; Хант, Фил (январь 2013 г.). «RFC6819 - модель угроз OAuth 2.0 и соображения безопасности» . Инженерная группа Интернета . Архивировано 30 июня 2020 года . Проверено 29 июня 2020 .[RFC: 6819 Модель угроз OAuth 2.0 и соображения безопасности]. Инженерная группа Интернета. По состоянию на январь 2015 г.
- ^ «Рекомендации по безопасности OAuth: 2014.1« Скрытое перенаправление » » . oauth.net . 4 мая 2014 года. Архивировано 21 ноября 2015 года . Проверено 10 ноября 2014 года .
- ^ «Обнаружен серьезный недостаток безопасности в OAuth, OpenID» . CNET . 2 мая 2014. Архивировано 2 ноября 2015 года . Проверено 10 ноября 2014 года .
- ^ «Студент-математик обнаруживает уязвимость безопасности OAuth, OpenID» . Phys.org. 3 мая 2014 года. Архивировано 6 ноября 2015 года . Проверено 11 ноября 2014 года .
- ^ «Скрытое перенаправление» . Тетраф. 1 мая 2014. Архивировано 10 марта 2016 года . Проверено 10 ноября 2014 года .
- ^ а б Фетт, Дэниел; Кюстерс, Ральф; Шмитц, Гвидо (2016). «Комплексный формальный анализ безопасности OAuth 2.0». Материалы конференции ACM SIGSAC по компьютерной и коммуникационной безопасности 2016 года - CCS'16 . Нью-Йорк, Нью-Йорк, США: ACM Press: 1204–1215. arXiv : 1601.01229 . Bibcode : 2016arXiv160101229F . DOI : 10.1145 / 2976749.2978385 . ISBN 9781450341394. S2CID 1723789 .
- ^ Брэдли, Джон; Лабунец, Андрей; Лоддерстедт, Торстен; Фетт, Дэниел. «Лучшие современные методы обеспечения безопасности OAuth 2.0» . Инженерная группа Интернета . Архивировано 17 января 2020 года . Проверено 29 июля 2019 года .
- ^ «Взлом Facebook с помощью OAuth 2.0 и Chrome» . 12 февраля 2013 года. Архивировано 23 апреля 2016 года . Проверено 6 марта 2013 года .
- ^ а б в «Фишинговая электронная почта Google Docs« обошлась Миннесоте в 90 000 долларов » » . BBC News . 8 мая 2017. Архивировано 30 июня 2020 года . Проверено 29 июня 2020 .
- ^ «Аутентификация конечного пользователя с помощью OAuth 2.0» . oauth.net . Архивировано 19 ноября 2015 года . Проверено 8 марта +2016 .
- ^ а б Хаммер, Эран (28 июля 2012 г.). «OAuth 2.0 и дорога в ад» . Hueniverse . Архивировано из оригинального 25 марта 2013 года . Проверено 17 января 2018 .
Внешние ссылки
- Официальный веб-сайт
- Список рассылки рабочей группы OAuth
- Протокол OAuth 1.0 (RFC 5849)
- Платформа авторизации OAuth 2.0 (RFC 6749)
- Платформа авторизации OAuth 2.0: использование токена-носителя (RFC 6750)
- Платформа авторизации OAuth 2.1 draft-ietf-oauth-v2-1-00
- Руководство и ресурсный центр OAuth для начинающих от Hueniverse на Wayback Machine (архивировано 20 февраля 2017 г.)
- Памятка по конечным точкам OAuth
- OAuth с интеграцией фреймворка Spring