OpenID - OpenID

Логотип OpenID

OpenID - это открытый стандартный и децентрализованный протокол аутентификации , продвигаемый некоммерческой организацией OpenID Foundation . Он позволяет пользователям проходить аутентификацию с помощью взаимодействующих сайтов (известных как проверяющие стороны или RP) с использованием службы стороннего поставщика удостоверений (IDP), устраняя необходимость для веб-мастеров предоставлять свои собственные специальные системы входа и позволяя пользователям входить в систему. несколько несвязанных веб-сайтов без необходимости иметь для каждого отдельную личность и пароль. Пользователи создают учетные записи, выбирая поставщика удостоверений OpenID , а затем используют эти учетные записи для входа на любой веб-сайт, который принимает аутентификацию OpenID. Несколько крупных организаций выпускают или принимают идентификаторы OpenID на своих веб-сайтах.

Стандарт OpenID обеспечивает основу для взаимодействия, которое должно происходить между поставщиком удостоверений и принимающей стороной OpenID (« полагающаяся сторона »). Расширение стандарта (OpenID Attribute Exchange) облегчает передачу пользовательских атрибутов, таких как имя и пол, от провайдера идентификации OpenID к проверяющей стороне (каждая полагающаяся сторона может запрашивать другой набор атрибутов, в зависимости от своих требований) . Протокол OpenID не полагается на центральный орган для аутентификации личности пользователя. Более того, ни службы, ни стандарт OpenID не могут предписывать определенные средства аутентификации пользователей, допускающие различные подходы, от обычных (таких как пароли) до новаторских (таких как смарт-карты или биометрия).

Последней версией OpenID является OpenID 2.0, доработанная и опубликованная в декабре 2007 года. Термин OpenID может также относиться к идентификатору, указанному в стандарте OpenID; эти идентификаторы принимают форму уникального универсального идентификатора ресурса (URI) и управляются неким «поставщиком OpenID», который обрабатывает аутентификацию.

Принятие

По состоянию на март 2016 года в Интернете насчитывалось более 1 миллиарда учетных записей с поддержкой OpenID (см. Ниже), и примерно 1100 934 сайта интегрировали поддержку клиентов OpenID: AOL , Flickr , Google , Amazon.com , Canonical (название поставщика Ubuntu One ), LiveJournal , Microsoft (имя поставщика учетной записи Microsoft ), Mixi , Myspace , Novell , OpenStreetMap , Orange , Sears , Sun , Telecom Italia , Universal Music Group , VeriSign , WordPress , Yahoo! , BBC , IBM , PayPal и Steam , хотя некоторые из этих организаций также имеют собственное управление аутентификацией.

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

Facebook и раньше использовал OpenID, но перешел на Facebook Connect . Blogger также использовал OpenID, но с мая 2018 года его больше не поддерживает.

Технический обзор

Конечный пользователь является лицом , которое хочет утвердить определенную идентичность. Зависимая сторона (RP) представляет собой веб - сайт или приложение , которое хочет проверить идентификатор конечного пользователя. Другие термины для этой стороны включают «поставщик услуг» или уже устаревший «потребитель». Поставщик удостоверений или поставщик OpenID (OP) - это служба, специализирующаяся на регистрации URL-адресов OpenID или XRI. OpenID позволяет конечному пользователю общаться с проверяющей стороной. Эта связь осуществляется посредством обмена идентификатором или OpenID , который представляет собой URL-адрес или XRI, выбранный конечным пользователем для обозначения личности конечного пользователя. Провайдер идентификации обеспечивает аутентификацию OpenID (и, возможно, другие услуги идентификации). Обмен осуществляется пользовательским агентом , который представляет собой программу (например, браузер), используемую конечным пользователем для связи с проверяющей стороной и поставщиком OpenID.

Вход в систему

Конечный пользователь взаимодействует с полагающейся стороной (например, веб-сайтом), которая предоставляет возможность указать OpenID для целей аутентификации; конечный пользователь обычно ранее зарегистрировал OpenID (например alice.openid.example.org) у провайдера OpenID (например openid.example.org).

Проверяющая сторона обычно преобразует OpenID в каноническую форму URL (например, http://alice.openid.example.org/).

  • С OpenID 1.0 проверяющая сторона затем запрашивает ресурс HTML, идентифицированный URL-адресом, и считывает тег ссылки HTML, чтобы обнаружить URL-адрес поставщика OpenID (например http://openid.example.org/openid-auth.php). Проверяющая сторона также обнаруживает, следует ли использовать делегированное удостоверение (см. Ниже).
  • С OpenID 2.0 проверяющая сторона обнаруживает URL-адрес поставщика OpenID, запрашивая документ XRDS (также называемый документом Yadis ) с типом содержимого application/xrds+xml; этот документ может быть доступен по целевому URL и всегда доступен для целевого XRI.

Существует два режима, в которых проверяющая сторона может взаимодействовать с поставщиком OpenID:

  • checkid_immediate, в котором проверяющая сторона запрашивает, чтобы провайдер OpenID не взаимодействовал с конечным пользователем. Все коммуникации передаются через пользовательский агент конечного пользователя без явного уведомления конечного пользователя.
  • checkid_setup, в котором конечный пользователь связывается с поставщиком OpenID через тот же пользовательский агент, который используется для доступа к проверяющей стороне.

checkid_immediateРежим может упасть обратно в checkid_setupрежим , если операция не может быть автоматизирована.

Сначала проверяющая сторона и провайдер OpenID (необязательно) устанавливают общий секрет , на который ссылается связанный дескриптор , который затем хранит проверяющая сторона. При использовании этого checkid_setupрежима проверяющая сторона перенаправляет пользовательский агент конечного пользователя провайдеру OpenID, чтобы конечный пользователь мог пройти аутентификацию напрямую с помощью провайдера OpenID.

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

Если конечный пользователь отклоняет запрос провайдера OpenID доверять проверяющей стороне, то пользовательский агент перенаправляется обратно проверяющей стороне с сообщением, указывающим, что аутентификация была отклонена; полагающаяся сторона, в свою очередь, отказывается аутентифицировать конечного пользователя.

Если конечный пользователь принимает запрос поставщика OpenID на доверие проверяющей стороне, то пользовательский агент перенаправляется обратно проверяющей стороне вместе с учетными данными конечного пользователя. Затем доверяющая сторона должна подтвердить, что учетные данные действительно поступили от поставщика OpenID. Если проверяющая сторона и провайдер OpenID ранее установили общий секрет, то проверяющая сторона может проверить идентичность провайдера OpenID, сравнив свою копию общего секрета с копией, полученной вместе с учетными данными конечного пользователя; такая проверяющая сторона называется с отслеживанием состояния, потому что она хранит общий секрет между сеансами. Напротив, не имеющая состояния или глупая полагающаяся сторона должна сделать еще один фоновый запрос ( check_authentication), чтобы убедиться, что данные действительно поступили от поставщика OpenID.

После проверки OpenID аутентификация считается успешной, и считается, что конечный пользователь вошел в систему проверяющей стороны под идентификатором, заданным данным OpenID (например, alice.openid.example.org). Проверяющая сторона обычно затем сохраняет OpenID конечного пользователя вместе с другой информацией о сеансе конечного пользователя.

Идентификаторы

Чтобы получить URL - адрес с поддержкой OpenID, который можно использовать для входа на веб-сайты с поддержкой OpenID, пользователь регистрирует идентификатор OpenID у поставщика удостоверений. Поставщики удостоверений предлагают возможность зарегистрировать URL-адрес (обычно домен третьего уровня, например username.example.com), который будет автоматически настроен со службой аутентификации OpenID.

После регистрации OpenID пользователь может также использовать существующий URL-адрес под своим собственным контролем (например, блог или домашнюю страницу) в качестве псевдонима или «делегированного удостоверения». Они просто вставляют соответствующие теги OpenID в HTML или обслуживают документ Yadis .

Начиная с OpenID Authentication 2.0 (и некоторых реализаций 1.1), есть два типа идентификаторов, которые могут использоваться с OpenID: URL-адреса и XRI.

XRI - это новая форма идентификатора Интернета, разработанная специально для междоменной цифровой идентификации. Например, XRI бывают двух форм - i-имен и i-чисел , которые обычно регистрируются одновременно как синонимы . I-имена можно переназначать (как и доменные имена), а i-числа никогда не переназначаются. Когда i-имя XRI используется в качестве идентификатора OpenID, оно немедленно преобразуется в синонимичный i-номер (элемент CanonicalID документа XRDS). Этот i-номер является идентификатором OpenID, хранящимся проверяющей стороной. Таким образом, как пользователь, так и проверяющая сторона защищены от идентификатора OpenID конечного пользователя, когда-либо перехваченного другой стороной, что может случиться с URL-адресом, основанным на переназначаемом DNS-имени.

Фонд OpenID

OpenID Foundation (OIDF) продвигает и расширяет сообщество и технологии OpenID. OIDF - это некоммерческая организация по разработке международных стандартов, состоящая из отдельных разработчиков, государственных учреждений и компаний, которые хотят продвигать и защищать OpenID. OpenID Foundation была создана в июне 2007 года и служит общественной доверительной организацией, представляющей открытое сообщество разработчиков, поставщиков и пользователей. OIDF помогает сообществу, предоставляя необходимую инфраструктуру и помогая в продвижении и поддержке внедрения OpenID. Это включает в себя управление интеллектуальной собственностью и торговыми марками, а также содействие вирусному росту и глобальному участию в OpenID.

Люди

В совет директоров OpenID Foundation входят четыре члена сообщества и восемь корпоративных членов:

Главы

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

Соглашения об интеллектуальной собственности и взносах

OIDF гарантирует, что спецификации OpenID могут быть свободно реализованы, поэтому OIDF требует, чтобы все участники подписали соглашение о взносах. Это соглашение предоставляет Фонду лицензию на авторские права на публикацию коллективных спецификаций и включает соглашение об отказе от утверждения патента. В соглашении об отказе от утверждения указано, что участник не будет подавать в суд на кого-либо за реализацию спецификаций OpenID.

Правовые вопросы

Торговая марка OpenID в США была передана OpenID Foundation в марте 2008 года. Она была зарегистрирована NetMesh Inc. до того, как OpenID Foundation начала функционировать. В Европе с 31 августа 2007 г. торговая марка OpenID зарегистрирована в OpenID Europe Foundation.

Логотип OpenID был разработан Рэнди «ydnar» Реддигом, который в 2005 году заявил о планах передать права организации OpenID.

С момента первоначального объявления OpenID официальный сайт заявил:

Никто не должен владеть этим. Никто не планирует на этом зарабатывать. Цель состоит в том, чтобы выпустить каждую часть этого под максимально либеральными лицензиями, чтобы не было денег, лицензирования или регистрации, необходимых для игры. Если что-то подобное существует, это приносит пользу сообществу в целом, и мы все являемся его частью.

Sun Microsystems , VeriSign и ряд более мелких компаний, участвующих в OpenID, подписали договор об отказе от утверждения патентов, охватывающий спецификации OpenID 1.1. В соглашениях говорится, что компании не будут отстаивать свои патенты против реализаций OpenID и откажутся от своих обещаний от любого, кто угрожает или заявляет патенты против разработчиков OpenID.

Безопасность

Ошибки аутентификации

В марте 2012 г. в исследовательском документе сообщалось о двух общих проблемах безопасности в OpenID. Обе проблемы позволяют злоумышленнику войти в учетные записи проверяющей стороны жертвы. Что касается первой проблемы, OpenID и Google (поставщик удостоверений OpenID) опубликовали рекомендации по безопасности для ее решения. В сообщении Google говорится: «Злоумышленник может подделать запрос OpenID, который не запрашивает адрес электронной почты пользователя, а затем вставить неподписанный адрес электронной почты в ответ IDP. Если злоумышленник передает этот ответ веб-сайту, который не замечает, что это атрибут без подписи, веб-сайт может быть обманут для входа злоумышленника в любую локальную учетную запись ". В исследовательском документе утверждается, что многие популярные веб-сайты оказались уязвимыми, в том числе Yahoo! Почта , smartsheet.com , Zoho , manymoon.com , diigo.com . Исследователи уведомили затронутые стороны, которые затем исправили свой уязвимый код.

Что касается второй проблемы, документ назвал ее «Ошибка логики путаницы типов данных», которая также позволяет злоумышленникам входить в учетные записи RP жертвы. Первоначально было подтверждено, что Google и PayPal уязвимы. OpenID опубликовал отчет об уязвимости. В отчете говорится, что Google и PayPal применили исправления, и предлагают другим поставщикам OpenID проверить свои реализации.

Фишинг

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

Пытаясь бороться с возможными фишинговыми атаками, некоторые поставщики OpenID требуют, чтобы конечный пользователь прошел аутентификацию у них перед попыткой аутентификации у проверяющей стороны. Это зависит от того, что конечный пользователь знает политику поставщика удостоверений. В декабре 2008 года OpenID Foundation утвердила версию 1.0 расширения политики аутентификации провайдера (PAPE), которая «позволяет Доверяющим сторонам запрашивать у провайдеров OpenID определенные политики аутентификации при аутентификации пользователей, а провайдерам OpenID - сообщать Доверяющим сторонам, какие политики были фактически применены. использовал."

Проблемы конфиденциальности и доверия

Другие проблемы безопасности, выявленные с помощью OpenID, включают отсутствие конфиденциальности и неспособность решить проблему доверия . Однако эта проблема не является уникальной для OpenID, а является просто обычным состоянием Интернета.

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

Взлом аутентификации при незащищенном соединении

Другая важная уязвимость присутствует на последнем этапе схемы аутентификации, когда TLS / SSL не используются: URL-адрес перенаправления от поставщика удостоверений к проверяющей стороне. Проблема с этим перенаправлением заключается в том, что любой, кто может получить этот URL-адрес (например, обнюхивая провод), может воспроизвести его и войти на сайт как пользователь-жертва. Некоторые поставщики удостоверений используют одноразовые номера (число, используемое один раз), чтобы позволить пользователю войти на сайт один раз и потерпеть неудачу во всех последующих попытках. Решение nonce работает, если пользователь первым использует URL-адрес. Однако быстрый злоумышленник, который обнюхивает провод, может получить URL-адрес и немедленно сбросить TCP-соединение пользователя (поскольку злоумышленник обнюхивает провод и знает требуемые порядковые номера TCP), а затем выполнить атаку воспроизведения, как описано выше. Таким образом, одноразовые номера защищают только от пассивных злоумышленников, но не могут помешать активным злоумышленникам выполнить атаку воспроизведения. Использование TLS / SSL в процессе аутентификации может значительно снизить этот риск.

Это можно переформулировать так: 

  IF (Both RP1 and RP2 have Bob as a client) AND       // a common case
     (Bob uses the same IDP with both RP1 and RP2) AND // a common case
     (RP1 does not use VPN/SSL/TLS to secure their connection with the client) // preventable!
  THEN
    RP2 could obtain credentials sufficient to impersonate Bob with RP1
  END-IF

Скрытое перенаправление

1 мая 2014 года была обнаружена ошибка, получившая название « Скрытое перенаправление, связанное с OAuth 2.0 и OpenID». Он был обнаружен докторантом математики Ван Цзином в Школе физико-математических наук Технологического университета Наньян , Сингапур.

Объявление OpenID гласит: «« Скрытое перенаправление », опубликованное в мае 2014 года, представляет собой пример злоумышленников, использующих открытые перенаправители - хорошо известную угрозу с хорошо известными средствами предотвращения. Протокол OpenID Connect требует строгих мер, препятствующих открытию перенаправители для предотвращения этой уязвимости ".

«По общему мнению, скрытое перенаправление не так уж плохо, но все же представляет угрозу. Чтобы понять, что делает его опасным, необходимо базовое понимание открытого перенаправления и того, как его можно использовать».

Патч не был доступен сразу. Ори Эйзен, основатель, председатель и главный директор по инновациям 41st Parameter, сказал Сью Маркетт Поремба: «В любой распределенной системе мы рассчитываем на доброжелательность участников, чтобы поступать правильно. В таких случаях, как OAuth и OpenID, распределение настолько обширны, что неразумно ожидать, что каждый веб-сайт будет исправлен в ближайшем будущем ».

История

Оригинальный протокол аутентификации OpenID был разработан в мае 2005 года Брэдом Фитцпатриком , создателем популярного веб-сайта сообщества LiveJournal , во время работы в Six Apart . Первоначально назывался Yadis (аббревиатура от «Еще одна распределенная система идентификации»), но был назван OpenID после того, как доменное имя openid.net было передано Six Apart для использования в проекте. Вскоре поддержка OpenID была реализована в LiveJournal и в сообществе движка LiveJournal, DeadJournal, для комментариев к сообщениям в блогах и быстро привлекла внимание сообщества цифровой идентификации. Веб-разработчик JanRain был одним из первых сторонников OpenID, предоставляя программные библиотеки OpenID и расширяя свой бизнес за счет сервисов на основе OpenID.

В конце июня начались обсуждения между пользователями OpenID и разработчиками из компании NetMesh, производящей корпоративное программное обеспечение , которые привели к сотрудничеству в области взаимодействия между OpenID и аналогичным протоколом Light-weight Identity (LID) NetMesh . Прямым результатом сотрудничества стал протокол обнаружения Yadis , получивший название, изначально использовавшееся для OpenID. Новый Yadis был анонсирован 24 октября 2005 года. После обсуждения на семинаре Internet Identity Workshop 2005 года, несколько дней спустя, разработчики XRI / i-names присоединились к проекту Yadis, предоставив свой формат Extensible Resource Descriptor Sequence ( XRDS ) для использования в протокол.

В декабре разработчики Sxip Identity начали обсуждения с сообществом OpenID / Yadis после того, как объявили о переходе в разработке версии 2.0 своего протокола Simple Extensible Identity Protocol (SXIP) на идентификаторы на основе URL-адресов, такие как LID и OpenID. В марте 2006 года компания JanRain разработала расширение Simple Registration (SREG) для OpenID, обеспечивающее простейший обмен профилями, а в апреле представила предложение формализовать расширения для OpenID. В том же месяце началась работа по включению полной поддержки XRI в OpenID. Примерно в начале мая ключевой разработчик OpenID Дэвид Рекордон покинул Six Apart и присоединился к VeriSign, чтобы больше сосредоточиться на цифровой идентификации и руководстве по спецификации OpenID. К началу июня основные различия между проектами SXIP 2.0 и OpenID были устранены благодаря соглашению о поддержке нескольких персон в OpenID путем отправки URL-адреса поставщика удостоверений, а не полного URL-адреса удостоверения. Благодаря этому, а также добавлению расширений и поддержки XRI, OpenID превратился в полноценную структуру цифровой идентификации, при этом Recordon объявила: «Мы рассматриваем OpenID как зонтик для структуры, которая включает в себя уровни для идентификаторов, обнаружения, аутентификации и уровня служб обмена сообщениями, который находится наверху, и все это как бы окрестили «OpenID 2.0». В конце июля Sxip начала объединять свой протокол Digital Identity Exchange (DIX) с OpenID, представив первоначальные черновики атрибута OpenID Расширение биржи (AX) в августе. В конце 2006 г. в журнале ZDNet была представлена ​​аргументация в пользу OpenID для пользователей, операторов веб-сайтов и предпринимателей.

31 января 2007 г. Symantec объявила о поддержке OpenID в своих продуктах и ​​услугах Identity Initiative. Неделю спустя, 6 февраля, Microsoft совместно с JanRain, Sxip и VeriSign объявили о сотрудничестве в области взаимодействия между OpenID и платформой цифровой идентификации Windows CardSpace от Microsoft , уделяя особое внимание разработке устойчивого к фишингу решения аутентификации для OpenID. В рамках сотрудничества Microsoft обязалась поддерживать OpenID в своих будущих продуктах для серверов идентификации, а JanRain, Sxip и VeriSign обязались добавить поддержку профиля Microsoft Information Card в свои будущие решения для идентификации. В середине февраля AOL объявила, что экспериментальная служба провайдера OpenID работает для всех учетных записей AOL и AOL Instant Messenger (AIM).

В мае Sun Microsystems начала работать с сообществом OpenID, объявив о программе OpenID, а также заключив договор об отказе от утверждения с сообществом OpenID, пообещав не отстаивать свои патенты против реализаций OpenID. В июне руководство OpenID сформировало OpenID Foundation, общественную корпорацию из Орегона для управления брендом и собственностью OpenID. В том же месяце независимый фонд OpenID Europe Foundation был основан в Бельгии Снорри Джорджетти. К началу декабря основные участники протокола собрали соглашения об отказе от утверждения, а 5 декабря были ратифицированы окончательные спецификации OpenID Authentication 2.0 и OpenID Attribute Exchange 1.0.

В середине января 2008 года Yahoo! объявила о первоначальной поддержке OpenID 2.0 как в качестве поставщика, так и в качестве доверенной стороны, выпуская услугу поставщика к концу месяца. В начале февраля Google, IBM, Microsoft, VeriSign и Yahoo! присоединился к OpenID Foundation в качестве членов корпоративного совета. Примерно в начале мая SourceForge, Inc. представила поддержку поставщика OpenID и проверяющей стороны ведущему сайту разработки программного обеспечения с открытым исходным кодом SourceForge.net . В конце июля популярная социальная сеть MySpace объявила о поддержке OpenID в качестве провайдера. В конце октября Google начал поддержку в качестве поставщика OpenID, а Microsoft объявила, что Windows Live ID будет поддерживать OpenID. В ноябре JanRain анонсировал бесплатный размещенный сервис RPX Basic, который позволяет веб-сайтам начать принимать OpenID для регистрации и входа в систему без необходимости установки, интеграции и настройки библиотек с открытым исходным кодом OpenID.

В январе 2009 года PayPal присоединился к OpenID Foundation в качестве корпоративного члена, а вскоре в феврале последовал за ним и Facebook. Фонд OpenID сформировал исполнительный комитет и назначил Дона Тибо исполнительным директором. В марте MySpace запустила свою ранее анонсированную службу провайдера OpenID, позволяющую всем пользователям MySpace использовать свой URL MySpace в качестве OpenID. В мае Facebook запустил свою функцию проверяющей стороны, позволяя пользователям использовать учетную запись OpenID с автоматическим входом (например, Google) для входа в Facebook.

В сентябре 2013 года Янрейн объявил, что MyOpenID.com будет закрыт 1 февраля 2014 года; круговая диаграмма показала, что Facebook и Google доминируют в пространстве входа в социальные сети во втором квартале 2013 года. Facebook с тех пор покинул OpenID; он больше не является спонсором, представленным на доске или разрешающим вход в систему OpenID.

В мае 2016 года Symantec объявила, что прекращает поддержку службы портала персональных идентификационных данных OpenID pip.verisignlabs.com.

В марте 2018 года Stack Overflow объявил о прекращении поддержки OpenID, сославшись на недостаточное использование, чтобы оправдать затраты. В объявлении указывалось, что в зависимости от активности пользователи настоятельно предпочитают Facebook, Google и аутентификацию учетной записи на основе электронной почты / пароля.

OpenID против псевдо-аутентификации с использованием OAuth

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

Аутентификация в контексте доступа пользователя к приложению сообщает приложению, кто является текущим пользователем и присутствует ли он. [...] Аутентификация - это все о пользователе и его присутствии в приложении, и протокол аутентификации в масштабе Интернета должен иметь возможность делать это через границы сети и безопасности.

Однако OAuth ничего об этом не сообщает приложению. OAuth абсолютно ничего не говорит о пользователе и не говорит, как пользователь доказал свое присутствие или даже если он еще там. Что касается клиента OAuth, он запросил токен, получил токен и в конечном итоге использовал этот токен для доступа к некоторому API. Ему ничего не известно о том, кто авторизовал приложение и был ли там вообще пользователь. Фактически, большая часть смысла OAuth заключается в предоставлении делегированного доступа для использования в ситуациях, когда пользователь не присутствует в соединении между клиентом и ресурсом, к которому осуществляется доступ. Это отлично подходит для авторизации клиентов, но действительно плохо для аутентификации, когда все дело в том, чтобы выяснить, находится ли пользователь там или нет (и кто они).

На следующем рисунке показаны различия между использованием OpenID и OAuth для аутентификации. Обратите внимание, что с OpenID процесс начинается с того, что приложение запрашивает у пользователя их личность (обычно URI OpenID), тогда как в случае OAuth приложение напрямую запрашивает токен OAuth с ограниченным доступом (служебный ключ) для доступа к API (введите дом) от имени пользователя. Если пользователь может предоставить этот доступ, приложение может получить уникальный идентификатор для установления профиля (идентичности) с помощью API.

OpenID против псевдо-аутентификации с использованием OAuth

Атака на псевдо-аутентификацию

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

Обратите внимание, что ключ камердинера никоим образом не описывает пользователя, он предоставляет только ограниченные права доступа к какому-то дому (который даже не обязательно является пользователем, у него просто был ключ). Следовательно, если ключ становится скомпрометированным (пользователь злонамеренный и сумел украсть ключ от чужого дома), то пользователь может выдать себя за владельца дома для приложения, которое запросило его подлинность. Если ключ скомпрометирован какой-либо точкой в ​​цепочке доверия, злоумышленник может перехватить его и использовать для олицетворения пользователя X для любого приложения, использующего OAuth2 для псевдо-аутентификации на том же сервере авторизации OAuth. И наоборот, нотариально заверенное письмо содержит подпись пользователя, которая может быть проверена запрашивающим приложением против пользователя, поэтому такая атака нецелесообразна.

Проверка письма

Письмо может использовать криптографию с открытым ключом для аутентификации.

  • Запрашивающее приложение предоставляет свой открытый ключ шифрования пользователю, который предоставляет его серверу аутентификации.
  • Сервер аутентификации шифрует документ, содержащий ключ шифрования, который соответствует одностороннему хешу секрета, известного пользователю (например, парольной фразы) для ответа на запрос, с использованием открытого ключа приложения.
  • Пользователь передает зашифрованный документ обратно в приложение, которое его расшифровывает.
  • Приложение шифрует случайную фразу, используя полученный ключ шифрования, и просит пользователя сделать то же самое, затем сравнивает результаты, если они совпадают, пользователь аутентичен.

OpenID Connect (OIDC)

OpenID Connect, опубликованный в феврале 2014 года OpenID Foundation, представляет собой третье поколение технологии OpenID. Это уровень аутентификации поверх инфраструктуры авторизации OAuth 2.0 . Он позволяет вычислительным клиентам проверять идентичность конечного пользователя на основе аутентификации, выполненной сервером авторизации, а также получать базовую информацию профиля о конечном пользователе с возможностью взаимодействия и REST-подобным образом. С технической точки зрения OpenID Connect определяет RESTful HTTP API, используя JSON в качестве формата данных.

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

Смотрите также

использованная литература

  1. ^ a b c d Элдон, Эрик (2009-04-14). «Служба единого входа OpenID становится все более популярной» . venturebeat.com . Проверено 25 апреля 2009 .
  2. ^ "Что такое OpenID?" . Проверено 19 июня 2014 года .
  3. ^ «Спецификация OpenID Authentication 2.0 - окончательная» . Проверено 24 октября 2011 .
  4. ^ «OpenID Attribute Exchange 1.0 - Final» . Проверено 24 октября 2011 .
  5. ^ «OpenID Authentication 2.0 - Final» . 2007-12-05 . Проверено 18 мая 2014 .
  6. ^ «Статистика использования OpenID» .
  7. ^ Башберн, Билл (22.04.2008). «BBC присоединяется к OpenID Foundation» .
  8. ^ «Лидеры технологий присоединяются к OpenID Foundation, чтобы продвигать открытое управление идентификацией в Интернете» . 2008-02-07.
  9. ^ «PayPal Access использует OpenID 2.0» . OpenID · . Проверено 19 июня 2014 года .
  10. ^ «Сообщество Steam :: Документация по веб-API Steam» . Проверено 10 февраля 2012 .
  11. ^ Перес, Хуан Карлос. «Facebook и Google запускают программы по переносимости данных для всех» . Network World, Inc . Проверено 19 июня 2014 года .
  12. ^ «Настало время генеральной уборки для Blogger» . Команда Blogger . Проверено 10 сентября 2019 .
  13. ^ «Аутентификация OpenID 1.1 # Делегирование» .
  14. ^ Пол Тарджан. «Простое делегирование OpenID с помощью Yadis» . Архивировано из оригинала на 2009-07-04 . Проверено 30 июня 2009 .
  15. ^ a b «Лидерство» . openID Foundation . Проверено 19 июня 2014 года .
  16. ^ «Присвоение товарного знака, серийный номер: 78899244» . Ведомство США по патентам и товарным знакам . 2008-05-06 . Проверено 19 мая 2008 . Exec Dt: 27.03.2008
  17. ^ «Последняя информация о статусе» . Ведомство США по патентам и товарным знакам. 2006-03-27 . Проверено 20 марта 2008 .
  18. ^ "NetMesh: Компания / Менеджмент" . NetMesh . Архивировано из оригинала на 2007-08-30 . Проверено 20 марта 2008 .
  19. ^ «Политика OpenID Europe в отношении товарных знаков и логотипов» . Фонд OpenID Europe . Архивировано из оригинала на 2008-03-09 . Проверено 20 марта 2008 .
  20. ^ Реддиг, Рэнди (2005-06-29). «Логотип OpenID» . Danga Interactive . Проверено 20 марта 2008 .
  21. ^ Фитцпатрик, Брэд . «Интеллектуальная собственность» .
  22. ^ a b «Sun OpenID: Соглашение об отказе от утверждения» . Sun Microsystems . Проверено 20 марта 2008 .
  23. ^ "Патентное соглашение VeriSign о непринятии заявлений OpenID" . VeriSign . Архивировано из оригинала на 2008-04-15 . Проверено 20 марта 2008 .
  24. ^ Руи Ван; Шо Чен и Сяофэн Ван. «Вход меня в свои учетные записи через Facebook и Google: исследование безопасности коммерчески развернутых веб-служб единого входа с учетом трафика» .
  25. ^ «Предупреждение безопасности обмена атрибутами» .
  26. ^ «Рекомендации по безопасности для веб-сайтов, использующих OpenID Attribute Exchange» .
  27. ^ «Отчет об уязвимости: путаница в данных» .
  28. ^ Кроули, Пол (2005-06-01). «Фишинговые атаки на OpenID» . Danga Interactive . Проверено 20 марта 2008 .
  29. ^ Андерсон, Тим (2007-03-05). «OpenID все еще открыт для злоупотреблений» . IT неделя . Проверено 13 марта 2007 .
  30. ↑ Слот, Марко. «Руководство для начинающих по фишингу OpenID» . Проверено 31 июля 2007 .
  31. ^ "Verisign PIP FAQ" . Архивировано из оригинала на 2008-11-13 . Проверено 13 ноября 2008 .
  32. ^ Джонс, Майк. «PAPE одобрен как спецификация OpenID» . OpenID Foundation.
  33. ↑ Стефан Брэндс (22 августа 2007 г.). «Проблемы с OpenID» . Архивировано из оригинала на 2011-05-16 . Проверено 12 декабря 2010 . (изначально опубликовано в The Identity Corner по адресу www.idcorner.org/?p=161)
  34. ^ Tsyrklevich, Евгений. «Единый вход в Интернет: история безопасности» (PDF) . Blackhat США . Проверено 19 апреля 2012 .
  35. ^ «Обнаружен серьезный недостаток безопасности в OAuth, OpenID» . CNET. 2 мая 2014 . Проверено 10 ноября 2014 года .
  36. ^ «Скрытое перенаправление» . Тетраф. 1 мая 2014 . Проверено 10 ноября 2014 года .
  37. ^ «Facebook, пользователям Google угрожает новая брешь в безопасности» . Yahoo. 2 мая 2014 . Проверено 10 ноября 2014 года .
  38. ^ «В OAuth и OpenID обнаружена неприятная уязвимость при скрытом перенаправлении» . Хакерские новости. 3 мая 2014 . Проверено 10 ноября 2014 года .
  39. ^ «Студент-математик обнаруживает уязвимость безопасности OAuth, OpenID» . Tech Xplore. 3 мая 2014 . Проверено 10 ноября 2014 года .
  40. ^ «Скрытое перенаправление» . OpenID. 15 мая 2014 . Проверено 10 ноября 2014 года .
  41. ^ « Уязвимость « Скрытое перенаправление »влияет на OAuth 2.0, OpenID» . Журнал SC. 2 мая 2014 . Проверено 10 ноября 2014 года .
  42. ^ «Уроки, которые следует извлечь из скрытого перенаправления» . 41-й параметр. 5 мая 2014 . Проверено 10 ноября 2014 года .
  43. ^ Фитцпатрик, Брэд (2005-05-16). «Распределенная идентичность: Яди» . Живой Журнал . Архивировано из оригинала на 2006-05-04 . Проверено 20 марта 2008 .
  44. ^ Уотерс, Джон К. (2007-12-01). «OpenID обновляет идентификационные характеристики» . Новости разработчиков Redmond . Архивировано из оригинала на 2008-02-08 . Проверено 20 марта 2008 .
  45. ^ «Глоссарий» . Сервер LiveJournal: техническая информация . Проверено 13 октября 2009 года .
  46. ^ Lehn, Дэвид И. (18 мая 2005). «18 мая 2005 г.» . Блог Advogato для dlehn . Advogato. Архивировано из оригинального 21 декабря 2010 года . Проверено 13 октября 2009 года . Они искали имя и успели написать мне по электронной почте об openid.net прямо перед тем, как я собирался им его предложить. Поэтому я дал им это для нового и улучшенного проекта OpenID.
  47. ^ «OpenID: фактически распределенная система идентификации» . 2005-09-24. Архивировано из оригинала на 2005-09-24 . Проверено 20 марта 2008 .
  48. ^ a b Фитцпатрик, Брэд (30 мая 2006 г.). «Жизнь Брэда - OpenID и SixApart» . Живой Журнал . Архивировано из оригинала на 2007-04-25 . Проверено 20 марта 2008 .
  49. ^ Recordon, Дэвид (2005-12-24). «Анонсируем ЯДИС ... снова» . Danga Interactive . Проверено 20 марта 2008 .
  50. ^ Рид, Даммонд (31 декабря 2005 г.). «Внедрение YADIS без нового программного обеспечения» . Danga Interactive . Проверено 20 марта 2008 .
  51. ^ Рид, Драммонд (2008-11-30). «XRD начинается» . Равно Драммонд . Проверено 5 января 2009 года .
  52. ^ Хардт, Дик (2005-12-18). «Sxip заботится о YADIS» . Danga Interactive . Проверено 20 марта 2008 .
  53. ^ Хардт, Дик (2005-12-10). «Тизер SXIP 2.0» . Идентичность 2.0 . Архивировано из оригинала на 2007-08-14 . Проверено 20 марта 2008 .
  54. ↑ Хойт, Джош (15 марта 2006 г.). «OpenID + простой обмен регистрационной информацией» . Danga Interactive . Проверено 20 марта 2008 .
  55. ^ Грей, Виктор (2006-04-02). «Предложение по профилю XRI (i-name) для OpenID» . Danga Interactive . Проверено 20 марта 2008 .
  56. ^ Recordon, Дэвид (29 апреля 2006 г.). "Двигаемся дальше ..." LiveJournal . Архивировано из оригинала на 2006-10-20 . Проверено 20 марта 2008 .
  57. ^ Recordon, Дэвид (16.06.2006). «Продвижение OpenID вперед» . Danga Interactive . Проверено 19 мая 2008 .
  58. ^ Йоханнес Эрнст и Дэвид Рекордон. Редактор: Фил Беккер (04.12.2006). «Дело за OpenID» . ZDNet . Проверено 12 декабря 2010 .
  59. ^ «Symantec представляет инициативу по идентификации Security 2.0 на конференции DEMO 07» . Symantec . 2007-01-31 . Проверено 20 марта 2008 .
  60. ^ Грейвс, Майкл (2007-02-06). «VeriSign, Microsoft и партнеры будут работать вместе над OpenID + Cardspace» . VeriSign . Архивировано из оригинала на 2008-05-03 . Проверено 20 марта 2008 .
  61. ↑ Panzer, Джон (16 февраля 2007 г.). «AOL и 63 миллиона OpenID» . Сеть разработчиков AOL . Архивировано из оригинала на 2008-05-11 . Проверено 20 марта 2008 .
  62. ^ "Sun Microsystems объявляет о программе OpenID" . PR Newswire . 2007-05-07 . Проверено 20 марта 2008 .
  63. ^ Совет директоров OpenID (2007-06-01). «Фонд OpenID» . Проверено 20 марта 2008 .
  64. ^ Фонд OpenID Europe
  65. ^ "OpenID 2.0 ... Final (ly)!" . OpenID Foundation . 2007-12-05 . Проверено 20 марта 2008 .
  66. ^ «Yahoo! Объявляет о поддержке OpenID; пользователи могут получить доступ к нескольким интернет-сайтам со своим Yahoo! ID» . Yahoo! . 2008-01-17. Архивировано из оригинала на 2008-03-04 . Проверено 20 марта 2008 .
  67. ^ «Лидеры технологий присоединяются к OpenID Foundation, чтобы продвигать открытое управление идентификацией в Интернете» . OpenID Foundation . Marketwire . 2008-02-07 . Проверено 20 марта 2008 .
  68. ^ «SourceForge реализует технологию OpenID» (пресс-релиз). SourceForge, Inc. 7 мая 2008. Архивировано из оригинального 13 мая 2008 года . Проверено 21 мая 2008 .
  69. ^ «MySpace объявляет о поддержке OpenID и представляет новые реализации доступности данных» . Деловой провод . Мое пространство. 22 июля 2008 г. п. 2 . Проверено 23 июля 2008 .
  70. ^ «Microsoft и Google объявляют о поддержке OpenID» . OpenID Foundation. 2008-10-30.
  71. ^ «JanRain выпускает бесплатную версию ведущего в отрасли решения OpenID» (пресс-релиз). JanRain, Inc. 14 ноября 2008. Архивировано из оригинала 18 декабря 2008 года . Проверено 14 ноября 2008 .
  72. ^ «Разработчики Facebook | Новости разработчиков Facebook» . Developers.facebook.com. 2009-05-18. Архивировано из оригинала на 2009-12-23 . Проверено 28 июля 2009 .
  73. ^ «Facebook теперь принимает вход в учетную запись Google» . Pocket-lint.com. 2009-05-19 . Проверено 28 июля 2009 .
  74. ^ «Требования OpenID - Facebook Developer Wiki» . Wiki.developers.facebook.com. 2009-06-26. Архивировано из оригинала на 2009-12-23 . Проверено 28 июля 2009 .
  75. Перейти ↑ Kane, Zee M (4 сентября 2013 г.). «MyOpenID для выключения. Будет отключен 1 февраля 2014 г.» . Следующая Сеть . Проверено 5 сентября 2013 года .
  76. ^ «Спонсирующие члены OpenID» . Проверено 17 апреля 2014 года .
  77. ^ «Баннер Symantec Personal Identification Portal указывает, что обслуживание будет прекращено 12 сентября 2016 г.» . Архивировано из оригинального 11 июня 2016 года . Дата обращения 17 мая 2016 .
  78. ^ "Неужели Symantec сильно не в состоянии быть Google?" . 7 мая 2016 . Дата обращения 17 мая 2016 .
  79. ^ «Поддержка OpenID закончилась 25 июля 2018 г.» .
  80. ^ «Аутентификация пользователя с помощью OAuth 2.0» . OAuth.net . Проверено 19 марта 2015 года .
  81. ^ "Почему использовать простой протокол oauth2 для аутентификации - плохая идея?" . Обмен стеками информационной безопасности . Проверено 7 июля 2018 .
  82. ^ «OpenID Connect FAQ и вопросы и ответы» . Проверено 25 августа 2014 года .

внешние ссылки