stringtranslate.com

OAuth

OAuth (сокращение от open authorization [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 Widgets для доступа к их сервису. Кук, Крис Мессина и Ларри Халфф из Magnolia встретились с Дэвидом Рекордоном, чтобы обсудить использование OpenID с API Twitter и Magnolia для делегирования аутентификации. Они пришли к выводу, что открытых стандартов для делегирования доступа к API не существует. [6]

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

На 73-й встрече Internet Engineering Task Force (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, а Bearer Token Usage [ необходимо разъяснение ] как RFC 6750, оба стандарта отслеживают запросы на комментарии в октябре 2012 года. [2] [9]

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

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

OAuth 1.0

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

OAuth 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 на месте, безопасность 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]

Использует

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

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 как метода аутентификации может называться псевдоаутентификацией. [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 — это основанная на политике и атрибутах структура авторизации контроля доступа. Она обеспечивает:

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 — это сообщество, которое «всецело сосредоточено на корпоративных вариантах использования» и «не способно на простоту». «То, что сейчас предлагается, — это проект протокола авторизации», — отметил он, «это корпоративный путь», предоставляющий «совершенно новый рубеж для продажи консалтинговых услуг и интеграционных решений». [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. ^ abcd Hardt, Dick (октябрь 2012 г.). Hardt, D (ред.). "RFC6749 - The OAuth 2.0 Authorization Framework". Internet Engineering Task Force . doi :10.17487/RFC6749. Архивировано из оригинала 15 октября 2012 г. Получено 10 октября 2012 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  3. ^ Уитсон, Гордон. «Понимание OAuth: что происходит, когда вы входите на сайт с помощью Google, Twitter или Facebook». Lifehacker . Архивировано из оригинала 24 апреля 2014 г. Получено 15 мая 2016 г.
  4. ^ Генри, Гэвин (январь 2020 г.). «Джастин Ричер на OAuth». IEEE Software . 37 (1): 98–100. doi : 10.1109/MS.2019.2949648 . ISSN  0740-7459.
  5. ^ "Amazon & 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 Apps Go OAuth Today». WebProNews.com . Архивировано из оригинала 31 июля 2017 г. Получено 31 июля 2017 г.
  9. ^ Джонс, Майкл; Хардт, Дик (октябрь 2012 г.). "RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage". Internet Engineering Task Force . doi :10.17487/RFC6750. Архивировано из оригинала 15 октября 2012 г. Получено 10 октября 2012 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  10. ^ аб Лоддерстедт, Торстен; Хардт, Дик; Парецки, Аарон (13 октября 2012 г.). «Структура авторизации OAuth 2.1». www.tools.ietf.org . Проверено 22 ноября 2020 г.
  11. ^ "OAuth Security Advisory: 2009.1". oauth.net . 23 апреля 2009 г. Архивировано из оригинала 27 мая 2016 г. Получено 23 апреля 2009 г.
  12. ^ "OAuth Core 1.0a". oauth.net . Архивировано из оригинала 30 июня 2009 . Получено 17 июля 2009 .
  13. ^ Lodderstedt, Torsten; McGloin, Mark; Hunt, Phil (январь 2013 г.). Lodderstedt, T (ред.). "RFC6819 - OAuth 2.0 Threat Model and Security Considerations". Internet Engineering Task Force . doi : 10.17487/RFC6819 . Архивировано из оригинала 30 июня 2020 г. . Получено 29 июня 2020 г. .[rfc:6819 Модель угроз OAuth 2.0 и соображения безопасности]. Internet Engineering Task Force. Доступно в январе 2015 г.
  14. ^ "OAuth Security Advisory: 2014.1 "Covert Redirect"". oauth.net . 4 мая 2014 г. Архивировано из оригинала 21 ноября 2015 г. Получено 10 ноября 2014 г.
  15. ^ «Обнаружена серьезная уязвимость безопасности OAuth, OpenID». CNET . 2 мая 2014 г. Архивировано из оригинала 2 ноября 2015 г. Получено 10 ноября 2014 г.
  16. ^ "Студент-математик обнаружил уязвимость безопасности OAuth, OpenID". Phys.org. 3 мая 2014 г. Архивировано из оригинала 6 ноября 2015 г. Получено 11 ноября 2014 г.
  17. ^ "Скрытое перенаправление". Tetraph. 1 мая 2014 г. Архивировано из оригинала 10 марта 2016 г. Получено 10 ноября 2014 г.
  18. ^ ab Fett, Daniel; Küsters, Ralf; Schmitz, Guido (2016). «A Comprehensive Formal Security Analysis of OAuth 2.0». Труды конференции ACM SIGSAC 2016 года по компьютерной и коммуникационной безопасности . Нью-Йорк, Нью-Йорк, США: ACM Press. стр. 1204–1215. arXiv : 1601.01229 . Bibcode :2016arXiv160101229F. doi :10.1145/2976749.2978385. ISBN 9781450341394. S2CID  1723789.
  19. ^ Брэдли, Джон; Лабунец, Андрей; Лоддерстедт, Торстен; Фетт, Дэниел (8 июля 2019 г.). «OAuth 2.0 Security Best Current Practice». Internet Engineering Task Force . Архивировано из оригинала 17 января 2020 г. Получено 29 июля 2019 г.
  20. ^ "Взлом Facebook с помощью OAuth 2.0 и Chrome". 12 февраля 2013 г. Архивировано из оригинала 23 апреля 2016 г. Получено 6 марта 2013 г.
  21. ^ abc "Фишинговое письмо Google Docs обошлось Миннесоте в 90 000 долларов". BBC News . 8 мая 2017 г. Архивировано из оригинала 30 июня 2020 г. Получено 29 июня 2020 г.
  22. ^ "Типы грантов Oauth". Oauth.net . Получено 6 декабря 2023 г. .
  23. ^ "Аутентификация - Разработчики Facebook". Facebook для разработчиков . Архивировано из оригинала 23 января 2014 года . Получено 5 января 2020 года .
  24. ^ "Использование OAuth 2.0 для доступа к API Google | Платформа идентификации Google". Разработчики Google . Архивировано из оригинала 4 января 2020 г. Получено 4 января 2020 г.
  25. ^ "v2.0 Protocols - OAuth 2.0 Authorization Code Flow". Microsoft Docs . Архивировано из оригинала 29 июня 2020 г. Получено 29 июня 2020 г.
  26. ^ «Введение в аутентификацию OAuth2». Linode.com . 22 октября 2021 г. Получено 18 апреля 2024 г.
  27. ^ "Аутентификация конечного пользователя с помощью OAuth 2.0". oauth.net . Архивировано из оригинала 19 ноября 2015 г. Получено 8 марта 2016 г.
  28. ^ ab Hammer, Eran (28 июля 2012 г.). "OAuth 2.0 и дорога в ад". Hueniverse . Архивировано из оригинала 25 марта 2013 г. Получено 17 января 2018 г.
  29. ^ Харрис, Дэвид (октябрь 2021 г.). «Архивы новостей Pegasus Mail и Mercury Developer». Pegasus Mail .

Внешние ссылки