OpenID
| OpenID — открытый стандарт децентрализованной системы аутентификации, предоставляющей пользователю возможность создать единую учётную запись для аутентификации на множестве не связанных друг с другом интернет-ресурсов, используя услуги третьих лиц. Базовой функцией OpenID является предоставление портативного, клиент-ориентированного, цифрового идентификатора для свободного и децентрализованного использования. Стандарт описывает процесс коммуникации Интернет-ресурсов (Relying Parties), требующих аутентификации, и Провайдеров OpenID (OpenID Providers). Аутентификацию OpenID используют в том числе Google, Yahoo!, AOL, LiveJournal, MySpace, IBM, Steam, Orange и VeriSign. Сайты, поддерживающие её, часто помечаются логотипом системы, расположенным возле поля ввода пароля на странице входа. Существует несколько OpenID-провайдеров, которые предоставляют хостинг OpenID URL. На сайте, назовём его, к примеру, example.com, располагается форма входа, но вместо привычных полей логин и пароль в ней можно заполнить только одно — поле для ввода OpenID идентификатора. Зачастую рядом с таким полем располагается логотип OpenID. Чтобы пользователь смог пройти OpenID-авторизацию на сайте example.com с помощью своего идентификатора, например: pupkin.openid-provider.org, который он зарегистрировал у провайдера идентификации openid-provider.org, пользователь просто на example.com вводит свой OpenID в предлагаемую форму входа. Сайт зависимой стороны перенаправляет пользователя на сайт провайдера. Сайт провайдера запрашивает у пользователя подтверждение, действительно ли пользователь желает предоставить информацию о своей учётной записи. Если пользователь соглашается, то сайт провайдера перенаправляет пользователя обратно на сайт зависимой стороны. При обратном перенаправлении провайдер передаст информацию о пользователе зависимой стороне. Например, OpenID-провайдером является Живой Журнал, поэтому в качестве Open ID можно использовать адрес своего дневника в Live Journal. Для веб-разработчиков: за обработку формы отвечает клиентская часть библиотеки OpenID[6]. Декларируя возможность авторизации по OpenID, сайт example.com объявляет себя Зависимой стороной, и получает секретный код — описатель партнёра (associate handler) от openid-provider.org, который зависимая сторона сохраняет. В режиме 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 Интернет-ресурсы (Relying Parties) или Провайдеров OpenID (OpenID Providers). А конечный пользователь может свободно выбирать, какого Провайдера OpenID использовать, и сохранять Идентификатор в случае изменения Провайдера OpenID. Стандарт не требует JavaScript или современных браузеров, однако схема аутентификации хорошо совместима с концепцией «AJAX». Это значит, что конечный пользователь аутентифицируется Интернет-сервисом (любым объектом, желающим проверить подлинность идентификатора), не покидая текущую Web-страницу. OpenID-аутентификация использует только стандартные HTTP(S) запросы и ответы, поэтому он не требует специальных пользовательских приложений или какого-либо клиентского программного обеспечения. OpenID не привязан к использованию файлов cookie или к каким-либо другим механизмам управления сеансом. Различные расширения могут упростить использование OpenID, но не являются обязательными для использования стандарта. Идентификатор (Identifier, далее ID) — «http» или «https» URI (URL) или XRI. Провайдер OpenID (OpenID Provider, далее OP или провайдер) — сервер OpenID-аутентификации, который подтверждает Интернет-сервису (любому объекту, желающему проверить подлинность идентификатора) подлинность Идентификатора конечного пользователя. URL конечной точки OP (OP Endpoint URL, далее OP URL) — URL, который принимает запросы аутентификации по протоколу OpenID и содержится в Предъявляемом Идентификаторе (HTTP или HTTPS). OP Идентификатор (OP Identifier, далее OP ID) — идентификатор, предъявляемый конечным пользователем провайдеру OpenID для аутентификации на сервере провайдера OpenID. Предъявляемый Идентификатор (User-Supplied Identifier, далее Предъявляемый ID) — идентификатор, который конечный пользователь предоставляет Сервису, это может быть OP URL. В случае использования OP URL Провайдер предоставляет возможность конечному пользователю передать Единый Идентификатор Интернет-сервису. Единый Идентификатор(Claimed Identifier, далее Единый ID) — идентификатор единой учётной записи пользователя, хранящийся на сервере. Может быть использован в качестве идентификатора учётной записи в Интернет-сервисе. Предоставление этого идентификатора и есть основная цель протокола. Единый идентификатор может находиться в Предъявляемом Идентификаторе, либо может быть получен от OP. Конечный пользователь желает аутентифицироваться с помощью Предъявляемого ID на Интернет-сервисе, через свой браузер. Из Предъявляемого Идентификатора Интернет-сервис определяет URL Провайдера OpenID, используемого конечным пользователем. Предъявляемый ID может содержать только OP URL, который позволяет конечному пользователю, каким-то образом взаимодействуя с OP, передать Единый ID, или любую другую информацию о себе, Интернет-сервису. Переданная информация ещё не проверена Интернет-сервисом. (Не обязательно) Интернет-сервис и OP вместе создают общий секретный ключ для кода аутентификации сообщения по протоколу Диффи-Хеллмана. С помощью кода аутентификации сообщения Интернет-сервис аутентифицирует сообщение от OP без дополнительных запросов подлинности к провайдеру. Интернет-сервис перенаправляет браузер пользователя на OP с запросом аутентификации. Провайдер проверяет, авторизирован ли пользователь на сервере и хочет ли он аутентифицироваться на Интернет-сервисе. В общем случае, конечный пользователь предъявляет OP ID. Спецификация OpenID не описывает, каким образом конечный пользователь аутентифицируется у OP. OP перенаправляет браузер пользователя назад в Интернет-сервис с утверждением, что пользователь аутентифицирован или не аутентифицирован, и с результатом аутентификации — одноразовой меткой. Каждая аутентификация на сервере генерирует новую метку, которая не повторяется со сгенерированными ранее одноразовыми метками для того же пользователя. Одноразовая метка позволяет предотвратить атаки повторного воспроизведения. Интернет-сервис проверяет информацию, полученную от провайдера, включая возвращённый URL, информацию о пользователе, результат аутентификации на сервере — одноразовую метку, код аутентификации сообщения, с помощью секретного общего ключа, если он создавался на шаге 3, или, посылая прямой запрос OP. В случае успешной проверки Интернет-сервис аутентифицирует пользователя. Уточним для третьего пункта, что OpenID-аутентификация поддерживает два алгоритма подписи: HMAC-SHA1 — 160 bit key length ([RFC2104] и [RFC3174]) HMAC-SHA256 — 256 bit key length ([RFC2104] и [FIPS1802] В спецификации рекомендуется использовать HMAC-SHA256. OpenID Foundation – это некоммерческая организация, которая была сформирована, чтобы управлять авторскими правами, товарными знаками, маркетинговыми кампаниями и другой деятельностью, связанной с OpenID сообществом. Главными управляющими являются 4 члена сообщества и 8 корпоративных членов: Члены сообщества • Джон Бредли (Independent) (англ. John Bradley) • Джордж Флетчер (AOL) (англ. George Fletcher) • Майк Джоунс (Microsoft) (англ. Mike Jones) • Нат Сакимура (Nomura Research Institute) (англ. Nat Sakimura) Корпоративные члены • Deutsche Telekom – Торстен Лоддерстендт (англ. Torsten Lodderstedt) • Google – Эрик Сахс (англ. Eric Sachs) • Microsoft – Энтони Надалин (англ. Anthony Nadalin) • PayPal – Фарханг Кассае (англ. Farhang Kassaei) • Ping Identity – Памела Дингл (англ. Pamela Dingle) • Symantec – Пол Агбабиан (англ. Paul Agbabian) • Verizon – Питер Типпетт (англ. Peter Tippett) • Yahoo – Дилан Касе (англ. Dylan Casey) В США в марте 2008 года OpenID Foundation зарегистрировала товарный знак OpenID. Ранее он принадлежал компании NetMesh Inc. В Европе 31 августа 2007 года товарный знак OpenID был зарегистрирован OpenID Europe Foundation. В 2005 году Брэд Фицпатрик, известный как создатель LiveJournal, предложил интернет-сообществу концепцию единой учётной записи для разных интернет-ресурсов. Он предложил хранить свои учётную запись на одном сервере, а при регистрации на других интернет-ресурсах пользоваться этой учётной записью. В 2006 была создана первая спецификация OpenID Authentication 1.1. 5 декабря 2007 года Sun Microsystems, VeriSign и ряд компаний, участвующих в разработке OpenID, выпустили спецификацию OpenID 2.0 и официально заявили, что не будут выдвигать претензии в случае использования технологии OpenID кем-либо, если только действия лица, использующего технологию, не будут направлены против реализации технологии или на правообладание технологией. Товарный знак OpenID был зарегистрирован в США в марте 2008 года Основным отличием OpenID 1.1 от OpenID 2.0 для конечного пользователя является возможность использования XRI в качестве Идентификатора. OpenID 2.0, в отличие от OpenID 1.1, поддерживает алгоритм HMAC-SHA256 — 256-битной ([RFC2104] цифровой подписи, что делает аутентификацию OpenID-сообщений безопаснее. OpenID 2.0 совместим с OpenID 1.1 На этой ступени своего развития стандарт OpenID притерпел ряд грандиозных изменений. Разработчики отказались от формата XML в пользу JSON по стандарту JWT, что сильно упрощает внедрение OpenID Connect в различные приложения. Еще одним существенным отличием от предыдущих версий является новый подход в области децентрализации OpenID. Если раньше провайдером могли стать лишь крупные компании при соблюдении довольно серьезных требований, то сейчас в качестве OpenID провайдера может выступать чуть ли не все что угодно, начиная от вашего веб-сайта и заканчивая телефоном или стиральной машинкой. Некоторые интернет-пользователи считают, что протокол OpenID уязвим к фишинговым атакам, когда вместо OP злоумышленники направляют конечного пользователя на сайт с похожим дизайном. Конечный пользователь вводит свой OP ID, и злоумышленникам в руки попадает информация, с помощью которой они могут представляться Интернет-ресурсам конечным пользователем. OpenID не содержит механизмов предотвращения фишинговых атак. Ответственность за фишинговые атаки перекладывается на провайдеров OpenID. Если в процессе аутентификации конечного пользователя не используется SSL-шифрование, злоумышленник может перехватить URL и предъявить его Интернет-ресурсу вместо конечного пользователя и получить доступ к ресурсу от его имени. Существует возможность делегирования OpenID. Это означает, что владелец некоего доменного имени может использовать его в качестве синонима (алиаса) к уже существующему OpenID, полученному у любого провайдера OpenID. | |
|
| |
| Просмотров: 891 | | |
| Всего комментариев: 0 | |