- 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[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, полученному у любого провайдера OpenID.
Критика
- Провайдер OpenID может представиться своим пользователем. Это возможно или в случае недобропорядочности провайдера, или в случае его взлома.
- Пользователь должен доверять провайдеру, так как тот знает, на какие сайты он входил используя OpenID. Хотя, с другой стороны, провайдер обычно и пользователю OpenID даёт возможность проконтролировать, на каких сайтах был использован его логин, и это, например, позволяет пользователю заметить кражу пароля.
- В OpenID не встроена защита от фишинга (для ввода пароля пользователя могут не перенаправить на страницу провайдера, а показать поддельную страницу, похожую на страницу провайдера). Однако многие провайдеры и дополнительные программы (например, расширения для браузера Firefox) предоставляют эту защиту.
Примечания
- ↑ PHP/Ruby/Python/DotNet/Java OpenID Library. Архивировано из первоисточника 25 августа 2011.
Аналоги
- TypeKey
- uID — универсальный логин (e-mail адрес), используемый в uNet-сообществе и большинстве сайтов системы uCoz.
- Google Friend Connect — платформа, позволяющая принимать авторизацию на сайте без регистрации. Авторизация по OpenID, Google, AIM и Yahoo
См. также
Ссылки
- Сайт проекта. Архивировано из первоисточника 28 ноября 2012. (англ.)
- OpenID Wiki. Архивировано из первоисточника 28 ноября 2012. (англ.)
- OpenID в энциклопедии сайтостроения. Архивировано из первоисточника 28 ноября 2012.
Протоколы аутентификации и обмена ключами С симметричными алгоритмами Wide-Mouth Frog • Yahalom • Протокол Нидхема — Шрёдера • Протокол Отвея — Рииса • Kerberos • Протокол Ньюмана — Стабблбайна
С симметричными и асимметричными алгоритмами Протоколы и сервисы, используемые в Internet OAuth • OpenID • Windows Live ID
Категории:- Аутентификация
- Уникальные идентификаторы
- Интернет
Wikimedia Foundation. 2010.