OpenID | это... Что такое OpenID? (original) (raw)

Логотип

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

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

Существует несколько OpenID-провайдеров, которые предоставляют хостинг OpenID URL.

Содержание

История развития

Протокол OpenID разработал Брэд Фицпатрик, один из создателей LiveJournal. Дальнейшие улучшения в спецификацию вносились многими специалистами, так как в отличие, к примеру, от TypeKey, OpenID изначально проектировался, как независимый от провайдера метод аутентификации. Для улучшения механизма, стимулирования разработчиков и скорейшего распространения проекта в августе 2006-го на развитие было выделено 50000—по50 000 — по 50000—по5 000 каждому из десяти крупных opensource-проектов, задействовавших поддержку OpenID. Начиная с версии 1.1, OpenID использует протокол Yadis. В настоящее время закончена работа над версией 2.0.

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

Конечный пользователь

лицо, которое хочет идентифицировать себя на сайте Зависимой стороны

Идентификатор

URI или XRI, предоставленный провайдером для того, чтобы пользователь мог идентифицировать себя на сайте Зависимой стороны.

Зависимая сторона

лицо, желающее проверить подлинность Идентификатора

Потребитель

устаревшее название Зависимой стороны

Провайдер идентификации или OpenID провайдер

лицо, предоставляющее Пользователям сервис регистрации и предоставляющее Зависимой стороне сервис проверки подлинности Идентификаторов

Сервер или сервер-агент

сервер, проверяющий Идентификатор Конечного пользователя. Это может быть личный сервер пользователя (например, блог) или сервер Провайдера идентификации.

Агент пользователя

программа (как правило, браузер), используемая клиентом для доступа к Провайдеру идентификации или к Зависимой стороне

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

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

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

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

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

Вход через OpenID с точки зрения зависимой стороны

Для веб-разработчиков: за обработку формы отвечает клиентская часть библиотеки OpenID[1]. Декларируя возможность авторизации по OpenID, сайт example.com объявляет себя Зависимой стороной в протоколе OpenID.

Если идентификатор представляет собой URL, то первое, что делает зависимая сторона (example.com) — приводит его к нормальному виду, то есть к виду http://pupkin.openid-provider.org/. В соответствии с OpenID 1.0 зависимая сторона запрашивает веб-страницу по этому адресу и через HTML тег находит URL сервера-провайдера OpenID, например, http://openid-provider.org/openid-auth.php. Зависимая сторона (клиент) также проверяет, стоит ли ему использовать делегированный идентификатор (см.ниже). С версии OpenID 2.0 зависимая сторона проводит инспекцию запрашивая XRDS документ (который также называют Yadis документом) с типом application/xrds+xml, который может располагаться по введенному URL, и всегда доступен для введённого XRI.

Зависимая сторона может обмениваться информацией с провайдером идентификации двумя способами:

Большей популярностью в Интернете пользуется второй способ. Кроме того, checkid_immediate может откатиться к использованию checkid_setup, если операция входа не может быть проведена автоматически.

Сначала (необязательно) зависимая сторона и провайдер согласовывают shared secret или секретный код — описатель партнёра (associate handler), который зависимая сторона сохраняет. В режиме 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 может использоваться для защищённых транзакций банков и коммерческих интернет-сервисов.

Простое Регистрационное Расширение

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

Делегирование OpenID

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

Критика

Примечания

  1. ↑ PHP/Ruby/Python/DotNet/Java OpenID Library. Архивировано из первоисточника 25 августа 2011.

Аналоги

См. также

Ссылки

Просмотр этого шаблона Протоколы аутентификации и обмена ключами
С симметричными алгоритмами Wide-Mouth Frog • Yahalom • Протокол Нидхема — Шрёдера • Протокол Отвея — Рииса • Kerberos • Протокол Ньюмана — Стабблбайна
С симметричными и асимметричными алгоритмами DASS • Протокол Деннинга — Сакко • Протокол Ву — Лама • SPKM
Протоколы и сервисы, используемые в Internet OAuth • OpenID • Windows Live ID