28-06-2023
OpenID — это открытая децентрализованная система, которая позволяет пользователю использовать единую учётную запись для аутентификации на множестве не связанных друг с другом сайтов, порталов, блогов и форумов.
Сайты, поддерживающие её, часто помечаются логотипом системы, расположенным возле поля ввода пароля на странице входа.
Существует несколько OpenID-провайдеров, которые предоставляют хостинг OpenID URL.
Содержание |
Протокол OpenID разработал Брэд Фицпатрик, один из создателей LiveJournal. Дальнейшие улучшения в спецификацию вносились многими специалистами, так как в отличие, к примеру, от TypeKey, OpenID изначально проектировался, как независимый от провайдера метод аутентификации. Для улучшения механизма, стимулирования разработчиков и скорейшего распространения проекта в августе 2006-го на развитие было выделено $50 000 — по $5 000 каждому из десяти крупных opensource-проектов, задействовавших поддержку OpenID. Начиная с версии 1.1, OpenID использует протокол Yadis. В настоящее время закончена работа над версией 2.0.
На сайте, назовём его, к примеру, example.com
, располагается форма входа, но вместо привычных полей логин и пароль, в ней можно заполнить только одно — поле для ввода OpenID идентификатора. Зачастую рядом с таким полем располагается логотип OpenID.
Чтобы пользователь Вася Пупкин смог пройти OpenID-авторизацию на сайте example.com
с помощью своего идентификатора pupkin.openid-provider.org
, который он зарегистрировал у провайдера идентификации openid-provider.org
, Вася просто на example.com
вводит свой OpenID в предлагаемую форму входа.
Сайт зависимой стороны перенаправляет пользователя на сайт провайдера. Сайт провайдера запрашивает у пользователя подтверждение, действительно ли пользователь желает предоставить информацию о своей учётной записи. Если пользователь соглашается, то сайт провайдера перенаправляет пользователя обратно на сайт зависимой стороны. При обратном перенаправлении, провайдер передаст информацию о пользователе зависимой стороне.
Например, OpenID-провайдером является Живой Журнал, поэтому в качестве Open ID можно использовать адрес своего дневника в ЖЖ.
Для веб-разработчиков: за обработку формы отвечает клиентская часть библиотеки OpenID[1]. Декларируя возможность авторизации по OpenID, сайт example.com
объявляет себя Зависимой стороной в протоколе OpenID.
Если идентификатор представляет собой URL, то первое, что делает зависимая сторона (example.com
) — приводит его к нормальному виду, то есть к виду http://pupkin.openid-provider.org/
. В соответствии с OpenID 1.0 зависимая сторона запрашивает веб-страницу по этому адресу и через HTML тег <link> находит URL сервера-провайдера OpenID, например, http://openid-provider.org/openid-auth.php
. Зависимая сторона (клиент) также проверяет, стоит ли ему использовать делегированный идентификатор (см.ниже). С версии OpenID 2.0 зависимая сторона проводит инспекцию запрашивая XRDS документ (который также называют Yadis документом) с типом application/xrds+xml
, который может располагаться по введенному URL, и всегда доступен для введённого XRI.
Зависимая сторона может обмениваться информацией с провайдером идентификации двумя способами:
checkid_immediate
— машинно-ориентированный, в котором обмен информации между серверами идёт в фоне, без ведома пользователя;checkid_setup
— где пользователь напрямую обращается к сайту провайдера идентификации, используя тот же браузер, с которого он заходит на сайт зависимой стороны.Большей популярностью в Интернете пользуется второй способ. Кроме того, 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.
Протоколы аутентификации и обмена ключами | |
---|---|
С симметричными алгоритмами | |
С симметричными и асимметричными алгоритмами | |
Протоколы и сервисы, используемые в Internet |
OAuth • OpenID • Windows Live ID |
OpenID.