OpenID: Открытый протокол децентрализованной аутентификации

Введение

Открытый и децентрализованный протокол аутентификации

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

Стандарт OpenID предоставляет основу для обмена данными между провайдером идентификации и акцептором OpenID (полагающейся стороной). Расширение стандарта (OpenID Attribute Exchange) облегчает передачу атрибутов пользователя, таких как имя и пол, от провайдера идентификации OpenID полагающейся стороне (каждая полагающаяся сторона может запрашивать различные наборы атрибутов в зависимости от своих требований). Протокол OpenID не опирается на центральный орган для аутентификации личности пользователя. Более того, ни сервисы, ни стандарт OpenID не могут предписывать конкретные методы аутентификации пользователей, позволяя использовать как распространенные подходы (например, пароли), так и новые (например, смарт-карты или биометрические данные). Окончательная версия OpenID — OpenID 2.0, завершенная и опубликованная в декабре 2007 года. Термин OpenID также может относиться к идентификатору, определенному в стандарте OpenID; эти идентификаторы имеют форму уникального идентификатора ресурса (URI) и управляются "провайдером OpenID", который обрабатывает аутентификацию. AOL, Flickr, Google, Amazon.com, Canonical (провайдер Ubuntu One), LiveJournal, Microsoft (провайдер Microsoft account), Mixi, Myspace, Novell, OpenStreetMap, Orange, Sears, Sun, Telecom Italia, Universal Music Group, VeriSign, WordPress, Yahoo!, BBC, IBM, PayPal и Steam — некоторые из организаций, использующих OpenID, хотя некоторые из них также имеют собственные системы управления аутентификацией. Многие, если не все, крупные организации требуют от пользователей предоставления существующих учетных данных электронной почты или номера мобильного телефона при регистрации учетной записи (которые затем могут быть использованы в качестве идентификатора OpenID). Существуют и небольшие организации, принимающие регистрации без дополнительных идентификационных данных. Facebook использовал OpenID в прошлом, но перешел на Facebook Connect. Blogger также использовал OpenID, но с мая 2018 года больше не поддерживает его.

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

OpenID — это децентрализованный протокол аутентификации, позволяющий пользователям проходить аутентификацию на нескольких веб-сайтах, используя единый набор учетных данных, что избавляет от необходимости создавать отдельные имена пользователей и пароли для каждого сайта. OpenID аутентифицирует пользователя через провайдера идентификации (IDP), который затем предоставляет пользователю уникальный идентификатор (называемый OpenID). Этот идентификатор можно использовать для аутентификации пользователя на любом веб-сайте, поддерживающем OpenID. Когда пользователь посещает веб-сайт с поддержкой аутентификации OpenID, сайт перенаправляет пользователя к выбранному им IDP. IDP запрашивает у пользователя подтверждение личности (например, ввод имени пользователя и пароля). После успешной аутентификации IDP генерирует OpenID и отправляет его обратно на веб-сайт. Веб-сайт может использовать этот OpenID для аутентификации пользователя, не запрашивая его фактические учетные данные. OpenID построен на основе нескольких существующих стандартов, включая HTTP, HTML и XML. OpenID использует ряд технологий, в том числе механизм обнаружения, позволяющий веб-сайтам находить IDP, связанный с конкретным OpenID, а также механизмы безопасности для защиты от фишинга и других атак. Одним из ключевых преимуществ OpenID является то, что он позволяет пользователям контролировать свою идентификационную информацию, а не полагаться на отдельные веб-сайты для ее хранения и управления учетными данными для входа. Это особенно важно в случаях, когда веб-сайты уязвимы для утечек данных или когда пользователи обеспокоены конфиденциальностью своей личной информации. OpenID широко используется многими крупными веб-сайтами и поставщиками услуг, включая Google, Yahoo! и PayPal. Протокол также применяется в ряде проектов с открытым исходным кодом и фреймворков, таких как Ruby on Rails и Django.

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

Конечный пользователь взаимодействует с доверяющей стороной (например, веб-сайтом), которая предоставляет возможность указать OpenID для целей аутентификации; обычно конечный пользователь предварительно зарегистрировал OpenID (например, alice.openid.example.org) у провайдера OpenID (например, openid.example.org) или предоставляет документ Yadis. Начиная с OpenID Authentication 2.0 (и некоторых реализаций 1.1), существует два типа идентификаторов, которые могут использоваться с OpenID: URL и XRI. XRI – это новая форма интернет-идентификатора, разработанная специально для междоменной цифровой идентификации. Например, XRI бывают двух видов – i-имена и i-номера, которые обычно регистрируются одновременно как синонимы. I-имена могут переназначаться (как и доменные имена), в то время как i-номера никогда не переназначаются. Когда i-имя XRI используется в качестве идентификатора OpenID, оно немедленно разрешается в синонимичный i-номер (элемент CanonicalID документа XRDS). Этот i-номер и является идентификатором OpenID, хранящимся доверяющей стороной. Таким образом, и пользователь, и доверяющая сторона защищены от ситуации, когда идентификатор OpenID конечного пользователя может быть перехвачен другой стороной, что возможно с URL, основанным на переназначаемом DNS-имени.

Фонд OpenID

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

Главы

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

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

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

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

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

Фишинг

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

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

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

История

Первоначальный протокол аутентификации OpenID был разработан в мае 2005 года Брэдом Фицпатриком, создателем популярного веб-сайта сообщества LiveJournal, во время работы в Six Apart. Изначально называемый Yadis (акроним от "Yet another distributed identity system"), он был назван OpenID после того, как доменное имя openid.net было передано Six Apart для использования в проекте. Поддержка OpenID вскоре была реализована на LiveJournal и сообществе LiveJournal-инженеров DeadJournal для комментариев к сообщениям в блогах и быстро привлекла внимание сообщества цифровой идентификации. Веб-разработчик JanRain был одним из первых сторонников OpenID, предоставляя программные библиотеки OpenID и расширяя свой бизнес вокруг сервисов на основе OpenID. В конце июня между пользователями OpenID и разработчиками корпоративной компании NetMesh начались дискуссии, которые привели к сотрудничеству в области совместимости между OpenID и аналогичным протоколом Light weight Identity (LID) от NetMesh. Прямым результатом сотрудничества стал протокол обнаружения Yadis, принявший название, первоначально использовавшееся для OpenID. Новый Yadis был анонсирован 24 октября 2005 года. После обсуждения на семинаре по интернет-идентичности 2005 года разработчики имен XRI/i присоединились к проекту Yadis, внеся свой вклад в формат расширяемой последовательности описателей ресурсов (XRDS) для использования в протоколе. В декабре разработчики Sxip Identity начали обсуждения с сообществом OpenID/Yadis после объявления о сдвиге в разработке версии 2.0 своего Простого протокола расширяемой идентификации (SXIP) на URL-идентификаторы, такие как LID и OpenID. В марте 2006 года JanRain разработал расширение Simple Registration (SREG) для OpenID, позволяющее осуществлять базовый обмен профилями, а в апреле представил предложение о формализации расширений для OpenID. В том же месяце началась работа по включению полной поддержки XRI в OpenID. В начале мая ключевой разработчик OpenID Дэвид Рекордсон покинул Six Apart, присоединившись к VeriSign, чтобы больше сосредоточиться на цифровой идентификации и руководстве по спецификации OpenID. К началу июня основные различия между проектами SXIP 2.0 и OpenID были устранены благодаря соглашению о поддержке нескольких персон в OpenID путем предоставления URL-адреса поставщика идентификации, а не полного URL-адреса идентификации. С этим, а также с добавлением расширений и поддержки XRI, OpenID превратился в полноценную систему цифровой идентификации, и Рекордсон заявил: "Мы рассматриваем OpenID как зонтик для системы, которая включает в себя слои идентификаторов, обнаружения, аутентификации и слой услуг обмена сообщениями, который находится на вершине, и все это было названо "OpenID 2.0"". В конце июля Sxip начал объединять свой протокол Digital Identity Exchange (DIX) в OpenID, представив первоначальные проекты расширения OpenID Attribute Exchange (AX) в августе. В конце 2006 года в статье ZDNet была выдвинута позиция о необходимости OpenID для пользователей, операторов веб-сайтов и предпринимателей. 31 января 2007 года Symantec объявила о поддержке OpenID в своих продуктах и услугах Identity Initiative. Неделю спустя, 6 февраля, Microsoft объявила о совместном сотрудничестве с JanRain, Sxip и VeriSign в области совместимости между OpenID и платформой цифровой идентификации Microsoft Windows CardSpace, с особым акцентом на разработку решения для аутентификации OpenID, устойчивого к фишингу. В рамках сотрудничества Microsoft обязалась поддерживать OpenID в своих будущих продуктах сервера идентификации, а JanRain, Sxip и VeriSign обязались добавить поддержку профиля информационной карты Microsoft в свои будущие решения идентификации. В середине февраля AOL объявила, что экспериментальный сервис OpenID провайдера функционирует для всех учетных записей AOL и AOL Instant Messenger (AIM). В мае Sun Microsystems начала работать с сообществом OpenID, объявив о программе OpenID, а также заключив соглашение о непритязании с сообществом OpenID, пообещав не заявлять о каких-либо своих патентах в отношении реализаций OpenID. В июне руководство OpenID создало Фонд OpenID, общественно-полезную корпорацию в штате Орегон для управления брендом и собственностью OpenID. В том же месяце в Бельгии был создан независимый Фонд OpenID Europe. К началу декабря основные участники протокола собрали соглашения о непритязании, а окончательные спецификации OpenID Authentication 2.0 и OpenID Attribute Exchange 1.0 были ратифицированы 5 декабря. В середине января 2008 года Yahoo! объявила о начальной поддержке OpenID 2.0, как в качестве поставщика, так и в качестве доверенной стороны, выпустив службу поставщика к концу месяца. В начале февраля Google, IBM, Microsoft, VeriSign и Yahoo! присоединились к Фонду OpenID в качестве членов совета директоров. В начале мая SourceForge, Inc. представила поддержку OpenID провайдера и доверенной стороны на ведущем веб-сайте разработки программного обеспечения с открытым исходным кодом SourceForge.net. В конце июля популярный сервис социальных сетей MySpace объявил о поддержке OpenID в качестве поставщика. В конце октября Google запустила поддержку в качестве OpenID провайдера, а Microsoft объявила, что Windows Live ID будет поддерживать OpenID. В ноябре JanRain объявила о бесплатном размещенном сервисе RPX Basic, который позволяет веб-сайтам начинать принимать OpenID для регистрации и входа в систему без необходимости установки, интеграции и настройки библиотек OpenID с открытым исходным кодом. В январе 2009 года PayPal присоединился к Фонду OpenID в качестве корпоративного члена, за которым вскоре последовал Facebook в феврале. Фонд OpenID сформировал исполнительный комитет и назначил Дона Тибо в качестве исполнительного директора. В марте MySpace запустила ранее анонсированный сервис OpenID провайдера, позволяя всем пользователям MySpace использовать свой URL-адрес MySpace в качестве OpenID. В мае Facebook запустил функциональность доверенной стороны, позволяя пользователям использовать учетную запись OpenID с автоматическим входом (например, Google) для входа в Facebook. В сентябре 2013 года Janrain объявила о прекращении работы MyOpenID.com 1 февраля 2014 года; диаграмма показала, что Facebook и Google доминируют в пространстве социальной авторизации по состоянию на второй квартал 2013 года. Facebook с тех пор покинул OpenID; он больше не является спонсором, представленным в совете директоров, или разрешает вход в систему OpenID. В мае 2016 года Symantec объявила о прекращении работы своего личного портала идентификации OpenID pip.verisignlabs.com. В марте 2018 года Stack Overflow объявила о прекращении поддержки OpenID, ссылаясь на недостаточное использование, чтобы оправдать затраты. В объявлении говорилось, что, основываясь на активности, пользователи отдавали предпочтение Facebook, Google и аутентификации на основе электронной почты/пароля.

The original OpenID authentication protocol was developed in May 2005 by Brad Fitzpatrick, creator of popular community website LiveJournal, while working at Six Apart. Initially referred to as Yadis (an acronym for "Yet another distributed identity system"), it was named OpenID after the openid. net domain name was given to Six Apart to use for the project. OpenID support was soon implemented on LiveJournal and fellow LiveJournal engine community DeadJournal for blog post comments and quickly gained attention in the digital identity community. Web developer JanRain was an early supporter of OpenID, providing OpenID software libraries and expanding its business around OpenID based services. In late June, discussions started between OpenID users and developers from enterprise software company NetMesh, leading to collaboration on interoperability between OpenID and NetMesh's similar Light weight Identity (LID) protocol. The direct result of the collaboration was the Yadis discovery protocol, adopting the name originally used for OpenID. The new Yadis was announced on October 24, 2005. After a discussion at the 2005 Internet Identity Workshop a few days later, XRI/i names developers joined the Yadis project, contributing their Extensible Resource Descriptor Sequence (XRDS) format for utilization in the protocol. In December, developers at Sxip Identity began discussions with the OpenID/Yadis community after announcing a shift in the development of version 2.0 of its Simple Extensible Identity Protocol (SXIP) to URL based identities like LID and OpenID. In March 2006, JanRain developed a Simple Registration (SREG) extension for OpenID enabling primitive profile exchange and in April submitted a proposal to formalize extensions to OpenID. The same month, work had also begun on incorporating full XRI support into OpenID. Around early May, key OpenID developer David Recordon left Six Apart, joining VeriSign to focus more on digital identity and guidance for the OpenID spec. By early June, the major differences between the SXIP 2.0 and OpenID projects were resolved with the agreement to support multiple personas in OpenID by submission of an identity provider URL rather than a full identity URL. With this, as well as the addition of extensions and XRI support underway, OpenID was evolving into a full fledged digital identity framework, with Recordon proclaiming "We see OpenID as being an umbrella for the framework that encompasses the layers for identifiers, discovery, authentication and a messaging services layer that sits atop and this entire thing has sort of been dubbed 'OpenID 2.0'. " In late July, Sxip began to merge its Digital Identity Exchange (DIX) protocol into OpenID, submitting initial drafts of the OpenID Attribute Exchange (AX) extension in August. Late in 2006, a ZDNet opinion piece made the case for OpenID to users, web site operators and entrepreneurs. On January 31, 2007, Symantec announced support for OpenID in its Identity Initiative products and services. A week later, on February 6 Microsoft made a joint announcement with JanRain, Sxip, and VeriSign to collaborate on interoperability between OpenID and Microsoft's Windows CardSpace digital identity platform, with particular focus on developing a phishing resistant authentication solution for OpenID. As part of the collaboration, Microsoft pledged to support OpenID in its future identity server products and JanRain, Sxip, and VeriSign pledged to add support for Microsoft's Information Card profile to their future identity solutions. In mid February, AOL announced that an experimental OpenID provider service was functional for all AOL and AOL Instant Messenger (AIM) accounts. In May, Sun Microsystems began working with the OpenID community, announcing an OpenID program, as well as entering a non assertion covenant with the OpenID community, pledging not to assert any of its patents against implementations of OpenID. In June, OpenID leadership formed the OpenID Foundation, an Oregon based public benefit corporation for managing the OpenID brand and property. The same month, an independent OpenID Europe Foundation was formed in Belgium by Snorri Giorgetti. By early December, non assertion agreements were collected by the major contributors to the protocol and the final OpenID Authentication 2.0 and OpenID Attribute Exchange 1.0 specifications were ratified on December 5. In mid January 2008, Yahoo! announced initial OpenID 2.0 support, both as a provider and as a relying party, releasing the provider service by the end of the month. In early February, Google, IBM, Microsoft, VeriSign and Yahoo! joined the OpenID Foundation as corporate board members. Around early May, SourceForge, Inc. introduced OpenID provider and relying party support to leading open source software development website SourceForge. net. In late July, popular social network service MySpace announced support for OpenID as a provider. In late October, Google launched support as an OpenID provider and Microsoft announced that Windows Live ID would support OpenID. In November, JanRain announced a free hosted service, RPX Basic, that allows websites to begin accepting OpenIDs for registration and login without having to install, integrate and configure the OpenID open source libraries. In January 2009, PayPal joined the OpenID Foundation as a corporate member, followed shortly by Facebook in February. The OpenID Foundation formed an executive committee and appointed Don Thibeau as executive director. In March, MySpace launched their previously announced OpenID provider service, enabling all MySpace users to use their MySpace URL as an OpenID. In May, Facebook launched their relying party functionality, letting users use an automatic login enabled OpenID account (e. g. Google) to log into Facebook. In September 2013, Janrain announced that MyOpenID. com would be shut down on February 1, 2014; a pie chart showed Facebook and Google dominate the social login space as of Q2 2013. Facebook has since left OpenID; it is no longer a sponsor, represented on the board, or permitting OpenID logins. In May 2016, Symantec announced that they would be discontinuing their pip. verisignlabs. com OpenID personal identity portal service. In March 2018, Stack Overflow announced an end to OpenID support, citing insufficient usage to justify the cost. In the announcement, it was stated that based on activity, users strongly preferred Facebook, Google, and e mail/password based account authentication.

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

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

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

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

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

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

OpenID Connect (OIDC)

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