OAuth


OAuth
Логотип OAuth

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

Содержание

Преимущества OAuth-авторизации

Безопасность

При разработке приложения не нужно заботиться об обеспечении конфиденциальности логина и пароля пользователя. Логин и пароль не передаются приложению, а следовательно, не могут попасть в руки злоумышленников.

Повышение лояльности пользователей

У пользователя больше оснований доверять приложению, поскольку пользователь может быть уверен, что несанкционированный доступ к его личным данным невозможен. Не владея логином и паролем пользователя, приложение сможет выполнять только те действия с данными, которые разрешил пользователь, и никакие другие.

Удобство для пользователей

Если сам пользователь уже авторизован на Яндексе (например, вошел в Почту), ему не нужно вводить логин и пароль на Яндексе перед выдачей разрешения приложению. Отсутствие необходимости часто вводить логин и пароль особенно актуально для пользователей мобильных приложений.

История

OAuth 1.0

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

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

15 апреля 2009 года Twitter предложил своим пользователям решение, позволяющее делегировать третьесторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Sign-in with Twitter» и было основано на OAuth. Это событие стало поводом для первого широкого исследования протокола на уязвимости, и через несколько дней был обнаружен потенциальный эксплоит, затрагивающий все существующие реализации OAuth. После этого, 23 апреля сообществом разработчиков было выпущено первое дополнение безопасности к протоколу, которое вошло в обновленную спецификацию OAuth Core 1.0 Revision A, опубликованную 24 июня.

В апреле 2010 года был выпущен информационный документ RFC 5849[1], посвященный стандарту OAuth. [2]

OAuth 2.0

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

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

  • 6 новых потоков.
Поток пользователя – агента (User-Agent Flow)  — для клиентов, работающих внутри агента пользователя (обычно веб-браузер).
Поток веб – сервера (Web Server Flow) — для клиентов, которые являются частью веб-приложения сервера, доступные через запросы HTTP.
Поток устройства (Device Flow) — подходит для клиентов, выполняющихся на ограниченных устройствах, но там, где конечный пользователь имеет отдельный доступ к браузеру на другом компьютере или устройстве.
Поток имени пользователя и пароля(Username and Password Flow) — используется в тех случаях, когда пользователь доверяет клиенту обрабатывать свои полномочия, но он по-прежнему нежелательно разрешит клиенту сохранить имя и пароль пользователя. Этот поток подходит только когда есть высокая степень доверия между пользователем и клиентом.
Поток клиентских полномочий (Client Credentials Flow) — клиент использует свои полномочия для получения токена.
Поток утверждения (Assertion Flow) — клиент представляет утверждение, такие как утверждение SAML к серверу авторизации в обмен на токен.
Приложения, работающие на настольном компьютере или мобильном устройстве может быть реализованы с использованием выше сказанных потоков.
  • Токен на предъявителя.
Метод авторизации аналогичен существующему способу авторизации с помощью cookie. В этом случае токен непосредственно используется как секрет (сам факт наличия токена авторизует клиента) и передается через HTTPS. Это позволяет получать доступ к API посредством простых скриптов (например, с использованием cURL).
  • Упрощенная подпись.
Подпись была значительно упрощена, чтобы устранить необходимость в специальном анализе, кодированиях и сортировках параметров.
  • Короткоживущие токены с долговременной авторизацией.
Вместо выдачи долгоживущего токена (который за длительное время может быть скомпрометирован), сервер предоставляет кратковременный доступ и долговременную возможность обновлять токен без участия пользователя.
  • Разделение ролей.
За авторизацию и за предоставление доступа к API могут отвечать разные сервера.

Стоит отметить, что, хотя стандарт OAuth 2.0 ещё не утвержден, он уже используется некоторыми сервисами. Например, Graph API социальной сети Facebook поддерживает только OAuth 2.0.

Отличие OAuth от OpenID

Существует ошибочное мнение, что OAuth является расширением протокола OpenID. На самом деле это не так. Хотя OpenID и OAuth имеют много общего, последний является самостоятельным протоколом, никак не связанным с OpenID.

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

OpenID является средством аутентификации: с помощью этой системы можно удостовериться, что пользователь — именно тот, за кого себя выдает. Какие действия сможет совершать пользователь, прошедший аутентификацию посредством OpenID, определяется стороной, проводящей аутентификацию.

Термины

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

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

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

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

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

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

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

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

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

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

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

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

OAuth используется три вида полномочий: учетные данные клиента (consumer key and secret или client credentials), временные учетные данные (request token and secret или temporary credentials) и токены (access token and secret или token credentials).

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

Токен используется вместо имени и пароля владельца ресурса. Владелец ресурса не поделится своими учетными данными с клиентом, а разрешает серверу выдавать клиенту токен - специальный класс учетных данных, которые представляют доступ гранта. Клиент использует токен для доступа к защищенному ресурсу, не зная пароля владельца ресурсов.

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

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

Как работает OAuth

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

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

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

Данный пример описывает поток с кодом подтверждения (Authorization Code Flow). Помимо этого в стандарте OAuth 2.0 описаны следующие потоки:

  • Поток неявного доступа (Implicit Grant Flow)
Отличие от потока с кодом подтверждения заключается в том, что клиент не проходит аутентификацию на сервере и токен доступа выдается сервером после запроса авторизации.
  • Поток с обновляемым токеном (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.

Порталы, использующие OAuth

Дискуссия

В июле 2012 года, Эран Хаммер (Eran Hammer), действующий редактор стандарта OAuth 2.0, объявил об уходе с поста после трех лет работы над новым стандартом, и попросил вычеркнуть своё имя из спецификаций. Он говорил о своих взглядах на своем сайте[21]. Он позже выступил с докладом. [22].

Девид Рекордон (англ. David Recordon) позже также вычеркнул своё имя из спецификаций без указания причин. Дик Хардт стал редактором стандарта OAuth2.0, и несмотря на взгляды Эрана Хаммера структура OAuth 2.0 было опубликована в RFC 6749 2012 года.

Примечания

См. также

Ссылки


Wikimedia Foundation. 2010.

Смотреть что такое "OAuth" в других словарях:

  • OAuth — (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g., photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically… …   Wikipedia

  • OAuth — Logo OAuth ist ein offenes Protokoll, das eine standardisierte, sichere API Autorisierung für Desktop , Web und mobile Anwendungen erlaubt. Es wurde von Blaine Cook und Chris Messina initiiert. Ein Endbenutzer (User) kann mit Hilfe dieses… …   Deutsch Wikipedia

  • OAuth — est un protocole libre, créé par Blaine Cook et Chris Messina, qui permet l authentification à une API sécurisée d une façon simple et standard depuis son bureau ou une application web. Pour les développeurs d une application accédant à une API,… …   Wikipédia en Français

  • OAuth — (Open Authorization) es un protocolo abierto, propuesto por Blaine Cook y Chris Messina, que permite autorización segura de un API de modo estándar y simple para aplicaciones de escritorio, móviles, y web. Para desarrolladores de consumidores,… …   Wikipedia Español

  • XRDS — (Kurzform für: eXtensible Resource Descriptor Sequence) ist ein XML Format, um Metadaten über eine Web Resource zu beschreiben und abrufbar zu machen (engl. „Discovery ) – insbesondere Dienste, die unter dieser Ressource verfügbar sind (engl.… …   Deutsch Wikipedia

  • Distributed social network — A distributed social network is an Internet social network service that is decentralized and distributed across different providers. The emphasis of the distribution is on portabilitya[›], interoperability and federation capability. It contrasts… …   Wikipedia

  • OpenID — The OpenID logo OpenID is an open standard that describes how users can be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital… …   Wikipedia

  • Аутентификация в Интернете — Аутентификация – это проверка подлинности предъявленного пользователем идентификатора. Аутентификация требуется при доступе к таким интернет сервисам, как: электронная почта веб форумы социальные сети интернет банкинг платежные системы… …   Википедия

  • Ma.gnolia — Infobox Website name = Magnolia caption = url = http://ma.gnolia.com type = Online social bookmarking registration = Optional owner = Gnolia Systems launch date = 2006 [cite web |url=http://www.techcrunch.com/2005/10/22/magnolia more social… …   Wikipedia

  • XRDS — (eXtensible Resource Descriptor Sequence) is an XML format for discovery of metadata about a resource – in particular discovery of services associated with the resource, a process known as service discovery. For example, a website offering OpenID …   Wikipedia

Книги