✖


Jump to content

OAuth

(Перенаправлено из OAuth 2.0 )
Информацию о поддержке OAuth в MediaWiki (программном обеспечении, используемом Википедией) см. в разделе mw:Help:OAuth.

Неофициальный логотип, разработанный Крисом Мессиной.
Последняя версия 2.0
Организация Целевая группа по интернет-инжинирингу
Веб-сайт Хардт, Дик (октябрь 2012 г.). «Структура авторизации OAuth 2.0» .

OAuth (сокращение от открытой авторизации [1] [2] ) — это открытый стандарт делегирования доступа , обычно используемый интернет-пользователями для предоставления веб-сайтам или приложениям доступа к своей информации на других веб-сайтах, но без предоставления им паролей. [3] [4] Этот механизм используют такие компании, как Amazon , [5] Google , Meta Platforms , Microsoft и Twitter разрешают пользователям делиться информацией о своих учетных записях со сторонними приложениями или веб-сайтами.

Как правило, протокол OAuth предоставляет владельцам ресурсов возможность предоставить клиенту [приложению] безопасный делегированный доступ к ресурсам сервера. Он определяет процесс, позволяющий владельцам ресурсов разрешать доступ третьих лиц к ресурсам своего сервера без предоставления учетных данных. Разработанный специально для работы с протоколом передачи гипертекста (HTTP), OAuth по сути позволяет выдавать токены доступа сторонним клиентам сервером авторизации с одобрения владельца ресурса. Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов. [2]

История

[ редактировать ]
Поток авторизации без Oauth.
Гипотетический поток авторизации, в котором данные для входа передаются стороннему приложению. Это создает множество рисков безопасности, которые можно предотвратить с помощью потоков авторизации OAuth.
Общий обзор процесса авторизации Oauth 2.0.
Общий обзор потока Oauth 2.0. Учетные данные владельца ресурса используются только на сервере авторизации, но не на клиенте (например, стороннем приложении).

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

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

На 73-м заседании Рабочей группы по проектированию Интернета (IETF) в Миннеаполисе в ноябре 2008 года был проведен OAuth BoF для обсуждения внесения протокола в 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 1.0. OAuth 2.0 был опубликован как RFC 6749 и использование токена носителя. [ нужны разъяснения ] как и RFC 6750, оба стандарта отслеживают запросы на комментарии в октябре 2012 года. [2] [9]

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

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

[ редактировать ]

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

[ редактировать ]

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

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

[ редактировать ]

В январе 2013 года Инженерная группа Интернета опубликовала модель угроз для OAuth 2.0. [13] Среди обозначенных угроз есть одна под названием «Открытый редиректор»; в начале 2014 года Ван Цзин описал этот вариант под названием «Скрытое перенаправление». [14] [15] [16] [17]

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

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

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

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

Типы

[ редактировать ]

Платформа OAuth определяет несколько типов грантов для разных вариантов использования. Некоторые из наиболее распространенных типов грантов OAuth: [22]

  • Код авторизации
  • ПКСЕ
  • Учетные данные клиента
  • Код устройства
  • Обновить токен

Использование

[ редактировать ]

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

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

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

[ редактировать ]

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

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

[ редактировать ]

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

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

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

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

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

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

OAuth и XACML

[ редактировать ]

XACML — это платформа авторизации управления доступом на основе политик и атрибутов . Он обеспечивает:

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

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

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

  • Менеджеры могут просматривать документы в своем отделе
  • Менеджеры могут редактировать принадлежащие им документы в режиме черновика.

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

Наконец, XACML может прозрачно работать в нескольких стеках ( API , единый вход в Интернет, ESB, собственные приложения, базы данных...). OAuth ориентирован исключительно на приложения на основе HTTP.

Споры

[ редактировать ]

Эран Хаммер ушел с должности ведущего автора проекта OAuth 2.0, вышел из рабочей группы IETF и удалил свое имя из спецификации в июле 2012 года. Причиной своего ухода Хаммер назвал конфликт между веб-культурой и корпоративной культурой, отметив, что IETF — это сообщество, которое «всецело посвящено корпоративным вариантам использования» и «не способно на простые решения». «То, что сейчас предлагается, — это проект протокола авторизации, — отметил он, — это подход предприятия, открывающий «совершенно новый рубеж для продажи консультационных услуг и интеграционных решений». [28] Сравнивая OAuth 2.0 с OAuth 1.0, Хаммер отмечает, что он стал «более сложным, менее совместимым, менее полезным, более неполным и, что наиболее важно, менее безопасным». Он объясняет, как внесены архитектурные изменения для несвязанных с клиентами токенов 2.0, удалены все подписи и криптография на уровне протокола и добавлены токены с истекающим сроком действия (поскольку токены не могут быть отозваны), усложняя при этом обработку авторизации. Многие элементы в спецификации были оставлены неопределенными или неограниченными, потому что «в соответствии с характером этой рабочей группы, ни одна проблема не является слишком незначительной, чтобы застрять в ней или оставить открытой для решения каждой реализации». [28]

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

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

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ «Открытая авторизация — Глоссарий | CSRC» . csrc.nist.gov .
  2. ^ Jump up to: а б с д Хардт, Дик (октябрь 2012 г.). Хардт, Д. (ред.). «RFC6749 — Структура авторизации OAuth 2.0» . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC6749 . Архивировано из оригинала 15 октября 2012 года . Проверено 10 октября 2012 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  3. ^ Уитсон, Гордон. «Понимание OAuth: что происходит, когда вы входите на сайт через Google, Twitter или Facebook» . Лайфхакер . Архивировано из оригинала 24 апреля 2014 года . Проверено 15 мая 2016 г.
  4. ^ Генри, Гэвин (январь 2020 г.). «Джастин Ричер об OAuth» . Программное обеспечение IEEE . 37 (1): 98–100. дои : 10.1109/MS.2019.2949648 . ISSN   0740-7459 .
  5. ^ «Амазонка и OAuth 2.0» . Архивировано из оригинала 8 декабря 2017 года . Проверено 15 декабря 2017 г.
  6. ^ "Введение" . oauth.net . Архивировано из оригинала 21 ноября 2018 года . Проверено 21 ноября 2018 г.
  7. ^ «OAuth Core 1.0» . 4 декабря 2007 г. Архивировано из оригинала 25 ноября 2015 г. Проверено 16 октября 2014 г.
  8. ^ Крис Крам (31 августа 2010 г.). «Приложения Twitter сегодня переходят на OAuth» . WebProNews.com . Архивировано из оригинала 31 июля 2017 года . Проверено 31 июля 2017 г.
  9. ^ Джонс, Майкл; Хардт, Дик (октябрь 2012 г.). «RFC6750 — Структура авторизации OAuth 2.0: использование токена носителя» . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC6750 . Архивировано из оригинала 15 октября 2012 года . Проверено 10 октября 2012 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  10. ^ Jump up to: а б Лоддерштедт, Торстен; Хардт, Дик; Парецки, Аарон (13 октября 2012 г.). «Структура авторизации OAuth 2.1» . www.tools.ietf.org . Проверено 22 ноября 2020 г.
  11. ^ «Рекомендации по безопасности OAuth: 2009.1» . oauth.net . 23 апреля 2009 г. Архивировано из оригинала 27 мая 2016 г. Проверено 23 апреля 2009 г.
  12. ^ «OAuth Core 1.0a» . oauth.net . Архивировано из оригинала 30 июня 2009 года . Проверено 17 июля 2009 г.
  13. ^ Лоддерштедт, Торстен; МакГлойн, Марк; Хант, Фил (январь 2013 г.). Лоддерштедт, Т. (ред.). «RFC6819 — Модель угроз OAuth 2.0 и соображения безопасности» . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC6819 . Архивировано из оригинала 30 июня 2020 года . Проверено 29 июня 2020 г. [rfc:6819 Модель угроз OAuth 2.0 и соображения безопасности]. Рабочая группа по интернет-инжинирингу. По состоянию на январь 2015 г.
  14. ^ «Рекомендации по безопасности OAuth: 2014.1 «Скрытое перенаправление» » . oauth.net . 4 мая 2014 года. Архивировано из оригинала 21 ноября 2015 года . Проверено 10 ноября 2014 г.
  15. ^ «Обнаружен серьезный недостаток безопасности в OAuth, OpenID» . CNET . 2 мая 2014 г. Архивировано из оригинала 2 ноября 2015 г. . Проверено 10 ноября 2014 г.
  16. ^ «Студент-математик обнаружил уязвимость безопасности OAuth, OpenID» . Физика.орг. 3 мая 2014 г. Архивировано из оригинала 6 ноября 2015 г. . Проверено 11 ноября 2014 г.
  17. ^ «Скрытое перенаправление» . Тетраф. 1 мая 2014 года. Архивировано из оригинала 10 марта 2016 года . Проверено 10 ноября 2014 г.
  18. ^ Jump up to: а б Фетт, Дэниел; Кюстерс, Ральф; Шмитц, Гвидо (2016). «Комплексный формальный анализ безопасности OAuth 2.0». Материалы конференции ACM SIGSAC 2016 г. по компьютерной и коммуникационной безопасности . Нью-Йорк, Нью-Йорк, США: ACM Press. стр. 1204–1215. arXiv : 1601.01229 . Бибкод : 2016arXiv160101229F . дои : 10.1145/2976749.2978385 . ISBN  9781450341394 . S2CID   1723789 .
  19. ^ Брэдли, Джон; Лабунец, Андрей; Лоддерштедт, Торстен; Фетт, Дэниел (8 июля 2019 г.). «Лучшая текущая практика безопасности OAuth 2.0» . Рабочая группа по интернет-инжинирингу . Архивировано из оригинала 17 января 2020 года . Проверено 29 июля 2019 г.
  20. ^ «Взлом Facebook с помощью OAuth 2.0 и Chrome» . 12 февраля 2013 года. Архивировано из оригинала 23 апреля 2016 года . Проверено 6 марта 2013 г.
  21. ^ Jump up to: а б с «Фишинговое письмо в Документах Google обошлось Миннесоте в 90 000 долларов » . Новости Би-би-си . 8 мая 2017 года. Архивировано из оригинала 30 июня 2020 года . Проверено 29 июня 2020 г.
  22. ^ «Типы предоставления OAuth» . Оаут.нет . Проверено 6 декабря 2023 г.
  23. ^ «Аутентификация — Разработчики Facebook» . Facebook для разработчиков . Архивировано из оригинала 23 января 2014 года . Проверено 5 января 2020 г.
  24. ^ «Использование OAuth 2.0 для доступа к API Google | Платформа Google Identity» . Разработчики Google . Архивировано из оригинала 4 января 2020 года . Проверено 4 января 2020 г.
  25. ^ «Протоколы v2.0 — поток кода авторизации OAuth 2.0» . Документы Майкрософт . Архивировано из оригинала 29 июня 2020 года . Проверено 29 июня 2020 г.
  26. ^ «Введение в аутентификацию OAuth2» . Linode.com . 22 октября 2021 г. Проверено 18 апреля 2024 г.
  27. ^ «Аутентификация конечного пользователя с помощью OAuth 2.0» . oauth.net . Архивировано из оригинала 19 ноября 2015 года . Проверено 8 марта 2016 г.
  28. ^ Jump up to: а б Хаммер, Эран (28 июля 2012 г.). «OAuth 2.0 и дорога в ад» . Хуэниверс . Архивировано из оригинала 25 марта 2013 года . Проверено 17 января 2018 г.
  29. ^ Харрис, Дэвид (октябрь 2021 г.). «Архив новостей разработчиков Pegasus Mail и Mercury» . Почта Пегаса .
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=OAuth&oldid=1233913796#OAuth_2.0"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 849688bd9b2c1d5aeceef80f08fdeb6f__1720701480
URL1:https://arc.ask3.ru/arc/aa/84/6f/849688bd9b2c1d5aeceef80f08fdeb6f.html
Заголовок, (Title) документа по адресу, URL1:
OAuth - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)