Войти
Логотип OAuth, разработанный американским блоггером Крисом Мессиной OAuth - это открытый стандарт для делегирования доступа, обычно используемый как способ для пользователей Интернета предоставлять доступ веб-сайтам или приложениям к их информации на других сайтах, но без указания им паролей. Этот механизм используется такими компаниями, как Amazon, Google, Facebook, Microsoft и Twitter, чтобы разрешить пользователи могут делиться информацией о своих учетных записях со сторонними приложениями или веб-сайтами.
Как правило, OAuth предоставляет клиентам «защищенный делегированный доступ» к ресурсам сервера от имени владельца ресурса. Он определяет процесс, позволяющий владельцам ресурсов разрешать доступ третьих лиц к ресурсам своих серверов без предоставления их учетных данных. Разработанный специально для работы с протоколом передачи гипертекста (HTTP), OAuth по существу позволяет выдавать токены доступа сторонним клиентам сервером авторизации с одобрения владельца ресурса. Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.
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 с Twitter и Magnolia API для делегирования аутентификации. Они пришли к выводу, что не существует открытых стандартов для делегирования доступа к API.
Группа обсуждения OAuth была создана в апреле 2007 года, чтобы небольшая группа разработчиков могла написать проект предложения по открытому протоколу.. ДеВитт Клинтон из Google узнал о проекте OAuth и выразил заинтересованность в поддержке его усилий. В июле 2007 года команда разработала начальную спецификацию. Эран Хаммер присоединился и координировал многие работы по OAuth, создав более формальную спецификацию. 4 декабря 2007 г. был выпущен окончательный проект OAuth Core 1.0.
На 73-м заседании Internet Engineering Task Force (IETF) в Миннеаполисе в ноябре 2008 г. OAuth BoF был проведен для обсуждения передачи протокола в IETF для дальнейшей работы по стандартизации. На мероприятии присутствовало много людей, и было широко поддержано официальное учреждение рабочей группы OAuth в IETF.
Протокол OAuth 1.0 был опубликован как RFC 5849, информационный запрос комментариев, в апреле 2010 года.
С 31 августа 2010 года все сторонние приложения Twitter должны были использовать OAuth.
Структура OAuth 2.0 была опубликована как RFC 6749, а использование токена носителя как RFC 6750, оба стандарта track Запросы комментариев в октябре 2012 года.
OAuth 2.0 не имеет обратной совместимости с OAuth 1.0. OAuth 2.0 обеспечивает определенные потоки авторизации для веб-приложений, настольных приложений, мобильных телефонов и смарт-устройств. Спецификация и связанные с ней RFC разрабатываются рабочей группой IETF OAuth; основная структура была опубликована в октябре 2012 года.
Facebook Graph API поддерживает только OAuth 2.0. Google поддерживает OAuth 2.0 в качестве рекомендуемого механизма авторизации для всех своих API. Microsoft также поддерживает OAuth 2.0 для различных API и свою службу Azure Active Directory, которая используется для защиты многих API Microsoft и сторонних производителей.
Структура OAuth 2.0 и использование токенов носителя были опубликованы в октябре 2012 года.
23 апреля 2009 года фиксация сеанса брешь безопасности в протоколе 1.0. Это влияет на процесс авторизации OAuth (также известный как «трехсторонний OAuth») в разделе 6 OAuth Core 1.0. Для решения этой проблемы была выпущена версия 1.0a протокола OAuth Core.
В январе 2013 года Инженерная группа Интернета опубликовала модель угроз для OAuth 2.0. Среди перечисленных угроз одна называется «Open Redirector»; Весной 2014 года Ван Цзин описал вариант этого под названием «Скрытое перенаправление».
OAuth 2.0 был проанализирован с использованием формального анализа веб-протокола. Этот анализ показал, что в настройках с несколькими серверами авторизации, один из которых ведет себя злонамеренно, клиенты могут запутаться в том, какой сервер авторизации использовать, и могут пересылать секреты на злонамеренный сервер авторизации (AS Mix-Up Attack). Это побудило к созданию нового интернет-проекта best current practice, который устанавливает новый стандарт безопасности для OAuth 2.0. При условии исправления атаки AS Mix-Up Attack безопасность OAuth 2.0 была доказана с помощью моделей сильных атак с использованием формального анализа.
Была обнаружена одна реализация OAuth 2.0 с многочисленными недостатками безопасности.
В апреле – мае 2017 г. около миллиона пользователей Gmail (менее 0,1% пользователей по состоянию на май 2017 г.) подверглись фишинг-атаке на основе OAuth, получив электронное письмо, якобы от коллеги, работодателя или друга, желающего опубликовать документ в Документах Google. Те, кто щелкнул ссылку в электронном письме, получили указание войти в систему и разрешить потенциально вредоносной сторонней программе под названием «Google Apps» доступ к их «учетной записи электронной почты, контактам и онлайн-документам». В течение «примерно одного часа» фишинговая атака была остановлена Google, который посоветовал тем, кто предоставил «Google Apps» доступ к своей электронной почте, отозвать такой доступ и изменить свои пароли.
OAuth может использоваться в качестве механизма авторизации для использования защищенных каналов RSS / ATOM. Использование каналов RSS / ATOM, требующих аутентификации, всегда было проблемой. Например, RSS-канал с защищенного сайта Google не мог быть использован с помощью Google Reader. Вместо этого был бы использован трехсторонний протокол OAuth для авторизации этого RSS-клиента для доступа к каналу с сайта Google. Его также можно использовать как средство входа в систему без создания учетной записи на каком-либо сайте и все преимущества хоста системы OAuth.
OAuth - это протокол авторизации, а не протокол аутентификации. Использование OAuth отдельно в качестве метода аутентификации может называться псевдо-аутентификацией. На следующих диаграммах показаны различия между использованием OpenID (специально разработанного как протокол аутентификации) и OAuth для авторизации.
Коммуникационный поток в обоих процессах похож:
Решающий ди Предпочтение заключается в том, что в случае использования аутентификации OpenID ответ от провайдера идентификации является подтверждением идентичности; в то время как в сценарии использования авторизации OAuth поставщик удостоверений также является поставщиком API, а ответ от поставщика удостоверений - токеном доступа, который может предоставить приложению постоянный доступ к некоторым API поставщика удостоверений на от имени пользователя. Маркер доступа действует как своего рода «служебный ключ», который приложение может включать в свои запросы к провайдеру идентификации, которые доказывают, что у него есть разрешение от пользователя на доступ к этим API.
Поскольку провайдер идентификации обычно ( но не всегда) аутентифицирует пользователя как часть процесса предоставления токена доступа OAuth, соблазнительно рассматривать успешный запрос токена доступа OAuth как сам метод аутентификации. Однако, поскольку OAuth не был разработан с учетом этого варианта использования, это предположение может привести к серьезным недостаткам безопасности.
XACML - это доступ на основе политик, на основе атрибутов control структура авторизации. Он обеспечивает:
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 - это сообщество, которое «полностью занимается корпоративными сценариями использования» и «не способно к простому». «Сейчас предлагается проект протокола авторизации, - отметил он, - это корпоративный подход», обеспечивающий «совершенно новый рубеж для продажи консалтинговых услуг и интеграционных решений».
При сравнении OAuth 2.0 Хаммер отмечает, что с OAuth 1.0 он стал «более сложным, менее совместимым, менее полезным, более неполным и, что наиболее важно, менее безопасным». Он объясняет, как архитектурные изменения для несвязанных токенов 2.0 от клиентов, удалены все подписи и криптография на уровне протокола и добавлены истекающие токены (потому что токены не могут быть отозваны), усложняя обработку авторизации. Многочисленные элементы были оставлены неуказанными или неограниченными в спецификации, потому что «в соответствии с характером этой рабочей группы, ни одна проблема не является слишком мелкой, чтобы застрять или оставить открытой для каждой реализации».
Дэвид Рекордон позже также удалил свое имя из спецификаций по неустановленным причинам. Дик Хардт взял на себя роль редактора, и в октябре 2012 года структура была опубликована.
