OpenID - OpenID

Не путать с OpenID Connect.
Логотип OpenID

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

Стандарт OpenID обеспечивает основу для взаимодействия, которое должно происходить между поставщиком удостоверений и получателем OpenID ("полагающаяся сторона ").[3] Расширение стандарта (OpenID Attribute Exchange) облегчает передачу пользовательских атрибутов, таких как имя и пол, от провайдера идентификации 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, France Telecom, Google, Amazon.com, Канонический (имя провайдера Ubuntu One ), LiveJournal, Microsoft (имя провайдера Учетная запись Microsoft ), Mixi, Мое пространство, Novell, OpenStreetMap, оранжевый, Sears, солнце, Telecom Italia, Универсальная музыкальная группа, VeriSign, WordPress, Yahoo!, то BBC,[7] IBM,[8] PayPal,[9] и Пар,[10] хотя некоторые из этих организаций также имеют собственное управление аутентификацией.

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

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

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

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

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

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

Проверяющая сторона обычно преобразует 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 документ (также называемый Яди документ) с типом содержимого приложение / 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 конечного пользователя вместе с другой информацией о сеансе конечного пользователя.

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

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

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

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

Рентгеновские снимки это новая форма Интернет идентификатор разработан специально для междоменной цифровой идентификации. Например, XRI бывают двух форм:я-имена и 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 входят четыре члена сообщества и восемь корпоративных членов:[15]

Главы

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

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

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

Проблемы с законом

Торговая марка OpenID в США была передана OpenID Foundation в марте 2008 года.[16] Он был зарегистрирован NetMesh Inc. до начала работы OpenID Foundation.[17][18] В Европе с 31 августа 2007 г. торговая марка OpenID зарегистрирована в OpenID Europe Foundation.[19]

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

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

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

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

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

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

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

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

Фишинг

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

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

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

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

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

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

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

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

  ЕСЛИ (И RP1, и RP2 имеют Боба в качестве клиента) И // общий случай (Боб использует один и тот же IDP с обоими RP1 и RP2) И // общий случай (RP1 не использует VPN / SSL / TLS для защиты своего соединения с клиентом) // можно предотвратить! ТОГДА RP2 может получить учетные данные, достаточные для олицетворения Боба с помощью RP1 END-IF

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

1 мая 2014 г. произошла ошибка с названием "Скрытое перенаправление относится к OAuth 2.0 и OpenID ».[35][36] Он был обнаружен докторантом математики Ван Цзином в Школе физико-математических наук, Наньянский технологический университет, Сингапур.[37][38][39]

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

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

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

История

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

В конце июня начались обсуждения между пользователями OpenID и разработчиками из корпоративное программное обеспечение компании NetMesh, что привело к сотрудничеству в области взаимодействия между OpenID и аналогичными NetMesh Легкая идентичность (LID) протокол. Прямым результатом сотрудничества стал Яди протокол обнаружения, приняв имя, изначально использовавшееся для OpenID. О новом Яди было объявлено 24 октября 2005 года.[49] После обсуждения на 2005 г. Мастерская Интернет-идентичности несколько дней спустя, XRI /я-имена к проекту Yadis присоединились разработчики,[50] внося свою расширяемую последовательность дескриптора ресурса (XRDS ) формат для использования в протоколе.[51]

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

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

В мае, Sun Microsystems начал работать с сообществом OpenID, анонсировав программу OpenID,[62] а также заключить договор об отказе от утверждения с сообществом OpenID, обязуясь не отстаивать какие-либо из своих патентов против реализации OpenID.[22] В июне руководство OpenID сформировало OpenID Foundation, базирующуюся в Орегоне. корпорация общественного блага для управления брендом и собственностью OpenID.[63] В том же месяце в Бельгии был создан независимый фонд OpenID Europe Foundation.[64] пользователя Snorri Giorgetti. К началу декабря основные участники протокола собрали соглашения об отказе от утверждения, а окончательные спецификации OpenID Authentication 2.0 и OpenID Attribute Exchange 1.0 были ратифицированы 5 декабря.[65]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OpenID Connect

Основная статья: OpenID Connect

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

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

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

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

внешняя ссылка