OpenID — это открытый стандарт и децентрализованный протокол аутентификации , продвигаемый некоммерческой организацией OpenID Foundation. Он позволяет пользователям проходить аутентификацию на взаимодействующих сайтах (известных как проверяющие стороны или RP) с использованием службы стороннего поставщика удостоверений (IDP), что устраняет необходимость для веб-мастеров предоставлять свои собственные специальные системы входа в систему и позволяет пользователям войти на несколько несвязанных веб-сайтов без необходимости иметь отдельный идентификатор и пароль для каждого. [1] Пользователи создают учетные записи, выбирая поставщика удостоверений OpenID , [1] и затем используют эти учетные записи для входа на любой веб-сайт, который принимает аутентификацию OpenID. Несколько крупных организаций либо выдают, либо принимают OpenID на своих веб-сайтах. [2]
Стандарт OpenID обеспечивает основу для связи, которая должна происходить между поставщиком удостоверений и получателем OpenID (« проверяющая сторона »). [3] Расширение стандарта (обмен атрибутами OpenID) облегчает передачу атрибутов пользователя, таких как имя и пол, от поставщика удостоверений OpenID проверяющей стороне (каждая проверяющая сторона может запрашивать другой набор атрибутов, в зависимости от его требования). [4] Протокол OpenID не полагается на центральный орган для аутентификации личности пользователя. Более того, ни сервисы, ни стандарт OpenID не могут предписывать конкретные средства аутентификации пользователей, позволяя использовать различные подходы: от обычных (например, пароли) до новых (например, смарт-карты или биометрия).
Последней версией OpenID является OpenID 2.0, доработанная и опубликованная в декабре 2007 года. [5] Термин OpenID может также относиться к идентификатору, указанному в стандарте OpenID; эти идентификаторы принимают форму уникального универсального идентификатора ресурса (URI) и управляются неким «поставщиком OpenID», который обеспечивает аутентификацию. [1]
По состоянию на март 2016 года [обновлять]в Интернете насчитывается более 1 миллиарда учетных записей с поддержкой OpenID (см. ниже) и примерно 1 100 934 сайта имеют встроенную потребительскую поддержку OpenID: [6] 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 , [7] IBM , [8] PayPal , [9] и Steam , [10] хотя некоторые из этих организаций также имеют собственное управление аутентификацией.
Многие, если не все, крупные организации требуют, чтобы пользователи предоставили аутентификацию в виде существующей учетной записи электронной почты или номера мобильного телефона, чтобы зарегистрировать учетную запись (которая затем может использоваться в качестве идентификатора OpenID). Есть несколько небольших организаций, которые принимают регистрацию без необходимости предоставления дополнительных идентификационных данных.
Раньше Facebook использовал OpenID, но перешел на Facebook Connect . [11] Blogger также использовал OpenID, но с мая 2018 года больше не поддерживает его. [12]
OpenID — это децентрализованный протокол аутентификации, который позволяет пользователям аутентифицироваться на нескольких веб-сайтах, используя один набор учетных данных, устраняя необходимость в отдельных именах пользователей и паролях для каждого веб-сайта. OpenID основан на простой идее: пользователь проходит аутентификацию у поставщика удостоверений (IDP), который затем предоставляет пользователю уникальный идентификатор (называемый OpenID). Этот идентификатор затем можно использовать для аутентификации пользователя на любом веб-сайте, поддерживающем OpenID.
Когда пользователь посещает веб-сайт, поддерживающий аутентификацию OpenID, веб-сайт перенаправляет пользователя к выбранному им IDP. Затем IDP предложит пользователю пройти аутентификацию (например, путем ввода имени пользователя и пароля). После аутентификации пользователя IDP сгенерирует OpenID и отправит его обратно на веб-сайт. Затем веб-сайт может использовать этот OpenID для аутентификации пользователя без необходимости знать его фактические учетные данные.
OpenID построен на основе нескольких существующих стандартов, включая HTTP, HTML и XML. OpenID опирается на ряд технологий, включая механизм обнаружения, который позволяет веб-сайтам находить IDP, связанный с конкретным OpenID, а также механизмы безопасности для защиты от фишинга и других атак. [13]
Одним из ключевых преимуществ OpenID является то, что он позволяет пользователям контролировать свою собственную идентификационную информацию, а не полагаться на отдельные веб-сайты для хранения и управления своими учетными данными для входа. Это может быть особенно важно в тех случаях, когда веб-сайты уязвимы для нарушений безопасности или когда пользователи обеспокоены конфиденциальностью своей личной информации.
OpenID широко используется рядом крупных веб-сайтов и поставщиков услуг, включая Google, Yahoo! и PayPal. Протокол также используется рядом проектов и фреймворков с открытым исходным кодом, включая Ruby on Rails и Django.
Конечный пользователь взаимодействует с проверяющей стороной (например, веб-сайтом), которая предоставляет возможность указать OpenID для целей аутентификации; конечный пользователь обычно ранее зарегистрировал OpenID (например alice.openid.example.org
, ) у поставщика OpenID (например, openid.example.org
). [1]
Проверяющая сторона обычно преобразует OpenID в каноническую форму URL (например, http://alice.openid.example.org/
).
http://openid.example.org/openid-auth.php
). Проверяющая сторона также определяет, следует ли использовать делегированное удостоверение (см. ниже).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 [14] или обслуживают документ Yadis . [15]
Начиная с 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 (OIDF) продвигает и развивает сообщество и технологии OpenID. OIDF — это некоммерческая международная организация по разработке стандартов, объединяющая отдельных разработчиков, правительственные учреждения и компании, желающие продвигать и защищать OpenID. Фонд OpenID был основан в июне 2007 года и выступает в качестве общественной трастовой организации, представляющей открытое сообщество разработчиков, поставщиков и пользователей. OIDF помогает сообществу, предоставляя необходимую инфраструктуру и помогая в продвижении и поддержке внедрения OpenID. Это включает в себя управление интеллектуальной собственностью и товарными знаками, а также содействие вирусному росту и глобальному участию в OpenID.
В совет директоров OpenID Foundation входят шесть членов совета сообщества и восемь членов корпоративного совета: [16]
OIDF — это глобальная организация, занимающаяся продвижением цифровой идентификации и поощрением дальнейшего внедрения OpenID. OIDF поощряет создание отделений-членов. Отделения-члены официально являются частью Фонда и работают в рамках своих групп, поддерживая разработку и внедрение OpenID в качестве основы для пользовательской идентификации в Интернете.
OIDF гарантирует, что спецификации OpenID могут быть свободно реализованы, поэтому OIDF требует от всех участников подписать соглашение о вкладе. Это соглашение предоставляет Фонду авторскую лицензию на публикацию коллективных спецификаций и включает в себя соглашение об отказе от использования патента. В соглашении об отказе от утверждений говорится, что участник не будет предъявлять иск кому-либо за реализацию спецификаций OpenID.
Товарный знак OpenID в США был передан OpenID Foundation в марте 2008 года. [17] Он был зарегистрирован NetMesh Inc. до того, как OpenID Foundation начал свою работу. [18] [19] В Европе по состоянию на 31 августа 2007 г. торговая марка OpenID зарегистрирована в OpenID Europe Foundation. [20]
Логотип OpenID был разработан Рэнди «ydnar» Реддигом, который в 2005 году выразил планы передать права организации OpenID. [21]
С момента первоначального анонса OpenID на официальном сайте было написано: [22]
Никто не должен владеть этим. Никто не планирует зарабатывать на этом деньги. Цель состоит в том, чтобы выпустить каждую часть игры под максимально либеральными лицензиями, чтобы для игры не требовались ни деньги, ни лицензирование, ни регистрация. Если что-то подобное существует, это принесет пользу сообществу в целом, и мы все являемся частью сообщества.
Sun Microsystems , VeriSign и ряд небольших компаний, участвующих в OpenID, подписали соглашения о неутверждении патентов , охватывающие спецификации OpenID 1.1. В соглашениях говорится, что компании не будут отстаивать какие-либо свои патенты против реализаций OpenID и отзовут свои обещания от любого, кто угрожает или заявляет о патентах против разработчиков OpenID. [23] [24]
В марте 2012 года в исследовательской статье [25] сообщалось о двух общих проблемах безопасности в OpenID. Обе проблемы позволяют злоумышленнику войти в учетные записи проверяющей стороны жертвы. Что касается первой проблемы, OpenID и Google (поставщик идентификационной информации OpenID) опубликовали рекомендации по безопасности для ее решения. [26] [27] В сообщении Google говорится: «Злоумышленник может подделать запрос OpenID, который не запрашивает адрес электронной почты пользователя, а затем вставить неподписанный адрес электронной почты в ответ IDP. Если злоумышленник передаст этот ответ на веб-сайт, который не замечает, что этот атрибут не подписан, веб-сайт может быть обманным путем заставить злоумышленника войти в любую локальную учетную запись». В исследовательском документе утверждается, что многие популярные веб-сайты признаны уязвимыми, в том числе Yahoo! Почта , smartsheet.com , Zoho , Manymoon.com, diigo.com . Исследователи уведомили пострадавшие стороны, которые затем исправили свой уязвимый код.
Что касается второй проблемы, статья назвала ее «логической ошибкой путаницы типов данных», которая также позволяет злоумышленникам входить в учетные записи RP жертв. Google и PayPal изначально были признаны уязвимыми. OpenID опубликовала отчет об уязвимости [28] об этой уязвимости. В отчете говорится, что Google и PayPal внесли исправления и предлагают другим поставщикам OpenID проверить их реализацию.
Некоторые наблюдатели предполагают, что OpenID имеет слабые места в системе безопасности и может оказаться уязвимым для фишинговых атак. [29] [30] [31] Например, злонамеренная передающая сторона может перенаправить конечного пользователя на страницу аутентификации фиктивного поставщика удостоверений с просьбой к конечному пользователю ввести свои учетные данные. По завершении этого злоумышленник (который в данном случае также контролирует фиктивную страницу аутентификации) может получить доступ к учетной записи конечного пользователя у провайдера удостоверений, а затем использовать OpenID этого конечного пользователя для входа в другие службы.
В целях борьбы с возможными фишинговыми атаками некоторые провайдеры OpenID требуют, чтобы конечный пользователь прошел аутентификацию у них перед попыткой аутентификации у проверяющей стороны. [32] Это зависит от того, что конечный пользователь знает политику провайдера идентификации. В декабре 2008 года Фонд OpenID утвердил версию 1.0 расширения политики аутентификации поставщика (PAPE), которая «позволяет проверяющим сторонам запрашивать, чтобы поставщики OpenID применяли определенные политики аутентификации при аутентификации пользователей, а поставщики OpenID информировали проверяющие стороны, какие политики были фактически использованы». использовал." [33]
Другие проблемы безопасности, выявленные с помощью OpenID, включают отсутствие конфиденциальности и неспособность решить проблему доверия . [34] Однако эта проблема не уникальна для OpenID, а просто является состоянием широко используемого Интернета. [ нужна цитата ]
Однако поставщик удостоверений получает журнал ваших входов в систему OpenID; они знают, когда вы зашли на какой веб-сайт, что значительно упрощает межсайтовое отслеживание . Скомпрометированная учетная запись OpenID также может оказаться более серьезным нарушением конфиденциальности, чем взломанная учетная запись на одном сайте.
Другая важная уязвимость присутствует на последнем этапе схемы аутентификации, когда TLS/SSL не используются: URL-адрес перенаправления от поставщика удостоверений к проверяющей стороне. Проблема с этим перенаправлением заключается в том, что любой, кто может получить этот URL-адрес (например, прослушав провод), может воспроизвести его и войти на сайт как пользователь-жертва. Некоторые поставщики удостоверений используют одноразовые номера (число, используемое только один раз), чтобы позволить пользователю войти на сайт один раз и завершить все последующие попытки неудачно. Решение nonce работает, если пользователь первым использует URL-адрес. Однако быстрый злоумышленник, прослушивающий провод, может получить URL-адрес и немедленно сбросить TCP-соединение пользователя (поскольку злоумышленник прослушивает провод и знает необходимые порядковые номера TCP), а затем выполнить атаку повтора, как описано выше. Таким образом, одноразовые номера защищают только от пассивных злоумышленников, но не могут помешать активным злоумышленникам выполнить атаку воспроизведения. [35] Использование TLS/SSL в процессе аутентификации может значительно снизить этот риск.
Это можно переформулировать как:
ЕСЛИ (И RP1, и RP2 имеют Боба в качестве клиента) И // общий случай (Боб использует один и тот же IDP как с RP1, так и с RP2) И // общий случай (RP1 не использует VPN/SSL/TLS для защиты соединения с клиентом) // можно предотвратить! ЗАТЕМ RP2 может получить учетные данные, достаточные для того, чтобы выдать себя за Боба с помощью RP1. КОНЕЦ-ЕСЛИ
1 мая 2014 г. была обнаружена ошибка, получившая название « Скрытое перенаправление , связанное с OAuth 2.0 и OpenID». [36] [37] Его обнаружил докторант математики Ван Цзин в Школе физико-математических наук Наньянского технологического университета , Сингапур. [38] [39] [40]
В объявлении OpenID говорится: «'Скрытое перенаправление', опубликованное в мае 2014 года, представляет собой пример использования злоумышленниками открытых перенаправлений – хорошо известной угрозы с хорошо известными средствами предотвращения. Протокол OpenID Connect требует строгих мер, исключающих открытое перенаправление. редиректоры для предотвращения этой уязвимости». [41]
«На данный момент общее мнение заключается в том, что скрытое перенаправление не так уж и плохо, но все же представляет собой угрозу. Понимание того, что делает его опасным, требует базового понимания открытого перенаправления и того, как его можно использовать». [42]
Патч не был доступен сразу. Ори Эйзен, основатель, председатель и директор по инновациям компании 41st Параметр, сказал Сью Маркетт Поремба: «В любой распределенной системе мы рассчитываем на добродушие участников, которые поступают правильно. В таких случаях, как OAuth и OpenID, распределение настолько обширен, что неразумно ожидать исправления каждого веб-сайта в ближайшем будущем». [43]
Оригинальный протокол аутентификации OpenID был разработан в мае 2005 года [44] Брэдом Фитцпатриком , создателем популярного сайта сообщества LiveJournal , во время работы в Six Apart . [45] Первоначально называвшаяся Yadis (аббревиатура от «Еще одна распределенная система идентификации»), [46] она была названа OpenID после того, как доменное имя openid.net было передано Six Apart для использования в проекте. [47] Поддержка OpenID вскоре была реализована в LiveJournal и другом сообществе движков LiveJournal DeadJournal для комментариев к сообщениям в блогах и быстро привлекла внимание сообщества цифровой идентификации. [48] [49] Веб-разработчик JanRain был одним из первых сторонников OpenID, предоставляя библиотеки программного обеспечения OpenID и расширяя свой бизнес за счет услуг на основе OpenID.
В конце июня начались дискуссии между пользователями OpenID и разработчиками из компании NetMesh, занимающейся корпоративным программным обеспечением , которые привели к сотрудничеству по вопросам совместимости между OpenID и аналогичным протоколом Light-weight Identity (LID) NetMesh. Прямым результатом сотрудничества стал протокол обнаружения Yadis , получивший имя, первоначально использовавшееся для OpenID. Новый Yadis был анонсирован 24 октября 2005 года. [50] После обсуждения на Internet Identity Workshop 2005 года, несколько дней спустя, разработчики XRI / i-names присоединились к проекту Yadis, [51] внеся свою последовательность дескрипторов расширяемых ресурсов ( XRDS) . ) формат для использования в протоколе. [52]
В декабре разработчики Sxip Identity начали обсуждения с сообществом OpenID/Yadis [53] после объявления о переходе в разработке версии 2.0 своего протокола Simple Extensible Identity Protocol (SXIP) к идентификации на основе URL-адресов, такой как LID и OpenID. [54] В марте 2006 года компания JanRain разработала расширение Simple Registration (SREG) для OpenID, позволяющее осуществлять примитивный обмен профилями [55], а в апреле представила предложение по формализации расширений OpenID. В том же месяце началась работа по включению полной поддержки XRI в OpenID. [56] Примерно в начале мая ключевой разработчик OpenID Дэвид Рекордон покинул Six Apart и присоединился к VeriSign, чтобы больше сосредоточиться на цифровой идентификации и руководстве по спецификации OpenID. [49] [57] К началу июня основные различия между проектами SXIP 2.0 и OpenID были устранены благодаря соглашению о поддержке нескольких персон в OpenID путем предоставления URL-адреса поставщика удостоверений, а не полного URL-адреса удостоверения. Благодаря этому, а также продолжающемуся добавлению расширений и поддержки XRI, OpenID превратился в полноценную платформу цифровой идентификации, при этом Recordon заявил: «Мы рассматриваем OpenID как зонтик для структуры, которая включает в себя уровни идентификаторов, обнаружения, аутентификации и уровень служб обмена сообщениями, который находится поверх него, и все это получило своего рода название «OpenID 2.0». расширение OpenID Attribute Exchange (AX) в августе. В конце 2006 года в статье ZDNet была представлена аргументация в пользу OpenID для пользователей, операторов веб-сайтов и предпринимателей. [59]
31 января 2007 г. Symantec объявила о поддержке OpenID в своих продуктах и услугах Identity Initiative. [60] Неделю спустя, 6 февраля, Microsoft сделала совместное заявление с JanRain, Sxip и VeriSign о сотрудничестве в области взаимодействия между OpenID и платформой цифровой идентификации Microsoft Windows CardSpace , уделяя особое внимание разработке устойчивого к фишингу решения аутентификации для OpenID. В рамках сотрудничества Microsoft обязалась поддерживать OpenID в своих будущих продуктах для серверов идентификации, а JanRain, Sxip и VeriSign обязались добавить поддержку профиля информационной карты Microsoft в свои будущие решения для идентификации. [61] В середине февраля AOL объявила, что экспериментальная служба провайдера OpenID работает для всех учетных записей AOL и AOL Instant Messenger (AIM). [62]
В мае Sun Microsystems начала работать с сообществом OpenID, объявив о программе OpenID [63], а также заключив соглашение об отказе от утверждений с сообществом OpenID, пообещав не защищать какие-либо из своих патентов против реализаций OpenID. [23] В июне руководство OpenID сформировало OpenID Foundation, общественную корпорацию со штаб -квартирой в Орегоне , занимающуюся управлением брендом и собственностью OpenID. [64] В том же месяце Снорри Джорджетти в Бельгии создал независимый Европейский фонд OpenID [65] . К началу декабря основные участники протокола собрали соглашения об отказе от утверждений, а 5 декабря были ратифицированы окончательные спецификации OpenID Authentication 2.0 и OpenID Attribute Exchange 1.0. [66]
В середине января 2008 года Yahoo! объявила о первоначальной поддержке OpenID 2.0 как в качестве поставщика, так и в качестве проверяющей стороны, выпустив услугу поставщика к концу месяца. [67] В начале февраля Google, IBM, Microsoft, VeriSign и Yahoo! присоединились к OpenID Foundation в качестве членов корпоративного совета. [68] Примерно в начале мая компания SourceForge, Inc. представила поставщика OpenID и поддержку проверяющей стороны ведущему веб-сайту по разработке программного обеспечения с открытым исходным кодом SourceForge.net . [69] В конце июля популярная социальная сеть MySpace объявила о поддержке OpenID в качестве провайдера. [70] В конце октября Google начал поддержку OpenID, а Microsoft объявила, что Windows Live ID будет поддерживать OpenID. [71] В ноябре JanRain анонсировала бесплатный хостинговый сервис RPX Basic, который позволяет веб-сайтам начать принимать OpenID для регистрации и входа в систему без необходимости установки, интеграции и настройки библиотек OpenID с открытым исходным кодом. [72]
В январе 2009 года PayPal присоединилась к OpenID Foundation в качестве корпоративного члена, а вскоре в феврале последовал Facebook. Фонд OpenID сформировал исполнительный комитет и назначил Дона Тибо исполнительным директором. В марте MySpace запустила ранее анонсированную службу провайдера OpenID, позволяющую всем пользователям MySpace использовать свой URL-адрес MySpace в качестве OpenID. В мае Facebook запустил функцию проверяющей стороны, [73] [74] позволяя пользователям использовать учетную запись OpenID с автоматическим входом (например, Google) для входа в Facebook. [75]
В сентябре 2013 года Джанрайн объявил, что MyOpenID.com будет закрыт 1 февраля 2014 года; круговая диаграмма показала, что Facebook и Google доминируют в сфере социальных сетей по состоянию на второй квартал 2013 года. [76] С тех пор Facebook покинул OpenID; он больше не является спонсором, представленным на форуме и не разрешающим вход в систему OpenID. [16] [77]
В мае 2016 года Symantec объявила о прекращении поддержки службы портала личных идентификационных данных OpenID pip.verisignlabs.com. [78] [79]
В марте 2018 года Stack Overflow объявила о прекращении поддержки OpenID, сославшись на недостаточное использование, чтобы оправдать затраты. В объявлении было указано, что в зависимости от активности пользователи отдают предпочтение Facebook, Google и аутентификации учетной записи на основе электронной почты и пароля. [80]
OpenID — это способ использования одного набора учетных данных пользователя для доступа к нескольким сайтам, в то время как OAuth облегчает авторизацию одного сайта для доступа и использования информации, связанной с учетной записью пользователя на другом сайте. Хотя OAuth не является протоколом аутентификации , его можно использовать как часть одного из них.
Аутентификация в контексте доступа пользователя к приложению сообщает приложению, кто является текущим пользователем и присутствует ли он. [...] Аутентификация — это все о пользователе и его присутствии в приложении, и протокол аутентификации в масштабе Интернета должен иметь возможность делать это через границы сети и безопасности.
Однако OAuth ничего об этом не сообщает приложению. OAuth абсолютно ничего не говорит о пользователе, а также не говорит, как пользователь доказал свое присутствие и даже находится ли он еще там. Что касается клиента OAuth, он запросил токен, получил токен и в конечном итоге использовал этот токен для доступа к некоторому API. Ему ничего не известно о том, кто авторизовал приложение и был ли там вообще пользователь. Фактически, большая часть смысла OAuth заключается в предоставлении этого делегированного доступа для использования в ситуациях, когда пользователь не присутствует в соединении между клиентом и ресурсом, к которому осуществляется доступ. Это отлично подходит для авторизации клиента, но очень плохо для аутентификации, где весь смысл заключается в выяснении, присутствует ли пользователь на месте или нет (и кто он). [81]
На следующем рисунке показаны различия между использованием OpenID и OAuth для аутентификации. Обратите внимание, что при использовании OpenID процесс начинается с того, что приложение запрашивает у пользователя его личность (обычно это URI OpenID), тогда как в случае с OAuth приложение напрямую запрашивает токен OAuth с ограниченным доступом (ключ камердинера) для доступа к API (введите дом) от имени пользователя. Если пользователь может предоставить такой доступ, приложение может получить уникальный идентификатор для создания профиля (идентификации) с помощью API.
OpenID предоставляет механизм криптографической проверки, который предотвращает описанную ниже атаку на пользователей, которые неправильно используют OAuth для аутентификации.
Обратите внимание, что ключ камердинера никак не описывает пользователя, он лишь предоставляет ограниченные права доступа, к какому-то дому (который даже не обязательно принадлежит пользователю, просто у него был ключ). Поэтому, если ключ будет скомпрометирован (пользователь является злонамеренным и сумел украсть ключ от чужого дома), то пользователь может выдать себя за владельца дома в приложении, которое запросило его подлинность. Если ключ скомпрометирован в любой точке цепочки доверия, злоумышленник может перехватить его и использовать для выдачи себя за пользователя X для любого приложения, использующего OAuth2 для псевдоаутентификации на том же сервере авторизации OAuth. И наоборот, нотариально заверенное письмо содержит подпись пользователя, которую запрашивающее приложение может проверить на пользователя, поэтому такая атака нежизнеспособна.[82]
Для аутентификации письма может использоваться криптография с открытым ключом .
OpenID Connect, опубликованный в феврале 2014 года OpenID Foundation, представляет собой третье поколение технологии OpenID. Это уровень аутентификации поверх структуры авторизации OAuth 2.0 . [83] Это позволяет вычислительным клиентам проверять личность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя интероперабельным и REST-подобным способом. С технической точки зрения OpenID Connect определяет RESTful HTTP API, используя JSON в качестве формата данных.
OpenID Connect позволяет широкому кругу сторон, включая веб-клиенты, мобильные клиенты и клиенты JavaScript, запрашивать и получать информацию об аутентифицированных сеансах и конечных пользователях. Спецификация OpenID Connect является расширяемой и поддерживает дополнительные функции, такие как шифрование идентификационных данных, обнаружение поставщиков OpenID и управление сеансами.
Дата исполнения: 27.03.2008
Они искали имя и успели написать мне по электронной почте об openid.net прямо перед тем, как я собирался им его предложить.
Поэтому я отдал его им для нового и улучшенного проекта OpenID.