Эта статья выставлена на рецензию

OpenID

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск
Логотип

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

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

Стандарт описывает процесс коммуникации Интернет-ресурсов (Relying Parties), требующих аутентификации, и Провайдеров OpenID (OpenID Providers). Существует несколько OpenID-провайдеров, которые предоставляют хостинг OpenID URL[2]. Аутентификацию OpenID используют в том числе Google, Yahoo!, AOL, LiveJournal, MySpace, IBM[3], Steam[4], Orange и VeriSign[5].

Сайты, поддерживающие её, часто помечаются логотипом системы, расположенным возле поля ввода пароля на странице входа [6].

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

Вход через OpenID[править | править вики-текст]

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

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

Чтобы пользователь смог пройти OpenID-авторизацию на сайте example.com с помощью своего идентификатора, например: pupkin.openid-provider.org, который он зарегистрировал у провайдера идентификации openid-provider.org, пользователь просто на example.com вводит свой OpenID в предлагаемую форму входа.

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

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

Вход через OpenID с точки зрения аутентифицирующей стороны[править | править вики-текст]

За обработку формы отвечает клиентская часть библиотеки OpenID[9]. В начале авторизации по OpenID, сайт example.com объявляет себя Зависимой стороной, и получает секретный код — описатель партнёра (associate handler) от openid-provider.org, который зависимая сторона сохраняет. В режиме checkid_setup зависимая сторона переадресует браузер пользователя к провайдеру. В данном случае браузер Пользователя переадресуется на openid-provider.org, где провайдер сможет опознать его [Пользователя].

Метод идентификации Пользователя провайдером может быть любым, но обычно OpenID провайдер запрашивает у Пользователя логин и пароль его учётной записи на сервере провайдера (затем, как правило, сохраняет сессию в cookie, как это делает большинство сайтов с парольным доступом). Затем провайдер спросит, доверяет ли Пользователь странице, указанной зависимой стороной для возврата пользователя после проверки подлинности, куда будет отправлена его информация (к примеру, http://example.com/openid-return.php). Если Пользователь ответит утвердительно, браузер с соответствующими подтверждениями перенаправляется на указанную страницу, и идентификация по OpenID почти готова к тому, чтобы быть признанной успешной. В случае недоверия Пользователя к указанной странице браузер всё равно перенаправляется туда же — однако зависимая сторона получает отказ на свой запрос, и, в свою очередь, отказывается впустить Пользователя.

Однако процесс входа всё ещё не завершён, потому что на данном этапе example.com должен удостовериться, что полномочия Пользователю выдал действительно openid-provider.org, а не сам Пользователь, например, взломщик, который зашёл на страницу подтверждения авторизации самостоятельно. Если стороны предварительно договорились о секретном ключе (shared secret см.выше), то зависимая сторона может проверить ключ, полученный вместе с полномочиями Пользователя по имеющейся у неё информации. Такая зависимая сторона называется хранящей состояние (stateful), так как она сохраняет секретный ключ между сессиями. В противоположность ей зависимая сторона без памяти (stateless) или немая (dumb) должна совершить ещё один фоновый запрос (check_authentication) для проверки того, что данные действительно пришли с сервера openid-provider.org.

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

OpenID не предоставляет собственных средств проверки подлинности Пользователя, но если провайдер идентификации использует сильное шифрование, OpenID может использоваться для защищённых транзакций банков и коммерческих интернет-сервисов[10].

Общее описание протокола[править | править вики-текст]

Возможности OpenID[править | править вики-текст]

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

Децентрализованность[править | править вики-текст]

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

Технологические требования[править | править вики-текст]

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

Устройство протокола[править | править вики-текст]

Терминология[править | править вики-текст]

  • Идентификатор (Identifier, далее ID) — «http» или «https» URI (URL) или XRI[11].
  • Провайдер OpenID (OpenID Provider, далее OP или провайдер) — сервер OpenID-аутентификации, который подтверждает Интернет-сервису (любому объекту, желающему проверить подлинность идентификатора) подлинность Идентификатора конечного пользователя.
  • URL конечной точки OP (OP Endpoint URL, далее OP URL) — URL, который принимает запросы аутентификации по протоколу OpenID и содержится в Предъявляемом Идентификаторе (HTTP или HTTPS).
  • OP Идентификатор (OP Identifier, далее OP ID) — идентификатор, предъявляемый конечным пользователем провайдеру OpenID для аутентификации на сервере провайдера OpenID.
  • Предъявляемый Идентификатор (User-Supplied Identifier, далее Предъявляемый ID) — идентификатор, который конечный пользователь предоставляет Сервису, это может быть OP URL. В случае использования OP URL Провайдер предоставляет возможность конечному пользователю передать Единый Идентификатор Интернет-сервису.
  • Единый Идентификатор(Claimed Identifier, далее Единый ID) — идентификатор единой учётной записи пользователя, хранящийся на сервере. Может быть использован в качестве идентификатора учётной записи в Интернет-сервисе. Предоставление этого идентификатора и есть основная цель протокола. Единый идентификатор может находиться в Предъявляемом Идентификаторе, либо может быть получен от OP.

Механизм работы[править | править вики-текст]

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

Уточним для третьего пункта, что OpenID-аутентификация поддерживает два алгоритма подписи:

В спецификации рекомендуется использовать HMAC-SHA256.

OpenID Foundation[править | править вики-текст]

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

Главными управляющими являются 4 члена сообщества и 8 корпоративных членов:

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

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

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

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

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

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

Deutsche Telekom — Торстен Лоддерштедт (англ. Torsten Lodderstedt)

Google — Эрик Сахс (англ. Eric Sachs)

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

PayPal — Фарханг Кассаи (англ. Farhang Kassaei)

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

Symantec — Поль Агбабян (англ. Paul Agbabian)

Verizon — Питер Типпетт (англ. Peter Tippett)

Yahoo — Дилан Кейси (англ. Dylan Casey)

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

История возникновения[править | править вики-текст]

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

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

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

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

История версий[править | править вики-текст]

OpenID 1.1[править | править вики-текст]

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

OpenID 2.0[править | править вики-текст]

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

OpenID Connect[править | править вики-текст]

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

Уязвимости[править | править вики-текст]

Фишинговые атаки[править | править вики-текст]

Некоторые интернет-пользователи считают, что протокол OpenID уязвим к фишинговым атакам, когда вместо OP злоумышленники направляют конечного пользователя на сайт с похожим дизайном. Конечный пользователь вводит свой OP ID, и злоумышленникам в руки попадает информация, с помощью которой они могут представляться Интернет-ресурсам конечным пользователем[18]. OpenID не содержит механизмов предотвращения фишинговых атак. Ответственность за фишинговые атаки перекладывается на провайдеров OpenID[11].

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

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

Делегирование OpenID[править | править вики-текст]

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

См. также[править | править вики-текст]

Примечания[править | править вики-текст]

  1. OpenID Authentication 2.0. Проверено 2016-19-12.
  2. Get an OpenID. Проверено 12 декабря 2016. Архивировано 26 февраля 2017 года.
  3. Technology Leaders Join OpenID Foundation.
  4. Steam Web API.
  5. get-an-openid.
  6. Logos and Badges. Проверено 12 декабря 2016.
  7. OpenID 2009 Year in Review. Проверено 2016-19-12.
  8. Use an OpenID Account.
  9. PHP/Ruby/Python/DotNet/Java OpenID Library. Архивировано 25 августа 2011 года.
  10. OpenID Book.
  11. 1 2 3 4 5 OpenID Authentication 2.0.
  12. Distributed Identity: Yadis. Проверено 12 декабря 2016.
  13. OpenID: an actually distributed identity system. Проверено 12 декабря 2016. Архивировано 24 сентября 2005 года.
  14. Sun OpenID: Non-Assertion Covenant.
  15. Trademark Assignment Abstract of Title.
  16. OpenID Authentication 1.1. Проверено 12 декабря 2016.
  17. Welcome to OpenID Connect. Проверено 12 декабря 2016.
  18. Phishing attacks.
  19. Tsyrklevich, Eugene. Single Sign-On for the Internet: A Security Story. Проверено 12 декабря 2016.
  20. Создание OpenID-адреса. Яндекс.
  21. Announcing Facebook Connect - Facebook for Developers (en-US). Facebook Developers. Проверено 9 ноября 2015.

Литература[править | править вики-текст]

  1. Mark Ciampa. Sequrity + Guide To Network Sequrity Fundamentals. — 2012. — С. 400.
  1. Refeeq ur Rehman, CISSP. OpenID Book. — 2007.

Ссылки[править | править вики-текст]