WikiSort.ru - Не сортированное

ПОИСК ПО САЙТУ | о проекте
OAuth
Название OAuth

OAuth — открытый протокол (схема) авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль[1][2].

Работа над протоколом началась в ноябре 2006 года, а последняя версия OAuth 1.0 была утверждена 4 декабря 2007 года. Как последующее развитие в 2010 году появился протокол OAuth 2.0, последняя версия которого в качестве в RFC 6749 опубликована в октябре 2012 года.

Применение

Одной из проблем аутентификации и информационной безопасности является тот факт, что у одного пользователя, как правило, имеется несколько учётных записей на различных сервисах (например, на Google, Twitter, Apple и др.). При этом человеку приходится для каждого из сервисов иметь отдельные логин и пароль. В то же время, каждый из сервисов имеет свою систему безопасности, каждая из которых имеет свои уязвимости и недостатки. Как следствие, пользователям нужно хранить и защищать множество логинов-паролей, что вредит как удобству, так и безопасности; когда, например, пользователи для разных сервисов начинают использовать одни и те же пароли. В то же время, в данных обстоятельствах злоумышленникам становится проще осуществлять взлом (например, после получения доступа к одной из учётных записей взлом других может быть облегчён)[3].

Для улучшения защиты может быть использована аутентификация в два шага (например Google Authenticator), когда для подтверждения задействуется другой сервис пользователя (например, когда для аутентификации на веб-сайте требуется ввести кодовое слово, отправляемое на мобильный телефон). В этом случае вероятность взлома значительно уменьшается. Ключевая особенность применения OAuth заключается в том, что, если пользователь имеет подобный хорошо защищённый аккаунт, то с его помощью и технологии OAuth он может авторизироваться на других сервисах, и при этом ему не требуется раскрывать свой основной пароль. Например, пользователь, который хочет предоставить онлайн-сервису печати фотографий доступ к фотографиям своего Facebook-аккаунта, не должен сообщать сервису пароль от этого аккаунта. Вместо этого он проходит авторизацию непосредственно в Facebook'е, который (с разрешения пользователя или администратора сервиса) предоставляет сервису онлайн-печати полномочия доступа к фотографиям[3].

История

OAuth 1.0

OAuth появился в ноябре 2006 года, во время разработки Блейном Куком (англ. Blaine Cook) протокола OpenID для сервиса микроблогов Twitter. Совместно с Крисом Мессиной (англ. Chris Messina) он искал способ использования OpenID для доступа к Twitter API без предоставления сервису пароля. В сотрудничестве с одним из создателей OpenID Девидом Рекордоном (англ. David Recordon) они провели анализ функциональности OpenID, а также проприетарных протоколов авторизации, таких как Flickr Auth, Google AuthSub и Yahoo! BBAuth, после чего пришли к заключению, что существует необходимость в новом открытом протоколе[4].

В апреле 2007 года образовалась группа инженеров, работавших над его созданием. В её работе приняли участие сотрудники компаний Google и AOL (которая в это же время представила свой собственный протокол OpenAuth). Финальная версия ядра протокола OAuth 1.0 была представлена 4 декабря 2007 года. В 2008 году проводилась работа по стандартизации протокола в Инженерном совете Интернета[4].

15 апреля 2009 года Twitter предложил своим пользователям решение, позволяющее делегировать третьесторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Войти через Твиттер» и было основано на OAuth. Это событие стало поводом для первого широкого исследования протокола на уязвимости, и через несколько дней была обнаружена потенциальная уязвимость, затрагивающая все существующие реализации OAuth. После этого, 23 апреля сообществом разработчиков было выпущено первое дополнение безопасности к протоколу, которое вошло в обновлённую спецификацию OAuth Core 1.0 Revision A, опубликованную 24 июня. В апреле 2010 года был выпущен информационный документ RFC 5849[5], посвящённый стандарту OAuth[4].

OAuth 2.0

В 2010 году началась работа над новой версией протокола OAuth 2.0, для которой не предусматривалась обратная совместимость с OAuth 1.0[1]. В октябре 2012 года структура OAuth 2.0 была опубликована в RFC 6749, и использование носителя токена в RFC 6750.

Предпосылок для создания OAuth 2.0 было несколько. В первую очередь, OAuth достаточно нетривиально использовать на клиентской стороне. Одна из поставленных целей при разработке нового OAuth — упростить разработку клиентских приложений. Во-вторых, несмотря на заявленную в стандарте реализацию трёх методов (называемых потоками (англ. flows)) получения токена (уникального идентификатора) для авторизации: для веб-приложений, настольных клиентов и мобильных клиентов, фактически все три способа слиты в один. И, в-третьих, протокол оказался плохо масштабируемым. В него, помимо новых потоков, были добавлены[6][7]:

  • Токен на предъявителя. Метод авторизации аналогичен существующему способу авторизации с помощью cookie. В этом случае токен непосредственно используется как секрет (сам факт наличия токена авторизует клиента) и передаётся через HTTPS. Это позволяет получать доступ к API посредством простых скриптов (например, с использованием cURL).
  • Упрощенная подпись. Подпись была значительно упрощена, чтобы устранить необходимость в специальном анализе, кодированиях и сортировках параметров.
  • Короткоживущие токены с долговременной авторизацией. Вместо выдачи долгоживущего токена (который за длительное время может быть скомпрометирован), сервер предоставляет кратковременный доступ и долговременную возможность обновлять токен без участия пользователя.
  • Разделение ролей. За авторизацию и за предоставление доступа к API могут отвечать разные сервера.

Несмотря на то, что стандарт OAuth 2.0 не утверждён[8], он используется некоторыми сервисами[9]. Так, авторизация в Mail.Ru API переведена на стандарт OAuth 2.0[10], Facebook Graph API (англ.)русск. поддерживает только OAuth 2.0.[11], а Google рассматривает OAuth 2.0 как рекомендательный механизм аутентификации для всех своих API[12].

Последующее развитие

В июле 2012 года Эран Хаммер (Eran Hammer), действующий редактор стандарта OAuth 2.0, объявил об уходе с поста после трёх лет работы над новым стандартом и попросил вычеркнуть своё имя из спецификаций. Он говорил о своих взглядах на своём сайте[13] и позже выступил с докладом[14]. Девид Рекордон (англ. David Recordon) позже также вычеркнул своё имя из спецификаций без указания причин[15]. Дик Хардт (Dick Hardt) стал редактором стандарта OAuth2.0, и, несмотря на взгляды Эрана Хаммера, структура OAuth 2.0 была опубликована в RFC 6749 в октябре 2012 года[1].

Сравнение с другими протоколами

Преимущества

При использовании OAuth-авторизации пользователь не передаёт свой логин и пароль к защищённым ресурсам напрямую в приложение[3]. Поэтому:

  • У пользователя больше оснований доверять приложению, поскольку пользователь может быть уверен, что несанкционированный доступ к его личным данным невозможен. Не владея логином и паролем пользователя, приложение сможет выполнять только те действия с данными, которые разрешил пользователь, и никакие другие[3].
  • При разработке приложения не нужно заботиться об обеспечении конфиденциальности логина и пароля пользователя. Логин и пароль не передаются приложению, а следовательно, они не могут попасть в руки злоумышленников[16].

В случае авторизации без использования протокола OAuth пользователю необходимо передавать свой логин и пароль. У этого способа существуют дополнительные недостатки[3]:

  • Если пользователь изменяет пароль, то приложение больше не может получить доступ к защищённым ресурсам.
  • Единственный способ запретить приложению доступ к защищённым ресурсам — изменить пароль. Это одновременно запретит доступ к ресурсам и другим приложениям, которые ранее его имели.
  • Сервисы, хранящие защищённые ресурсы и предоставляющие API для доступа к ним, могут использовать федеративные механизмы аутентификации (англ. Federated Authentication), такие как OpenID или SAML, что позволяет пользователям не иметь пароля к их аккаунтам. Это делает невозможным для этих пользователей использование приложений, запрашивающих доступ к защищённым ресурсам через этот API.

Отличие от OpenID

Хотя OAuth и OpenID имеют много общего, OAuth является самостоятельным протоколом, никак не связанным с OpenID[16]:

  • OAuth является протоколом авторизации[16], который позволяет предоставить права на использование какого-то ресурса (например, API какого-либо сервиса). Наличие прав определяется токеном (уникальным идентификатором), который может быть одним и тем же для разных пользователей, или же у одного пользователя в разное время могут быть разные токены. Предоставление прав происходит в обмен на предоставление токена. В общем случае нельзя определить, кому принадлежит токен и кто в настоящий момент пользуется правами.
  • OpenID является средством аутентификации[16]: с помощью этой системы можно удостовериться, что пользователь — именно тот, за кого себя выдаёт. Какие действия сможет совершать пользователь, прошедший аутентификацию посредством OpenID, определяется стороной, проводящей аутентификацию.

Описание протоколов OAuth

Рассмотрим основные понятия протоколов и примеры их использования.

Клиент, сервер и владелец ресурса

OAuth 1.0 определяет три роли: клиент, сервер и владелец ресурса. Эти три роли присутствуют в любой операции OAuth, в некоторых случаях клиент также является владельцем ресурса. Оригинальная версия спецификации использует различный набор терминов для этих ролей: потребитель (клиент), услуга (сервер) и пользователь (владелец ресурса)[17]. В протоколе OAuth 2.0 произошло разделение ролей сервера: отдельно выделяется сервер авторизации и сервер, хранящий защищённые ресурсы[7].

Методы создания подписей

OAuth поддерживает 3 метода создания подписей, используемых для подписывания и проверки запросов: PLAINTEXT, HMAC-SHA1 и RSA-SHA1. PLAINTEXT тривиален в использовании и занимает значительно меньше времени для вычисления, но он может быть безопасен только над HTTPS или аналогичными защищёнными каналами. HMAC-SHA1 предлагает простой и общий алгоритм, который доступен на большинстве платформ, но не на всех устаревших устройствах, и использует симметричный общий ключ. RSA-SHA1 обеспечивает повышенную безопасность с помощью пары ключей, но является более сложным и требует генерации ключей[18].

Метка времени и Nonce

Чтобы предотвратить угрозу повторного использования запросов, OAuth использует nonce и метку времени. Термин «nonce» означает одноразовый код и является случайным набором букв и цифр, который предназначен для уникальной идентификации каждого подписанного запроса. Имея уникальный идентификатор для каждого запроса, поставщик услуг сможет предотвратить повторноe использование запросов. Это реализуется в виде генерируемой клиентом уникальной строки для каждого отправляемого на сервер запроса. А сервер отслеживает все использованные nonce для предотвращения их использования во второй раз[18].

Использование nonce может быть очень дорогостоящим для сервера, так как они требуют постоянного хранения всех полученных nonce. Для того, чтобы реализация была проще, OAuth добавляет метку времени для каждого запроса, которая позволяет серверу сохранить nonce в течение ограниченного времени. Если сервер получает запрос с меткой времени более ранней, чем сохранённое время, то он отвергает его как если бы не имел nonce с такого времени[18].

Полномочия и токены

В OAuth 1.0 и OAuth 2.0 используются три вида полномочий: учётные данные клиента (англ. consumer key and secret или англ. client credentials), временные учётные данные (англ. request token and secret или англ. temporary credentials) и токены (англ. access token and secret или англ. token credentials)[5][3].

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

Токен используется вместо имени и пароля владельца ресурса. Владелец ресурса не раскрывает свои учётные данные клиенту, а разрешает серверу выдавать клиенту токен — специальный класс учётных данных, предоставляющий клиенту некоторые ограниченные возможности. Клиент использует токен для доступа к защищённому ресурсу, не зная при этом пароля владельца ресурсов. Токен состоит из цифровой подписи, обычно (но не всегда) случайного набора букв и цифр, который является уникальным и криптографически стойким, и из ключа для защиты токена от использования посторонними лицами. Токен ограничен по полномочиям и продолжительности и может быть отозван в любой момент владельцем ресурса, при этом не затрагивает токенов, выданных другим клиентам[5].

Процесс OAuth авторизации также использует набор вре́менных учётных данных, которые задействуются на стадии запроса авторизации. В целях удовлетворения различного рода клиентов (веб-интерфейсных, настольных, мобильных и т. д.), временные полномочия предлагают дополнительную гибкость и безопасность[5].

OAuth 1.0

Схема работы протокола OAuth

Поясним работу протокола OAuth 1.0 на примере[5]. Допустим, что пользователь (владелец ресурсов) хочет распечатать свои фотографии (ресурсы), загруженные на сайт «photos.example.net» (сервер), при помощи сервиса печати «printer.example.net» (клиент).

  1. Клиент посредством протокола HTTPS отправляет серверу запрос, который содержит идентификатор клиента, метку времени, адрес обратного вызова (по нему нужно вернуть токен), используемый тип цифровой подписи и саму подпись.
  2. Сервер подтверждает запрос и отвечает клиенту токеном запроса (англ. Request Token) и частью разделённого секрета.
  3. Клиент передаёт токен владельцу ресурсов (пользователю) и перенаправляет его на сервер для прохождения аутентификации.
  4. Сервер, получив от пользователя токен, запрашивает у него его логин и пароль, и в случае успешной аутентификации просит пользователя подтвердить доступ клиента к ресурсам (происходит авторизация), после чего пользователь перенаправляется сервером к клиенту.
  5. Клиент передаёт серверу токен запроса посредством протокола TLS и запрашивает доступ к ресурсам.
  6. Сервер подтверждает запрос и отвечает клиенту новым токеном доступа (англ. Access Token).
  7. Используя токен доступа, клиент обращается к серверу за ресурсами.
  8. Сервер подтверждает запрос и предоставляет ресурсы.

OAuth 2.0

Протокол OAuth 2.0 обратно не совместим с протоколом OAuth 1.0[1]. Вместо того, чтобы дополнить OAuth 1.0, было принято решение разработать другой протокол[16]. Поэтому принцип работы OAuth 1.0 и OAuth 2.0 отличается. Так в стандарте OAuth 2.0 описаны следующие потоки (сценарии взаимодействия сторон)[1]:

  • Поток неявного доступа (англ. Implicit Grant Flow)
Является самым коротким потоком протокола: пользователь сначала перенаправляется клиентом на сервер, чтобы разрешить доступ к ресурсам, а после того, как доступ будет получен, перенаправляется сервером обратно к клиенту[16].
  • Поток с кодом подтверждения (англ. Authorization Code Flow)
Отличие данного потока от потока неявного доступа заключается в дополнительном шаге аутентификации клиента[16].
  • Поток с обновляемым токеном (англ. Refreshing an Expired Access Token Flow)
Отличия этого потока от приведённого примера в следующем: на шаге 2 сервер помимо токена доступа, который имеет ограниченное время жизни, выдаёт токен обновления; на шаге 8 сервер проверяет, является ли токен доступа валидным (в смысле истечения времени жизни), и в зависимости от этого либо предоставляет доступ к ресурсам, либо требует обновления токена доступа (который предоставляется при предъявлении токена обновления).
  • Поток с предоставлением клиенту пароля (англ. Resource Owner Password Credentials Flow)
В этом потоке владелец ресурсов предоставляет клиенту логин и пароль, он передаёт их серверу и получает токен для доступа к ресурсам. Несмотря на то, что такой режим работы несколько противоречит концепции создания протокола, он описан в спецификации.
  • Поток клиентских полномочий (англ. Client Credentials Flow)
В данном режиме работы протокола предоставление сервером токена доступа происходит после передачи клиентом его пользователя и пароля, который был предварительно установлен сервером авторизации (в спецификации не оговорено, каким именно образом). Фактически, клиент сразу проходит как авторизацию, так и аутентификацию.

OAuth поддерживает два метода аутентификации сообщений от клиента: HMAC-SHA1 и RSA-SHA1. Есть возможность передавать сообщения без подписи, тогда в поле типа подписи указывается «plain text». Но в этом случае, согласно спецификации, соединение между клиентом и сервером должно устанавливаться через протокол SSL или TLS[5].

Примечания

  1. 1 2 3 4 5 D. Hardt, Ed. The OAuth 2.0 Authorization Framework. Introduction (англ.). Internet Engineering Task Force (October 2012). Проверено 30 октября 2015.
  2. ↑ E. Hammer-Lahav, Ed. The OAuth 1.0 Protocol (англ.) // IETF. — 2010. — April. — ISSN 2070-1721.
  3. 1 2 3 4 5 6 Gibbons K., Raw J. O., Curran K. Security Evaluation of the OAuth 2.0 Framework // Information Management and Computer Security — Emerald Group Publishing, 2014. — Vol. 22, Iss. 3. — ISSN 0968-5227; 1758-5805
  4. 1 2 3 Eran Hammer. The OAuth 1.0 Guide. History (англ.). Проверено 30 октября 2015.
  5. 1 2 3 4 5 6 E. Hammer-Lahav, Ed. The OAuth 1.0 Protocol (англ.). Internet Engineering Task Force. Проверено 8 ноября 2015.
  6. ↑ Eran Hammer. Introducing OAuth 2.0 (англ.) (недоступная ссылка). hueniverse.com. Проверено 30 октября 2015. Архивировано 15 января 2011 года.
  7. 1 2 Ryan Boyd. Introduction // Getting Started with OAuth 2.0. — 1-е изд. — 1005 Gravenstein Highway North, Sebastopol: O’Reilly Media, Inc., 2012. — С. 67. — 9—12, 23—24 с. — ISBN 978-1-449-31160-5.
  8. ↑ Status of RFC 6749 (англ.). rfc-editor. — current status of RFC 6749. Проверено 30 октября 2015.
  9. ↑ OAuth 2.0. Implementations (англ.). oauth.net. Проверено 30 октября 2015.
  10. ↑ Mail.ru.OAuth 2.0 как предчувствие. http://api.mail.ru/+(11 февраля 2011). Проверено 3 декабря 2015.
  11. ↑ Authentication - Facebook Developers. developers.facebook.com.
  12. ↑ Google Accounts Authentication and Authorization. developers.google.com.
  13. ↑ Eran Hammer. OAuth 2.0 and the Road to Hell (англ.). hueniverse. Проверено 14 июня 2017. Архивировано 25 марта 2013 года.
  14. ↑ Eran Hammer. OAuth 2.0 - Looking Back and Moving On (англ.). hueniverse. Проверено 30 октября 2015.
  15. ↑ D. Hardt. The OAuth 2.0 Authorization Framework: Bearer Token Usage draft-ietf-oauth-v2-bearer-23. Appendix B. Document History (англ.) (1 August 2012). Проверено 30 октября 2015.
  16. 1 2 3 4 5 6 7 Chen E. Y., Pei Y., Chen S. et al. OAuth Demystified for Mobile Application Developers // Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security — New York City: ACM, 2014. — P. 892–903. — ISBN 978-1-4503-2957-6 — doi:10.1145/2660267.2660323
  17. ↑ Eran Hammer. Terminology (англ.). hueniverse. Проверено 31 октября 2015.
  18. 1 2 3 Eran Hammer. Security Framework (англ.). hueniverse. Проверено 31 октября 2015.

Ссылки

Данная страница на сайте WikiSort.ru содержит текст со страницы сайта "Википедия".

Если Вы хотите её отредактировать, то можете сделать это на странице редактирования в Википедии.

Если сделанные Вами правки не будут кем-нибудь удалены, то через несколько дней они появятся на сайте WikiSort.ru .



Текст в блоке "Читать" взят с сайта "Википедия" и доступен по лицензии Creative Commons Attribution-ShareAlike; в отдельных случаях могут действовать дополнительные условия.

Другой контент может иметь иную лицензию. Перед использованием материалов сайта WikiSort.ru внимательно изучите правила лицензирования конкретных элементов наполнения сайта.

2019-2024
WikiSort.ru - проект по пересортировке и дополнению контента Википедии