OpenID (OpenID)

Логотип OpenID

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

Базовой функцией OpenID является предоставление портативного, клиент-ориентированного, цифрового идентификатора для свободного и децентрализованного использования.

Стандарт описывает процесс коммуникации интернет-ресурсов (Relying Parties), требующих аутентификации, и провайдеров OpenID (OpenID Providers). Существует несколько OpenID-провайдеров, которые предоставляют хостинг OpenID URL. Аутентификацию OpenID используют в том числе Google, Yahoo!, AOL, LiveJournal, MySpace, IBM, Steam и Orange. Расширение стандарта (the OpenID Attribute Exchange) облегчает передачу пользовательских данных, таких как имя или пол, от OpenID-провайдера до интернет-ресурса.

На декабрь 2009 года существовало более 1 миллиарда аккаунтов OpenID и около 9 миллионов сайтов, поддерживающих технологию OpenID.

Текущая версия стандарта, OpenID Connect 1.0, вышла в феврале 2014 года и была обновлена в ноябре 2014 года.

История возникновения

В 2005 году Брэд Фицпатрик, известный как создатель LiveJournal, работавший на то время в Six Apart, предложил интернет-сообществу концепцию единой учётной записи для разных интернет-ресурсов. Он предложил хранить свою учётную запись на одном сервере, а при регистрации на других интернет-ресурсах пользоваться этой учётной записью. Первоначально протокол называют Yadis (акроним от «Yet another distributed identity system»), название OpenID протокол получил уже после того, как Six Apart зарегистрировало доменное имя openid.net для своего проекта. Вскоре поддержка OpenID была реализована на LiveJournal, и эта технология быстро привлекла к себе внимание интернет-сообщества.

В 2006 была создана первая спецификация OpenID — OpenID Authentication 1.1.

5 декабря 2007 года Sun Microsystems, VeriSign и ряд компаний, участвующих в разработке OpenID, выпустили спецификацию OpenID 2.0 и официально заявили, что не будут выдвигать претензии в случае использования технологии OpenID кем-либо, если только действия лица, использующего технологию, не будут направлены против реализации технологии или на правообладание технологией.

Товарный знак OpenID был зарегистрирован в США в марте 2008 года.

Вход через OpenID с точки зрения конечного пользователя

На сайте, например, example.com, находится форма входа с единственным полем ввода для OpenID-идентификатора. Зачастую рядом с таким полем располагается логотип OpenID. Для того, чтобы авторизоваться на данном сайте с помощью своего идентификатора, например, pupkin.openid-provider.org, зарегистрированного у OpenID-провайдера openid-provider.org, пользователю необходимо ввести свой идентификатор в предлагаемую на сайте форму входа. После этого сайт example.com перенаправляет пользователя на сайт провайдера. Сайт провайдера запрашивает у пользователя подтверждение, действительно ли пользователь желает предоставить информацию о своей учётной записи. Если пользователь соглашается, то сайт провайдера перенаправляет пользователя обратно на сайт зависимой стороны. При обратном перенаправлении провайдер передаст информацию о пользователе зависимой стороне.

OpenID-провайдером, например, является Живой Журнал, поэтому в качестве OpenID-идентификатора можно использовать адрес своего дневника в Live Journal. 

Общее описание протокола

Возможности OpenID

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

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

Децентрализованность

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

Технологические требования

Стандарт не требует JavaScript или современных браузеров, однако схема аутентификации хорошо совместима с подходом AJAX. Это значит, что конечный пользователь может проходить аутентификацию на сайте, не покидая текущую страницу. В этом случае коммуникация интернет-ресурса с OpenID-провайдером будет проходить в фоновом режиме. OpenID-аутентификация использует только стандартные HTTP(S) запросы и ответы, поэтому стандарт не требует от пользователя установки дополнительного программного обеспечения. Для работы OpenID не требуется использовать cookie или какие-либо другие механизмы управления сессией. Различные расширения могут упростить использование OpenID, но не являются обязательными для использования стандарта.

Устройство протокола

Терминология

• Идентификатор (Identifier) — HTTP или HTTPS URI (URL) или XRI (начиная с OpenID 2.0). В протоколе используется несколько видов идентификаторов.
• Интернет-сервис (Relying Party) — веб-приложение, которое хочет проверить подлинность идентификатора пользователя.
• Провайдер OpenID (OpenID Provider) — сервер OpenID-аутентификации, который подтверждает интернет-сервису подлинность идентификатора конечного пользователя.
• URL конечной точки провайдера (OpenID Provider Endpoint URL) — URL, который принимает запросы аутентификации по протоколу OpenID и может быть получен из предъявляемого идентификатора.
• Идентификатор провайдера (OP Identifier) — идентификатор, по которому можно определить OpenID-провайдера.
• Предъявляемый идентификатор (User-Supplied Identifier) — идентификатор, предъявляемый конечным пользователем интернет-сервису. Предъявляемый идентификатор может совпадать с OP-идентификатором.
• Заявленный идентификатор (Claimed Identifier) — идентификатор, о владении которым заявляет пользователь. Проверка данного утверждения является главной целью протокола OpenID. Заявленный идентификатор может быть получен из предъявленного путём его нормализации.

Механизм работы

1. Конечный пользователь инициирует процесс аутентификации на интернет-сервисе. Для этого он вводит предъявляемый идентификатор в форму входа, представленную на сайте.
2. Из предъявляемого идентификатора интернет-сервис определяет URL конечной точки OpenID-провайдера, используемого конечным пользователем. Предъявляемый идентификатор может содержать только Идентификатор провайдера. В этом случае конечный пользователь указывает свой заявленный идентификатор, взаимодействуя с провайдером.
3. Опционально интернет-сервис и OpenID-провайдер создают общий секретный ключ для кода аутентификации сообщения по протоколу Диффи-Хеллмана. С помощью кода аутентификации сообщения интернет-сервис аутентифицирует сообщение от провайдера без дополнительных запросов к нему для проверки подлинности.
4. В режиме checkid_setup интернет-сервис перенаправляет браузер пользователя на сайт провайдера для дальнейшей аутентификации. В режиме checkid_immediate коммуникация браузера с провайдером происходит незаметно для пользователя.
5. Провайдер проверяет, авторизирован ли пользователь на сервере и хочет ли он аутентифицироваться на интернет-сервисе. Спецификация OpenID не описывает процесс аутентификации пользователя на стороне провайдера.
6. Провайдер перенаправляет браузер пользователя назад в интернет-сервис, передавая сервису результат аутентификации.
7. Интернет-сервис проверяет подлинность информации, полученной от провайдера, включая возвращённый URL, информацию о пользователе, одноразовую метку (nonce) и подпись сообщения. Если на шаге 3 был создан общий секретный ключ, то проверка происходит с помощью него. Если ключ создан не был, то интернет-сервис отправляет провайдеру дополнительный запрос (check_authentication) для проверки подлинности. В первом случае интернет-сервис называется немым (dumb), а во втором — зависимой стороной без памяти (stateless).
8. В случае успешной проверки интернет-сервис аутентифицирует пользователя.

OpenID Foundation

OpenID Foundation (OIDF) — это некоммерческая организация, которая была сформирована в июне 2007 года для того, чтобы управлять авторскими правами, товарными знаками, маркетинговыми компаниями и другой деятельностью, связанной с OpenID-сообществом.

Совет директоров организации составляют 4 члена сообщества и 8 корпоративных членов:

Члены сообщества

• Джон Бредли (Independent) (англ. John Bradley)

• Джордж Флетчер (AOL) (англ. George Fletcher)

• Майк Джонс (Microsoft) (англ. Mike Jones)

• Нат Сакимура (Nomura Research Institute) (англ. Nat Sakimura)

Корпоративные члены

• Google — Адам Доус (англ. Adam Dawes)

• Microsoft — Энтони Надалин (англ. Anthony Nadalin)

• Ping Identity — Памела Дингл (англ. Pamela Dingle)

• Symantec — Брайан Берлинер (англ. Brian Berliner)

• Verizon — Бьорн Хельм (англ. Bjorn Hjelm)

• Oracle — Пратик Мишра (англ. Prateek Mishra)

• VMware— Ашиш Джейн (англ. Ashish Jain)

• Департамент здравоохранения и социальных служб США — Дэбби Бучи (англ. Debbie Bucci)

В США в марте 2008 года OpenID Foundation зарегистрировала товарный знак OpenID. Ранее он принадлежал компании NetMesh Inc. В Европе 31 августа 2007 года товарный знак OpenID был зарегистрирован OpenID Europe Foundation.

История версий

OpenID 1.1

OpenID-аутентификация предоставляет конечному пользователю способ доказать свою личность на сайте без ввода его пароля, e-mail или другой информации, которую он не желает вводить на данном ресурсе. Спецификация OpenID 1.1 не предусматривает какого-либо механизма для обмена информацией о профиле конечного пользователя.

OpenID 2.0

Основным отличием OpenID 2.0 от OpenID 1.1 для конечного пользователя является возможность использования XRI в качестве идентификатора. OpenID 2.0, в отличие от OpenID 1.1, поддерживает алгоритм HMAC-SHA256 — 256-битной ([RFC2104] цифровой подписи, что делает аутентификацию OpenID-сообщений безопаснее. В OpenID 2.0 появился механизм расширений, позволяющий добавлять к аутентификационным запросам и ответам дополнительную информацию.

OpenID 2.0 совместим с OpenID 1.1.

OpenID Connect

Третье поколение OpenID-технологии, которое представляет собой аутентификационную надстройку над протоколом авторизации OAuth 2.0. OpenID Connect позволяет интернет-ресурсам проверить личность пользователя на основе аутентификации, выполненной авторизационным сервером. Для работы используется RESTful API, описанный в спецификации. Также в OpenID Connect определены дополнительные механизмы для надёжного шифрования и цифровой подписи. Стандарт позволяет использовать дополнительные возможности, такие как управление сессиями и обнаружение OpenID-провайдеров.

В то время как для интеграции стандарта OAuth 1.0a с OpenID 2.0 требуется расширение, в OpenID Connect возможности OAuth 2.0 уже интегрированы с самим протоколом.

Уязвимости

Фишинговые атаки

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

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

OpenID не содержит механизмов предотвращения фишинговых атак. Ответственность за фишинговые атаки перекладывается на провайдеров OpenID.

Для защиты от фишинга пользователи могут использовать дополнительное программное обеспечение, например Microsoft’s Identity Selector. Также существуют решения, не требующие установки дополнительного программного обеспечения, например BeamAuth, использующий для своей работы закладки в браузере.

Атака «Человек посередине» при незащищённом соединении

Если для защиты соединения между пользователем и OpenID-провайдером не используются протоколы TLS/SSL, то на последней стадии аутентификации возникает уязвимость. Для перенаправления пользователя от себя к интернет-сервису провайдер передаёт пользователю специальный URL. Проблема заключается в том, что любой, кто может получить этот URL (например, путём сниффинга витой пары), может воспроизвести его и получить доступ на сайт как пользователь. Некоторые провайдеры для защиты от этой атаки используют одноразовый код (Nonce), который позволяет воспользоваться данным URL только один раз. Нонс-решение работает только в случае, когда Пользователь первым использует URL. Однако злоумышленник, который прослушивает канал связи и находится между пользователем и провайдером, может получить URL и немедленно прервать TCP-соединение пользователя, а затем выполнить атаку. Таким образом, одноразовые коды защищают только от пассивных злоумышленников, но не могут предотвратить атак активного злоумышленника. Использование TLS / SSL в процессе аутентификации устраняет этот риск.

Переиспользование идентификатора

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

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

Ошибки аутентификации

В 2012 году исследователи опубликовали работу, описывающую две уязвимости в OpenID. Обе уязвимости позволяют злоумышленнику получить доступ к аккаунту жертвы.

Первая уязвимость использует OpenID Attribute Exchange. Проблема заключается в том, что некоторые интернет-сервисы не проверяют данные, переданные через Attribute Exchange. Если Attribute Exchange используется для передачи нечувствительной к подмене информации о пользователе (например, пол), то данной уязвимостью воспользоваться не удастся. Однако Attribute Exchange может также использоваться для передачи, например, email пользователя. Злоумышленник осуществляет попытку аутентификации на сайте зависимой стороны и добавляет в ответ провайдера email жертвы. Если зависимая сторона не проверяет подлинность этой информации, то злоумышленник будет идентифицирован как жертва. Так можно получить доступ к любому зарегистрированному аккаунту. Согласно отчёту исследователей, этой атаке были подвержены многие популярные сайты, включая Yahoo! Mail.

Вторая уязвимость связана с ошибкой на стороне провайдера и тоже позволяет получить доступ к аккаунту на сайте зависимой стороны. Ответ провайдера содержит поле openid.ext1.value.email, которое обрабатывается зависимой стороной как email пользователя. Однако тип данных, который добавляется провайдером в данное поле может контролироваться злоумышленником - запрос к провайдеру содержит поле type.email с ссылкой на схему, описывающую данное поле. Атакующий может добавить в type.email ссылку на схему, описывающую имя пользователя. Если злоумышленник может зарегистрироваться на сайте провайдера с именем, например, [email protected], то провайдер добавит это имя в поле openid.ext1.value.email и зависимая сторона будет считать, что аккаунт с данным email принадлежит злоумышленнику. Уязвимыми были признаны реализации Google и Paypal.

OpenID опубликовала отчёты по обеим уязвимостям, и были выпущены обновления, исправляющие их.

См. также

• ResearcherID
• SQRL

Литература

• OpenID Authentication 2.0 Specification (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 22 октября 2011 года.

• Microsoft and Google Both Ship OpenID (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 24 июня 2017 года.

• Technology Leaders Join OpenID Foundation (англ.). http://www-03.ibm.com/. IBM. Дата обращения: 5 декабря 2017. Архивировано 10 февраля 2008 года.

• Документация Steam Web API  (рус.). http://steamcommunity.com/. Steam. Дата обращения: 5 декабря 2017. Архивировано 10 февраля 2012 года.

• OpenID Attribute Exchange 1.0 (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 20 ноября 2017 года.

• OpenID 2009 Year in Review (англ.). http://openid.net/. OpenID Foundation (15 декабря 2009). Дата обращения: 5 декабря 2017. Архивировано 3 июля 2017 года.

• OpenID Connect Core 1.0 (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 18 декабря 2014 года.

• Errata to OpenID Connect Specifications Approved (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 3 декабря 2014 года.

• Brad Fitzpatrick. Distributed Identity: Yadis (англ.). http://lj-dev.livejournal.com/ (16 мая 2005). Дата обращения: 5 декабря 2017. Архивировано 20 июля 2017 года.

• Brad Fitzpatrick. OpenID: an actually distributed identity system (англ.). http://www.danga.com/ (14 июля 2005). Дата обращения: 5 декабря 2017. Архивировано из оригинала 24 сентября 2005 года.

• OpenID Authentication 1.1 Specification (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 18 ноября 2017 года.

• OpenID.sun.com is open for business (англ.). https://blogs.oracle.com/. Oracle (6 июня 2007). Дата обращения: 5 декабря 2017. Архивировано 1 декабря 2017 года.

• USPTO Assignments on the Web - OpenID (англ.). http://assignments.uspto.gov/. United States Patent and Trademark Office. Дата обращения: 5 декабря 2017. Архивировано 10 октября 2013 года.

• What is OpenID? (англ.). https://www.livejournal.com/. LiveJournal. Дата обращения: 27 июня 2005. Архивировано 30 июня 2005 года.

• What is OpenID? (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 1 декабря 2017 года.

• OpenID Foundation (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 23 ноября 2017 года.

• OpenID Foundation Leadership (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 24 июня 2014 года.

• Welcome to OpenID Connect (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 12 декабря 2017 года.

• Bart van Delft and Martijn Oostdijk. A security analysis of OpenID. — Springer. — С. 73—84.

• Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID (англ.). http://www.tetraph.com/. Teltraph. Дата обращения: 5 декабря 2017. Архивировано 9 октября 2017 года.

• Ben Adida. Beamauth: Two-factor Web Authentication with a Bookmark. — ACM. — С. 48-57. — ISBN 9781595937032. — doi:10.1145/1315245.1315253.

• Eugene Tsyrklevich. Single Sign-On for the Internet: A Security Story. — BlackHat USA.

• Rui Wang, Shuo Chen, XiaoFeng Wang. Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services. — Microsoft Research.

• Attribute Exchange Security Alert (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 31 июля 2017 года.

• Vulnerability report: Data confusion (англ.). http://openid.net/. OpenID Foundation. Дата обращения: 5 декабря 2017. Архивировано 5 сентября 2019 года.

• Announcing Facebook Connect - Facebook for Developers (англ.). https://developers.facebook.com/. Facebook Developers. Дата обращения: 5 декабря 2017. Архивировано 26 августа 2017 года.