stringtranslate.com

OpenID

Логотип OpenID

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/).

Существует два режима, в которых проверяющая сторона может взаимодействовать с провайдером 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

Фонд 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

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

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

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

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

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

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

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

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

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

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

OpenID Connect (OIDC)

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

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

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

Рекомендации

  1. ^ abcd Элдон, Эрик (14 апреля 2009 г.). «Служба единого входа OpenID становится все более популярной» . www.venturebeat.com . Проверено 25 апреля 2009 г.
  2. ^ «Что такое OpenID?». 8 октября 2007 года . Проверено 19 июня 2014 г.
  3. ^ «Спецификация OpenID Authentication 2.0 – окончательная» . Проверено 24 октября 2011 г.
  4. ^ «Обмен атрибутами OpenID 1.0 – Финал» . Проверено 24 октября 2011 г.
  5. ^ «Аутентификация OpenID 2.0 — окончательная версия» . 5 декабря 2007 года . Проверено 18 мая 2014 г.
  6. ^ «Статистика использования OpenID» .
  7. ^ Башберн, Билл (22 апреля 2008 г.). «BBC присоединяется к OpenID Foundation» .
  8. ^ «Лидеры технологий присоединяются к OpenID Foundation для продвижения открытого управления идентификацией в Интернете» . 7 февраля 2008 г.
  9. ^ «Доступ к PayPal использует OpenID 2.0» . OpenID ·. 19 октября 2011 года . Проверено 19 июня 2014 г.
  10. ^ «Сообщество Steam :: Документация по веб-API Steam» . Проверено 10 февраля 2012 г.
  11. ↑ Перес, Хуан Карлос (4 декабря 2008 г.). «Facebook и Google запускают программы переносимости данных для всех» . Сетевой мир, Inc. Проверено 19 июня 2014 г.
  12. ^ «Для Blogger пришло время весенней уборки» . Команда блогеров . Проверено 10 сентября 2019 г.
  13. ^ Дипта, Р.; Мукеш, Раджешвари (1 сентября 2018 г.). «Расширение OpenID Connect для критически важных приложений». Кибернетика и информационные технологии . 18 (3): 93–110. дои : 10.2478/cait-2018-0041 .
  14. ^ «Аутентификация OpenID 1.1 # Делегирование» .
  15. ^ Пол Тарьян. «Простое делегирование OpenID с помощью Yadis». Архивировано из оригинала 4 июля 2009 года . Проверено 30 июня 2009 г.
  16. ^ аб «Лидерство». Фонд openID . Проверено 19 июня 2014 г.
  17. ^ «Передача товарного знака, серийный номер: 78899244» . Ведомство США по патентам и товарным знакам . 6 мая 2008 года . Проверено 19 мая 2008 г. Дата исполнения: 27.03.2008
  18. ^ «Последняя информация о статусе» . Ведомство США по патентам и товарным знакам. 27 марта 2006 г. Проверено 20 марта 2008 г.
  19. ^ «NetMesh: Компания / Руководство» . НетМеш . Архивировано из оригинала 30 августа 2007 года . Проверено 20 марта 2008 г.
  20. ^ «Политика OpenID Europe в отношении товарных знаков и логотипов» . Европейский фонд OpenID . Архивировано из оригинала 9 марта 2008 года . Проверено 20 марта 2008 г.
  21. ↑ Реддиг, Рэнди (29 июня 2005 г.). «Логотип OpenID». Данга Интерактив . Проверено 20 марта 2008 г.
  22. ↑ Фитцпатрик, Брэд (10 августа 2009 г.). "Интеллектуальная собственность".
  23. ^ ab «Sun OpenID: Соглашение об отказе от утверждений» . Сан Микросистемс . Проверено 20 марта 2008 г.
  24. ^ «Патентное соглашение VeriSign о неутверждении OpenID» . ВериСайн . Архивировано из оригинала 15 апреля 2008 года . Проверено 20 марта 2008 г.
  25. ^ Руй Ван; Шуо Чен; СяоФэн Ван (май 2012 г.). «Подписание меня в свои учетные записи через Facebook и Google: исследование безопасности коммерческих веб-служб единого входа с учетом трафика».
  26. ^ «Предупреждение безопасности обмена атрибутами» . 5 мая 2011 г.
  27. ^ «Рекомендации по безопасности для веб-сайтов, использующих обмен атрибутами OpenID» . 5 мая 2011 г.
  28. ^ «Отчет об уязвимости: путаница в данных» . 15 марта 2012 г.
  29. ↑ Кроули, Пол (1 июня 2005 г.). «Фишинговые атаки на OpenID». Данга Интерактив . Проверено 20 марта 2008 г.
  30. ↑ Андерсон, Тим (5 марта 2007 г.). «OpenID по-прежнему открыт для злоупотреблений». Неделя ИТ . Проверено 13 марта 2007 г.
  31. ^ Слот, Марко. «Руководство для начинающих по фишингу OpenID» . Проверено 31 июля 2007 г.
  32. ^ «Часто задаваемые вопросы о Verisign PIP» . Архивировано из оригинала 13 ноября 2008 года . Проверено 13 ноября 2008 г.
  33. ↑ Джонс, Майк (31 декабря 2008 г.). «PAPE одобрен как спецификация OpenID». Фонд OpenID.
  34. ↑ Стефан Брэндс (22 августа 2007 г.). «Проблема(ы) с OpenID». Архивировано из оригинала 16 мая 2011 года . Проверено 12 декабря 2010 г.(первоначально опубликовано в The Identity Corner по адресу www.idcorner.org/?p=161)
  35. ^ Цырклевич, Евгений. «Единый вход в Интернет: история безопасности» (PDF) . Блэкхэт США . Проверено 19 апреля 2012 г.
  36. ^ «Обнаружен серьезный недостаток безопасности в OAuth, OpenID» . CNET. 2 мая 2014 года . Проверено 10 ноября 2014 г.
  37. ^ «Скрытое перенаправление». Тетраф. 1 мая 2014 года . Проверено 10 ноября 2014 г.
  38. ^ «Facebook, пользователям Google угрожает новый недостаток безопасности» . Яху. 2 мая 2014 года . Проверено 10 ноября 2014 г.
  39. ^ «В OAuth и OpenID обнаружена ужасная уязвимость скрытого перенаправления» . Хакерские новости. 3 мая 2014 года . Проверено 10 ноября 2014 г.
  40. ^ «Студент-математик обнаруживает уязвимость безопасности OAuth, OpenID» . Техэксплор. 3 мая 2014 года . Проверено 10 ноября 2014 г.
  41. ^ «Скрытое перенаправление». OpenID. 15 мая 2014 года . Проверено 10 ноября 2014 г.
  42. ^ «Уязвимость «Скрытого перенаправления» влияет на OAuth 2.0, OpenID» . Журнал СК. 2 мая 2014 года . Проверено 10 ноября 2014 г.
  43. ^ «Уроки, которые следует извлечь из скрытого перенаправления» . 41-й параметр. 5 мая 2014 года . Проверено 10 ноября 2014 г.
  44. ↑ Фитцпатрик, Брэд (16 мая 2005 г.). «Распределенная идентичность: Ядис». Живой Журнал . Архивировано из оригинала 4 мая 2006 года . Проверено 20 марта 2008 г.
  45. ↑ Уотерс, Джон К. (1 декабря 2007 г.). «OpenID обновляет спецификацию идентификации». Новости разработчиков Редмонда . Архивировано из оригинала 8 февраля 2008 года . Проверено 20 марта 2008 г.
  46. ^ «Глоссарий». Сервер Живого Журнала: Техническая информация . Проверено 13 октября 2009 г.
  47. ^ Лен, Дэвид И. (18 мая 2005 г.). «18 мая 2005 года». Адвокатский блог для dlehn . Адвокато. Архивировано из оригинала 21 декабря 2010 года . Проверено 13 октября 2009 г. Они искали имя и успели написать мне по электронной почте об openid.net прямо перед тем, как я собирался им его предложить. Поэтому я отдал его им для нового и улучшенного проекта OpenID.
  48. ^ «OpenID: фактически распределенная система идентификации». 24 сентября 2005 г. Архивировано из оригинала 24 сентября 2005 г. Проверено 20 марта 2008 г.
  49. ^ аб Фитцпатрик, Брэд (30 мая 2006 г.). «Жизнь Брэда – OpenID и SixApart». Живой Журнал . Архивировано из оригинала 25 апреля 2007 года . Проверено 20 марта 2008 г.
  50. ↑ Рекордон, Дэвид (24 декабря 2005 г.). «Анонсируем YADIS... снова». Данга Интерактив . Проверено 20 марта 2008 г.
  51. ↑ Рид, Даммонд (31 декабря 2005 г.). «Внедрение YADIS без нового программного обеспечения». Данга Интерактив . Проверено 20 марта 2008 г.
  52. ↑ Рид, Драммонд (30 ноября 2008 г.). «Рентгенография начинается». Равен Драммонду . Проверено 5 января 2009 г.
  53. ↑ Хардт, Дик (18 декабря 2005 г.). «Sxip беспокоится о YADIS». Данга Интерактив . Проверено 20 марта 2008 г.
  54. ↑ Хардт, Дик (10 декабря 2005 г.). «Тизер SXIP 2.0». Идентичность 2.0 . Архивировано из оригинала 14 августа 2007 года . Проверено 20 марта 2008 г.
  55. ↑ Хойт, Джош (15 марта 2006 г.). «OpenID + Простой обмен регистрационной информацией». Данга Интерактив . Проверено 20 марта 2008 г.
  56. ↑ Грей, Виктор (2 апреля 2006 г.). «Предложение по профилю XRI (i-name) для OpenID». Данга Интерактив . Проверено 20 марта 2008 г.
  57. ↑ Рекордон, Дэвид (29 апреля 2006 г.). «Двигаемся дальше…» LiveJournal . Архивировано из оригинала 20 октября 2006 года . Проверено 20 марта 2008 г.
  58. ↑ Рекордон, Дэвид (16 июня 2006 г.). «Продвижение OpenID вперед». Данга Интерактив . Проверено 19 мая 2008 г.
  59. ↑ Беккер, Фил (4 декабря 2006 г.). «Дело в пользу OpenID». ЗДНет . Проверено 12 декабря 2010 г.
  60. ^ «Symantec представляет инициативу Security 2.0 Identity на конференции DEMO 07» . Симантек . 31 января 2007 года . Проверено 20 марта 2008 г.
  61. ↑ Грейвс, Майкл (6 февраля 2007 г.). «VeriSign, Microsoft и партнеры будут вместе работать над OpenID + Cardspace». ВериСайн . Архивировано из оригинала 3 мая 2008 года . Проверено 20 марта 2008 г.
  62. ^ Панцер, Джон (16 февраля 2007 г.). «AOL и 63 миллиона OpenID». Сеть разработчиков AOL . Архивировано из оригинала 11 мая 2008 года . Проверено 20 марта 2008 г.
  63. ^ «Sun Microsystems объявляет программу OpenID» . Пиар-новости . 7 мая 2007 года . Проверено 20 марта 2008 г.
  64. ^ Совет директоров OpenID (1 июня 2007 г.). «Фонд OpenID» . Проверено 20 марта 2008 г.
  65. ^ Европейский фонд OpenID
  66. ^ "OpenID 2.0...Наконец(ли)!". Фонд OpenID . 5 декабря 2007 года . Проверено 20 марта 2008 г.
  67. ^ «Yahoo! объявляет о поддержке OpenID; пользователи могут получать доступ к нескольким интернет-сайтам с помощью своего идентификатора Yahoo!». Yahoo! . 17 января 2008 г. Архивировано из оригинала 4 марта 2008 г. Проверено 20 марта 2008 г.
  68. ^ «Лидеры технологий присоединяются к OpenID Foundation для продвижения открытого управления идентификацией в Интернете» . Фонд OpenID . Маркетвайр . 7 февраля 2008 года . Проверено 20 марта 2008 г.
  69. ^ «SourceForge реализует технологию OpenID» (пресс-релиз). SourceForge, Inc., 7 мая 2008 г. Архивировано из оригинала 13 мая 2008 г. . Проверено 21 мая 2008 г.
  70. ^ «MySpace объявляет о поддержке OpenID и представляет новые реализации обеспечения доступности данных» . Деловой провод . Мое пространство. 22 июля 2008 г. с. 2 . Проверено 23 июля 2008 г.
  71. ^ «Microsoft и Google объявляют о поддержке OpenID» . Фонд OpenID. 30 октября 2008 г.
  72. ^ «JanRain выпускает бесплатную версию ведущего в отрасли решения OpenID» (пресс-релиз). JanRain, Inc. 14 ноября 2008 г. Архивировано из оригинала 18 декабря 2008 г. . Проверено 14 ноября 2008 г.
  73. ^ «Разработчики Facebook | Новости разработчиков Facebook» . Разработчики.facebook.com. 18 мая 2009 года. Архивировано из оригинала 23 декабря 2009 года . Проверено 28 июля 2009 г.
  74. ^ «Facebook теперь принимает вход в учетную запись Google» . Pocket-lint.com. 19 мая 2009 года . Проверено 28 июля 2009 г.
  75. ^ «Требования OpenID - Wiki для разработчиков Facebook» . Wiki.developers.facebook.com. 26 июня 2009 года. Архивировано из оригинала 23 декабря 2009 года . Проверено 28 июля 2009 г.
  76. ↑ Кейн, Зи М (4 сентября 2013 г.). «MyOpenID закрывается. Будет отключен 1 февраля 2014 г.». Следующая сеть . Проверено 5 сентября 2013 г.
  77. ^ «Члены-спонсоры OpenID» . 7 октября 2009 года . Проверено 17 апреля 2014 г.
  78. ^ «Баннер портала личной идентификации Symantec указывает на то, что обслуживание будет прекращено 12 сентября 2016 г.» . Архивировано из оригинала 11 июня 2016 года . Проверено 17 мая 2016 г.
  79. ^ «Symantec не справляется с ролью Google?» 7 мая 2016 года . Проверено 17 мая 2016 г.
  80. ^ «Поддержка OpenID закончилась 25 июля 2018 г.» .
  81. ^ «Аутентификация пользователя с помощью OAuth 2.0» . OAuth.net . Проверено 19 марта 2015 г.
  82. ^ «Почему использовать обычный oauth2 для аутентификации — плохая идея?». Обмен стеками информационной безопасности . Проверено 7 июля 2018 г.
  83. ^ «Часто задаваемые вопросы и ответы по OpenID Connect» . 20 февраля 2014 года . Проверено 25 августа 2014 г.

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