OAuth

Для MediaWiki (программное обеспечение, используемое Википедией) Поддержка OAuth, см. mw:Справка:OAuth OAuth ("O pen Auth orization") - это открытый стандарт делегирования доступа, обычно используемый пользователями Интернета для предоставления веб-сайтам или приложениям доступа к своей информации на других веб-сайтах, но без предоставления им паролей. Этот механизм используется такими компаниями, как Amazon, Google, Facebook, Microsoft и Twitter, чтобы разрешить пользователям делиться информацией о своих учетных записях со сторонними приложениями или веб-сайтами.

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

Обзор

Как правило, OAuth предоставляет клиентам "безопасный делегированный доступ" к ресурсам сервера от имени владельца ресурса. Он определяет процесс, позволяющий владельцам ресурсов разрешать сторонний доступ к ресурсам своего сервера без предоставления учетных данных. Разработанный специально для работы с протоколом передачи гипертекста (HTTP), OAuth, по сути, позволяет выдавать токены доступа сторонним клиентам сервером авторизации с одобрения владельца ресурса. Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов. В частности, OAuth 2.0 предоставляет специальные потоки авторизации для веб-приложений, настольных приложений, мобильных телефонов и интеллектуальных устройств. [[Файл:Abstract-flow.png|400px|thumb|left|]Высокоуровневый обзор потока Oauth 2.0. Учетные данные владельца ресурса используются только на сервере авторизации, но не на клиенте (например, в стороннем приложении).]

История

OAuth начался в ноябре 2006 года, когда Блейн Кук разрабатывал реализацию OpenID для Twitter . Тем временем Ma.gnolia нуждалась в решении, позволяющем своим пользователям с OpenIDs разрешать виджетам панели мониторинга доступ к их сервису. Кук, Крис Мессина и Ларри Халфф из Magnolia встретились с Дэвидом Рекордоном, чтобы обсудить использование OpenID с API Twitter и Magnolia для делегирования аутентификации. Они пришли к выводу, что не существует открытых стандартов для делегирования доступа к API.[6]

Дискуссионная группа по OAuth была создана в апреле 2007 года для небольшой группы разработчиков для написания проекта предложения по открытому протоколу. Девитт Клинтон из Google узнал о проекте OAuth и выразил заинтересованность в поддержке усилий. В июле 2007 года команда разработала первоначальную спецификацию. Эран Хаммер присоединился к многочисленным вкладам в OAuth и координировал их, создавая более формальную спецификацию. 4 декабря 2007 года был выпущен окончательный вариант OAuth Core 1.0.[7]

На 73-м заседании Рабочей группы по разработке Интернета (IETF) в Миннеаполисе в ноябре 2008 года была проведена Рабочая группа по OAuth для обсуждения включения протокола в IETF для дальнейшей работы по стандартизации. Мероприятие собрало большое количество участников, и идея официального учреждения рабочей группы по OAuth в рамках IETF получила широкую поддержку.

Протокол OAuth 1.0 был опубликован как RFC 5849, информационный запрос на комментарии, в апреле 2010 года. С 31 августа 2010 года все сторонние приложения Twitter должны использовать OAuth.[8]

Платформа OAuth 2.0 была опубликована с учетом дополнительных вариантов использования и требований к расширяемости, полученных от более широкого сообщества IETF. Несмотря на то, что OAuth 2.0 основан на опыте развертывания OAuth 1.0, OAuth 2.0 не имеет обратной совместимости с OAuth 1.0. OAuth 2.0 был опубликован как RFC 6749, а использование токена на предъявителя - как RFC 6750, оба стандарта отслеживают запросы на комментарии в октябре 2012 года.

Платформа авторизации OAuth 2.1 находится на стадии разработки и объединяет функциональность в RFC OAuth 2.0, OAuth 2.0 для собственных приложений, Proof Key для обмена кодами, OAuth 2.0 для приложений на основе браузера, OAuth Security Best Current и использование токенов на предъявителя.

Проблемы безопасности

OAuth 1.0

23 апреля 2009 года было объявлено о недостатке безопасности для фиксации сеанса в протоколе 1.0. Это влияет на поток авторизации OAuth (также известный как "трехэтапный OAuth") в разделе 6 ядра OAuth 1.0.[11] Версия 1.0a протокола ядра OAuth была выпущена для решения этой проблемы.

OAuth 2.0

В январе 2013 года Целевая группа по разработке Интернета опубликовала модель угроз для OAuth 2.0. Среди описанных угроз есть угроза под названием "Открытый перенаправитель"; в начале 2014 года Ван Цзин описал ее вариант под названием "Скрытое перенаправление".

OAuth 2.0 был проанализирован с использованием формального анализа веб-протокола. Этот анализ показал, что в установках с несколькими серверами авторизации, один из которых ведет себя злонамеренно, клиенты могут запутаться в используемом сервере авторизации и могут пересылать секреты вредоносному серверу авторизации (в качестве атаки с путаницей). Это побудило к созданию нового интернет-проекта наилучшей текущей практикив нем излагается определение нового стандарта безопасности для OAuth 2.0. Предполагая, что исправление против атаки AS Mix-Up на месте, безопасность OAuth 2.0 была доказана в рамках сильных моделей атакующих с использованием формального анализа.

Была обнаружена одна реализация OAuth 2.0 с многочисленными недостатками безопасности.

В апреле и мае 2017 года около миллиона пользователей Gmail (менее 0,1% пользователей по состоянию на май 2017 года) подверглись фишинг-атаке на основе OAuth, получив электронное письмо якобы от коллеги, работодателя или друга, желающего поделиться документом в Google Docs. Те, ктотем, кто нажал на ссылку в электронном письме, было предложено войти в систему и разрешить потенциально вредоносной сторонней программе под названием "Google Apps" получить доступ к их "учетной записи электронной почты, контактам и онлайн-документам". В течение "примерно одного часа"[21] фишинговая атака была остановлена Google, который посоветовал тем, кто предоставил "Google Apps" доступ к своей электронной почте, отозвать такой доступ и изменить свои пароли.

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

Использует

Graph API Facebook поддерживает только OAuth 2.0. Google поддерживает OAuth 2.0 в качестве рекомендуемого механизма авторизации для всех своих API. Microsoft также поддерживает OAuth 2.0 для различных API и своей службы Azure Active Directory, которая используется для защиты многих API Microsoft и сторонних производителей.

OAuth может использоваться в качестве механизма авторизации для доступа к защищенным каналам RSS / Atom. Доступ к каналам RSS / ATOM, требующим аутентификации, всегда был проблемой. Например, невозможно получить доступ к RSS-каналу с защищенного сайта Google с помощью Google Reader. Вместо этого трехэтапный OAuth использовался бы для авторизации этого RSS-клиента для доступа к ленте с сайта Google.

OAuth и другие стандарты

OAuth - это сервис, который дополняет OpenID и отличается от него. OAuth не имеет отношения к OATH, которая является эталонной архитектурой для аутентификации, а не стандартом для авторизации. Однако OAuth напрямую связан с OpenID Connect (OIDC), поскольку OIDC - это уровень аутентификации, построенный поверх OAuth 2.0. OAuth также не связан с XACML, который является стандартом политики авторизации. OAuth может использоваться совместно с XACML, где OAuth используется для получения согласия владельца и делегирования доступа, тогда как XACML используется для определения политик авторизации (например, менеджеры могут просматривать документы в своем регионе).

OpenID против псевдо-аутентификации с использованием OAuth

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

Коммуникационный поток в обоих процессах аналогичен:

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

(Только OAuth) Ответ включает токен доступа, который приложение может использовать для получения прямого доступа к службам поставщика удостоверений от имени пользователя.

1. Решающее различие заключается в том, что в случае использования аутентификации OpenID ответ от поставщика удостоверений представляет собой подтверждение подлинности; в то время как в случае использования авторизации OAuth поставщик удостоверений также является поставщиком API, а ответ от поставщика удостоверений представляет собой токен доступа, который может предоставить приложению постоянный доступ кнекоторые API-интерфейсы поставщика удостоверений, от имени пользователя. Токен доступа действует как своего рода "ключ камердинера", который приложение может включать в свои запросы к поставщику удостоверений, которые доказывают, что у него есть разрешение от пользователя на доступ к этим API.

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

Ca

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 - это сообщество, которое "полностью сосредоточено на корпоративных вариантах использования" и "не способно на простые". "То, что сейчас предлагается, - это схема протокола авторизации", - отметил он, "это путь предприятия", обеспечивающий "совершенно новые возможности для продажи консалтинговых услуг и интеграционных решений". При сравнении OAuth 2.0 с OAuth 1.0 Хаммер указывает, что он стал "более сложным, менее совместимым, менее полезным, более неполным и, самое главное, менее безопасным". Он объясняет, как архитектурные изменения для 2.0 развязали токены от клиентов, удалили все подписи и криптографию на уровне протокола и добавили токены с истекающим сроком действия (поскольку токены нельзя было отозвать), усложнив обработку авторизации. Многие пункты были оставлены неопределенными или неограниченными в спецификации, потому что "в соответствии с характером этой рабочей группы, ни одна проблема не является слишком маленькой, чтобы зациклиться на ней или оставить открытой для решения каждой реализации".

Дэвид Рекордон позже также удалил свое имя из спецификаций по неуказанным причинам.Дик Хардт взял на себя роль редактора, и фреймворк был опубликован в октябре 2012 года.

Дэвид Харрис, автор почтового клиента Pegasus Mail, раскритиковал OAuth 2.0 как "абсолютный собачий завтрак", требующий от разработчиков написания пользовательских модулей, специфичных для каждой службы (Gmail, почтовые службы Microsoft и т. Д.), И регистрации именно в них.

Смотрите также

• Список поставщиков OAuth
• Переносимость данных
• Независимый доступ
• Персона Mozilla
• SAML
• Управляемый пользователем доступ

Пруф

//oauth.net/