OpenID

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

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

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

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

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

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

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

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

OpenID 2.0 совместим с OpenID 1.1[23].

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

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

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

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

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

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

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

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

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

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

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

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

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