Интернет магазин китайских планшетных компьютеров

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

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

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

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

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

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

Сначала зависимая сторона и провайдер согласовывают shared secret или секретный код — описатель партнёра, который зависимая сторона сохраняет. В режиме checkid_setup зависимая сторона переадресует браузер пользователя к провайдеру. В данном случае браузер Васи переадресуется на openid-provider.org, где провайдер сможет опознать Васю.

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

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

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

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