OpenID

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

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

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

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

Протокол OpenID разработал Брэд Фицпатрик, один из создателей LiveJournal. Дальнейшие улучшения в спецификацию вносились многими специалистами, так как в отличие, к примеру, от TypeKey, OpenID изначально проектировался, как независимый от провайдера метод аутентификации. Для улучшения механизма, стимулирования разработчиков и скорейшего распространения проекта в августе 2006-го на развитие было выделено $50 000 — по $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. Декларируя возможность авторизации по 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, полученному у любого провайдера OpenID.

Критика

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

Аналоги

• TypeKey
• uID — универсальный логин (e-mail адрес), используемый в uNet-сообществе и большинстве сайтов системы uCoz.
• Google Friend Connect — платформа, позволяющая принимать авторизацию на сайте без регистрации. Авторизация по OpenID, Google, AIM и Yahoo

См. также

• OAuth
• Pavatar
• Технология единого входа

Ссылки

• Сайт проекта (англ.)
• OpenID Wiki (англ.)
• OpenID в энциклопедии сайтостроения
• Сообщество OpenID на Украине