Open id что это за программа

Open id что это за программа

Прежде чем писать ваш вопрос сюда, убедитесь пожалуйста в том, что ответа на него нет в Справке ЖЖ.
Также, если ваш вопрос касается работы LiveJounal.com, то вы можете задать его по-русски на странице Службы поддержки пользователей.

Возможность блокировки пользователей связанных аккаунтов

• 11 июн, 2013 at 11:46 AM

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

Бывает, что пользователь жж, после того, как его забанили в чьём-то журнале, продолжает комментирование, пользуясь аккаунтами mail.ru, вконтакте и другими. Если автор журнала в принципе не заинтересован в комментариях от пользователей этих ресурсов, то мог бы отключить для них эту возможность.

Преимущества: более гибкая настройка возможностей комментирования

Возможные проблемы: нет, т. к. всегда можно просто отказаться от использования данной опции

Метки:

• 76 высказались
• Высказать свое мнение
• Поделиться
• Пожаловаться на запись
• Ссылка

Улучшенный аккаунт для Профиля OpenID

• 19 авг, 2011 at 6:32 PM

У профилей OpenID — базовый аккаунт, а у профилей facebook — улучшенный аккаунт. Улучшенный аккаунт позволяет использовать больше функций в профиле по сравнению с базовым. Например можно открыть поиск аккаунтов по названию города (в профиле, раздел МЕСТОПОЛОЖЕНИЕ), что базовый аккаунт сделать не позволяет.

OpenID Connect. Теория

Просьба, перевести профили OpenID на улучшенный аккаунт. СПАСИБО .

Метки:

• 16 высказались
• Высказать свое мнение
• Поделиться
• Пожаловаться на запись
• Ссылка

OpenID и остальные гости

• 6 июн, 2011 at 5:42 PM

Очень благодарен сервису ЖЖ за то что разрешили нам Вашим гостям не только комментировать блоги но и писать посты в сообществах. В связи с этим у меня просьба, можно ли сделать так чтобы убрать из моего имени (ника) скобки с упоминанием блогспота.

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

Метки:

• 46 высказались
• Высказать свое мнение
• Поделиться
• Пожаловаться на запись
• Ссылка

[UPD!] Переименованные аккаунты и OpenID

• 29 июл, 2010 at 4:58 PM

Уважаемые пользователи.

OpenId — Como funciona o openId connect

На прошлой неделе мы объявили о введении ограничений на возможность аутентификации по OpenID [username].livejournal.com на сторонних ресурсах. После более тщательного анализа ситуации, принимая во внимание ваши отзывы, было принято решение смягчить введенные ограничения:

С сегодняшнего дня возможность аутентификации по OpenID [username].livejournal.com на сторонних ресурсах заблокирована только для тех пользователей, которые выполнили переименование после 15.07.2010.

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

Если вы не переименовывали аккаунт или переименовали его до 15.07.2010, однако испытываете трудности с аутентификацией по OpenID Живого Журнала на стороннем ресурсе, вероятно, вы столкнулись с проблемой «совместимости OpenID клиента» из-за обновления протокола OpenID в ЖЖ до версии 2.0. Уточните, пожалуйста, адрес ресурса, на котором вы пытаетесь авторизоваться, и сообщение об ошибке, которое вы получаете, в комментарии к этой записи или новом запросе на форуме поддержки.

Метки:

• 10 высказались
• Высказать свое мнение
• Поделиться
• Пожаловаться на запись
• Ссылка

Источник: lj-ru-support.livejournal.com

OpenID

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

Сайты, поддерживающие её, часто помечаются логотипом системы, расположенным возле поля ввода пароля на странице входа.

Существует несколько «OpenID провайдеров», которые предоставляют хостинг OpenID URL. Самые известные и простые из них: ClaimID, myID.net, myOpenID и myVidoop.

История развития

Протокол OpenID разработал Брэд Фицпатрик, один из создателей LiveJournal. Дальнейшие улучшения в спецификацию вносились многими специалистами, так как в отличие, к примеру, от TypeKey, OpenID изначально проектировался, как независимый от провайдера метод аутентификации. Для улучшения механизма, стимулирования разработчиков и скорейшего распространения проекта в августе 2006-го на развитие было выделено $50 000 — по $5 000 каждому из десяти крупных opensource-проектов, задействовавших поддержку OpenID. Начиная с версии 1.1, OpenID использует протокол Yadis. В настоящее время закончена работа над версией 2.0.

Терминология

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

Вход через OpenID с точки зрения конечного пользователя

На сайте, назовём его, к примеру, example.com , располагается форма входа, но вместо привычных полей логин и пароль, в ней можно заполнить только одно — для ввода OpenID идентификатора. Зачастую рядом с таким полем располагается логотип OpenID.

Чтобы пользователь Вася Пупкин смог пройти OpenID-авторизацию на сайте example.com с помощью своего идентификатора pupkin.openid-provider.org , который он зарегистрировал у провайдера идентификации openid-provider.org , Вася просто на example.com вводит свой OpenID в предлагаемую форму входа.

Сайт зависимой стороны перенаправляет пользователя на сайт провайдера. Сайт провайдера запрашивает у пользователя подтверждение, действительно ли пользователь желает предоставить информацию о своей учётной записи. Если пользователь соглашается, то сайт провайдера перенаправляет пользователя обратно на сайт зависимой стороны. При обратном перенаправлении, провайдер передаст информацию о пользователе зависимой стороне.

Вход через OpenID с точки зрения зависимой стороны

Для веб-разработчиков: за обработку формы отвечает клиентская часть библиотеки OpenID [1] . Декларируя возможность авторизации по OpenID, сайт example.com объявляет себя Зависимой стороной в протоколе OpenID.

Если идентификатор представляет собой URL, то первое, что делает зависимая сторона ( example.com ) — приводит его к нормальному виду, то есть к виду http://pupkin.openid-provider.org/ . В соответствии с OpenID 1.0 зависимая сторона запрашивает веб-страницу по этому адресу и через HTML тег находит URL сервера-провайдера OpenID, например, http://openid-provider.org/openid-auth.php . Зависимая сторона (клиент) также проверяет, стоит ли ему использовать делегированный идентификатор (см.ниже). С версии OpenID 2.0 зависимая сторона проводит инспекцию запрашивая XRDS документ (который также называют Yadis документом) с типом application/xrds+xml , который может располагаться по введенному URL, и всегда доступен для введённого XRI.

Зависимая сторона может обмениваться информацией с провайдером идентификации двумя способами:

• checkid_immediate — машинно-ориентированный, в котором обмен информации между серверами идёт в фоне, без ведома пользователя;
• checkid_setup — где пользователь напрямую обращается к сайту провайдера идентификации, используя тот же браузер, с которого он заходит на сайт зависимой стороны.

Большей популярностью в Интернете пользуется второй способ. Кроме того, checkid_immediate может откатиться к использованию checkid_setup , если операция входа не может быть проведена автоматически.

Сначала (необязательно) зависимая сторона и провайдер согласовывают shared secret или секретный код — описатель партнёра (associate handler), который зависимая сторона сохраняет. В режиме checkid_setup зависимая сторона переадресует браузер пользователя к провайдеру. В данном случае браузер Васи переадресуется на openid-provider.org , где провайдер сможет опознать Васю.

Метод идентификации пользователя провайдером может быть любым, но обычно OpenID провайдер запрашивает у пользователя логин и пароль его учётной записи на сервере провайдера (затем, как правило, сохраняет сессию в cookie, как это делает большинство сайтов с парольным доступом). Затем провайдер спросит, доверяет ли Вася странице, указанной зависимой стороной для возврата пользователя после проверки подлинности, куда будет отправлена его информация (к примеру, http://example.com/openid-return.php ). Если Вася ответит утвердительно, браузер с соответствующими подтверждениями перенаправляется на указанную страницу, и идентификация по OpenID почти готова, чтоб признаться успешной. В случае недоверия Васи к указанной странице, браузер всё равно перенаправляется туда же — однако зависимая сторона получает отказ на свой запрос, и, в свою очередь, отказывается впустить Васю.

Однако процесс входа всё ещё не завершён, потому что на данном этапе example.com должен удостовериться, что полномочия пользователю выдал действительно openid-provider.org , а не сам Вася например, взломщик, и пошёл на страницу подтверждения авторизации самостоятельно. Если стороны предварительно договорились о секретном ключе (shared secret см.выше), то зависимая сторона может проверить ключ, полученный вместе с полномочиями пользователя по имеющейся у неё информации. Такая зависимая сторона называется хранящей состояние (stateful), так как она сохраняет секретный ключ между сессиями. В противоположность ей зависимая сторона без памяти (stateless) или немая (dumb) должна совершить ещё один фоновый запрос ( check_authentication ) для проверки того, что данные действительно пришли с сервера openid-provider.org .

После проверки идентификатора Вася признаётся зашедшим на example.com как pupkin.openid-provider.org . После чего сайт может сохранить сессию или, если это первый визит, запросить у пользователя дополнительную информацию необходимую example.com для завершения регистрации.

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

Пожалуйста, улучшите статью в соответствии с правилами написания статей.

Simple Registration Extension

Первоначально OpenID создавался исключительно для аутентификации пользователя, но после непродолжительной эксплуатации появилась острая потребность в предоставлении дополнительной информации о конечном пользователе. Для решения этой проблемы было разработано расширение протокола — Simple Registration Extension. Провайдеры аутентификации, которые поддерживают это расширение, могут хранить информацию о т. н. «персонах». «Персона» — запись, содержащая Ваше имя, адрес электронной почты и другие данные, которые обычно требуются для регистрации на сайтах. Любая персона может быть выбрана, как «публичная» — её содержимое сможет посмотреть каждый даже без согласия персоны на это.

Делегирование OpenID

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

Критика

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

Примечания

Аналоги

• TypeKey
• Windows Live ID
• uID — универсальный логин (e-mail адрес), используемый в uNet-сообществе и большинстве сайтов системы uCoz.
• Google Friend Connect — платформа, позволяющая принимать авторизацию на сайте без регистрации. Авторизация по OpenID, Google, AIM и Yahoo

См. также

Ссылки

• Сайт проекта (англ.)
• OpenID Wiki (англ.)
• OpenID Europe Foundation (англ.)
• OpenID в энциклопедии сайтостроения
• Каталог сайтов, поддерживающих OpenID (англ.)
• Форум по OpenId (рус.)

Провайдеры

• MyOpenID, популярный регистратор OpenID (англ.)
• isOpenID.ru, российский регистратор OpenID (рус.)
• Яндекс (рус.)
• Mail.ru (рус.)
• OneID (рус.)

Источник: www.sbup.com

Разница между OpenID и OAuth

Как ни странно, путаница в понятиях «OpenID» и «OAuth» встречается довольно часто. Люди используют их как взаимозаменяемые термины или считают OAuth своего рода новой улучшенной версией OpenID. Но на самом деле это совершенно разные вещи. Чтобы было куда ссылаться в таких случаях, пишу пост.

Этот пост не о том, что из этих двух слов «лучше», что «зло» или что «умерло». Это просто констатация фактов.

Суть

OpenID позволяет сайту удостовериться, что его пользователь владеет неким персональным URL (своим сайтом, блогом, профилем). Этого факта достаточно для того, чтобы использовать уникальный URL для узнавания того же самого пользователя в следующий раз. И всё. Все остальные вещи — заведение аккаунта, получение email’а и других данных, разрешение какой-то активности на сайте — остаётся на усмотрение сайта. Другими словами, OpenID — это чистая аутентификация: вы знаете, кто к вам пришёл, но вольны делать с этим знанием всё, что угодно.

OAuth позволяет программе (на вебе или локальной) получить от пользователя права на использование какого-то конкретного API. Права обозначаются токеном, свойства которого никак не определены: он может быть одинаковым для разных пользователей, может быть разным для одного в разное время. Всё, что гарантируется — это что программа в обмен на токен сможет выполнять какие-то действия на каком-то сервисе. Другими словами, OAuth — это чистая авторизация: вы обладаете конкретными правами, но не можете в общем случае по ним определить, кому они принадлежат.

Аналогия. OpenID — это ваш паспорт: он говорит, кто вы, но что он даёт, зависит от места, куда вы с ним пришли. OAuth — ключи от вашей машины: с ними можно ездить на вашей машине, даже не зная, как вас зовут.

Вход на сайты

Исходя из написанного выше, естественной технологией для реализации входа на сайты с существующим сторонним аккаунтом является OpenID. Больше того, из-за неопределённости понятия токена «входа через OAuth» вообще не может существовать в природе. Тем не менее, вездесущие входы через Твиттер и Фейсбук используют как раз OAuth. Где неувязка?

И Твиттер, и Фейсбук используют OAuth, как деталь реализации, но в остальном у них нет ничего общего. Роли протоколов выглядят в этом случае так:

• OAuth предоставляет сайту авторизацию на использование API Твиттера/Фейсбука
• а вот уже через API можно провести аутентификацию («вход») пользователя, так как оба они предоставляют некую идентифицирующую информацию

Аналогия. «Вход через OAuth» — это ключи от машины, в которой по случаю оказались ещё и именные документы владельца.

Важно понимать, что поскольку аутентификацию предоставляет проприетарный API, это не «вход через OAuth», а «вход через Твиттер/Фейсбук». На практике это значит, что нельзя написать некую обобщённую OAuth-библиотеку для входа через любой произвольный сервис типа Твиттера и Фейсбука.

OpenID Connect

Идея обобщённого входа через OAuth может работать, если вместо проприетарного API аутентификации стандартизовать какой-нибудь открытый. И такая попытка была — OpenID Connect. Там главная идея OpenID — открытая аутентификация — отделяется от протокола обмена ключами, в качестве которого берётся как раз OAuth. И ещё решаются сопутствующие вопросы типа discovery-механизма, которого в OAuth нет.

Впрочем, на практике OpenID Connect нигде не используется. Почему — совсем отдельная тема.

Комментарии: 19

Владимир Епифанов

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

Ivan Sagalaev
Ну судьба вполне понятна: он медленно умирает. Но я специально не затрагивал этого здесь.
Доброжелатель
Непонятно, как же тогда расценивать http://github.com/intridea/omniauth — как парадокс?

Ivan Sagalaev
Никакого парадокса. Это не обобщённая библиотека, там вручную написан код для каждого провайдера.

Хотелось бы ещё понять теперь, почему не используется OpenID Connect? Иван, может быть поделитесь ссылкой на какое-нибудь объяснение или лучше объясните в двух словах?

Владимир Епифанов

gurylyov, какие преимущества даст использование OpenID Connect? Твитер и Фейсбук дают ясные преимущества в виде доступа к разнообразной информации и под них всё уже готово.

Спасибо за статью =) теперь все стало на свои места, что куда и почему.
Константин Никитин

Иван, спасибо огромное за статью! Сравнение OAuth от Facebook с машиной с забытым паспортом сразу все расставило по местам!

Барсук ленивый

Люди считают так, потому что для них и аутентификация с авторизацией одно и то же «Надо нажатьна кнопку, и тогда можно будет писать»

Ivan Sagalaev

Вы о каких «людях»? Я пишу о специалистах (разработчиках, менеджерах), а не о пользователях, которым про эти технологии в принципе и знать не нужно.

«OpenID — это ваш паспорт»

Только спустя некоторое время тот же паспорт может оказаться совсем не ваш, потому что нет возможности получить какое-либо доменное имя навсегда. Достаточно не суметь вовремя продлить домен. Достаточно, чтобы у какой-нибудь конторы оказалась подходящая торговая марка, чтобы домен можно было отобрать.

Что примечательно, новый владелец паспорта сможет вклеить новую фотографию и претендовать на все права прежнего владельца. Например, сможет продать машину вместе с ключами. В общем, частному лицу надёжнее полагаться на крупного OpenID-провайдера, чем надеяться на «своё» доменное имя; «своих» постоянных URI в современном интернете нет 🙁 А если полагаться на крупного id-провайдера, то разница между механизмами аутентификации стирается (в любом случае, с авторизацией или без, всё в руках id-провайдера).

«OpenID — это ваш паспорт . OAuth — ключи от вашей машины . »

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

Thanks for the post—really appreciate the info.
Rohit Jangid
great post, very clearly explained the difference between the two protocols which I was looking for.

Я вот читал и думал, где же зде скрытое «сокровище» зарыто и понял, OAUTH не только предоставляет авторизацию, но ещё и подтверждает или, точнее, передаёт данные аутентификации от facebook’а или twitter’а. Потому сайт, через который была выполнена авторизация с помощью OAUTH, доверяя данным именно аутентификации может допустить вход пользователя к себе.

Аналогия. «Вход через OAuth» — это ключи от машины, в которой по случаю оказались ещё и именные документы владельца.

Собственно, ваша аналогия и молвит как раз о сем.
Mike Schwartz

OpenID is about authentication (ie. proving who you are), OAuth is about authorisation (ie. to grant access to functionality/data/etc.. without having to deal with the original authentication) Well thats another difference

Источник: softwaremaniacs.org

OpenID или не OpenID? Оно того стоит?

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

вещи, которые определенно должны быть собраны в процессе проверки:

• полное наименование
• электронная почта

(Я уверен, что мне придется спросить об этом самому)

• платежный адрес
• адрес доставки
• информация о кредитной карте

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

/ Edit

(возможно, вы заметили, что stackoverflow использует OpenID)

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

с Microsoft делает Live ID поставщиком OpenID (Подробнее), в результате чего на несколько сотен миллионов дополнительных счетов к тем, которые предоставляются Google, Yahoo, и другие, этот вопрос является более важным, чем когда-либо.

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

OpenID кажется хорошей идеей, но реализация имеет сомнительную ценность. Каковы преимущества OpenID и действительно ли это стоит в моем сценарии, описанном выше?

автор: Eloff

15 ответов

Я уважаю вашу потребность в деловой причине использовать OpenID, а не техническую причину. Вот оно:

Причина № 1

OpenID-это легче чем имя пользователя+пароль. «О Нет», я слышу ответы сейчас, » OpenID запутывает и пугает пользователей. Они убегут.- Вот почему ты . —7—>Не говорите пользователю, что это OpenID. Просто предложите кнопки Yahoo и Google и скажите: «используйте учетную запись, которую у вас уже есть» или что-то в этом роде эффект. Пользователи люблю тебя. Ниже вы используете OpenID, но не рекламируете этот факт и, возможно, даже не предлагаете текстовое поле OpenID, пока OpenID не станет более распространенным.

сильное большинство пользователей уже вошли в Yahoo или Google, поэтому» Нажмите здесь, чтобы войти в систему с помощью вашей учетной записи Google/Yahoo » кнопки будут означать, что это быстрее и проще для ваших клиентов -> больше продаж.

Причина № 2

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

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

Причина № 3

меньше вызовов поддержки и веб-страниц для поддержки пользователей, которые забыли свои пароли.

автор: Andrew Arnott

Что мне больше всего нравится в OpenID, так это то, что я вообще не чувствую, что создаю учетную запись. Это больше похоже на то, что у меня уже есть учетная запись для всего интернета, и StackOverflow замечает это при входе в систему. Я действительно устал от создания новой «идентичности» на каждом сайте, с которым я сталкиваюсь, потому что они хотят иметь больше пользователей.

Мне также нравится, что сайты, которые (только) используют OpenID, как правило, делают весь опыт учетной записи более гибким: нет подтверждения по электронной почте требуется, никаких насильственных-уникальные имена, использовать Граватар, и т. д. Плюс в том, что там нет Регистрация; я просто войти, как я уже был здесь.

автор: Eevee

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

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

автор: Jonik

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

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

автор: Michael Krelin — hacker

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

автор: niklassaers

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

автор: MattC

в моем последнем приложении я даю пользователям выбор. Я думаю, что если вы предлагаете OpenID, это должно быть необязательно, и тот факт, что это необязательно, должен быть очень ясен вашим пользователям. Я протестировал свою регистрацию с «средними» пользователями, и они очень не решались войти в систему со своими Yahoo, Facebook, Google или что у вас есть.

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

автор: Andy Gaskell

OpenId был оспорен, потому что это новая и незнакомая концепция. Во многих отношениях он должен был называться «OpenPassword», потому что основным преимуществом является управление кучей Логинов для многих сайтов с одним паролем. Однако это больше, чем это, потому что вы указываете одну величину, и она говорит, Кто вы, и доказывает это.

Я знаю некоторых очень опытных компьютерных ученых, которые были полностью сброшены, когда познакомились с концепцией — не могли видеть сразу как это было безопасно, как ввод пароля. Поскольку он называется «OpenID», они думали, что это просто незащищенное имя. Я упоминаю об этом, потому что этот вызов для понимания значителен.

Facebook Connect-это то же самое, и это работает просто потому, что есть 1 миллиард людей с аккаунтами Facebook, и они, как правило, войти в Facebook все время. То, что ребята facebook сделали хорошо, — это пользовательский интерфейс, и те, кто реализует OpenID, должны извлечь урок из что.

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

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

автор: AgilePro

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

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

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

автор: klabranche

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

вы можете дополнительно вставить ненавязчивую ссылку на регистрацию, говоря: «есть открытый идентификатор?». Таким образом, вы, те, кто знаком с ним, знаете, как им пользоваться, а не просто игнорируете его.

автор: HyderA

Я все больше и больше нахожу, что если мне нужно выбрать имя пользователя, и мой предпочтительный уже занят, я просто уйду с сайта. По крайней мере, одна компания потеряла продажи таким образом, и я отказываюсь присоединиться к Twitter. С другой стороны, сайты, которые используют ваш адрес электронной почты в качестве имени пользователя не совсем такая же проблема. Для меня это другая проблема: какой адрес у них?

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

автор: eswald

Я чувствую, что это зависит от конечных пользователей вашей системы. Open ID успешен в SO, потому что люди, которые используют SO, знают что-то об Open ID.

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

один из способов, который я мог бы придумать для процесса проверки, — не заставлять пользователя Регистрация. Если они решат просто проверить, пусть они делают это.

автор: Ramesh

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

автор: Sergio Tapia

лично я думаю, что ценность хорошо реализованной концепции «ленивой регистрации» намного полезнее, чем сам OpenId.

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

Источник: askdev.ru

Open id что это за программа

• Open Banking и Open API — зачем это нужно?
• В чем преимущества Open API?
• Open API в мире
• Open API в России
• Что ограничивает развитие Open API?
• Примеры Open API в России
• Кейс ВТБ

Этот материал является частью проекта ВТБ Fintech Talks.
Читайте, чтобы узнать больше

• Open Banking и Open API — зачем это нужно?
• В чем преимущества Open API?
• Open API в мире
• Open API в России
• Что ограничивает развитие Open API?
• Примеры Open API в России
• Кейс ВТБ

Этот материал является частью проекта ВТБ Fintech Talks.
Читайте, чтобы узнать больше

В последние два года одним из инновационных направлений на мировом рынке финансовых технологий стал Open Banking — тренд, диктуемый повышением конкуренции и изменившимися потребностями клиентов, которые ждут от банков простоты и удобства технологических компаний. По оценкам Accenture, к 2020 году 7% выручки европейских банков (или €61 млрд) будет результатом активностей в Open Banking. Великобритании, по данным PwC, Open Banking может принести £7.2 млрд выручки к 2022 году.

По России оценок пока нет, однако страна старается не отставать от общего тренда. Регулятор и сам рынок, как банки, так и финтех-сервисы, ищут оптимальные варианты для реализации концепции Open Banking и применения технологии Open API. ВТБ активно занимается решением этой задачи, обладает экспертизой в вопросе и готов поделиться своим практическим опытом и первыми кейсами.

Мы поговорили с экспертами ВТБ Иваном Бобровым и Сергеем Лукашкиным и разобрались, что представляют из себя Open Banking и Open API, какие преимущества эти технологии дают банкам и их клиентам, и что происходит с открытым банкингом за рубежом и в России.

Open Banking и Open API — зачем это нужно?
Open Banking и Open API — зачем это нужно?

Open Banking — концепция, которую можно использовать при создании собственной экосистемы. В такой экосистеме банки открывают доступ к данным и собственным сервисам сторонним компаниям (third party providers). Те, в свою очередь, могут использовать данные для анализа и дистрибуции продуктов. Одно из ключевых преимуществ Open Banking — «разворачивание» банковского сервиса в сторону клиента, возможность предлагать ему больше услуг в более удобном для него формате. Благодаря Open Banking развивается и сам рынок — для сторонних компаний снижаются барьеры входа в финансовую отрасль, стимулируется конкуренция на рынке.

В основе Open Banking лежат Open Data и Open API. Open Data — это принципы открытого доступа к данным. К таким данным — будь то курсы валют и списки банкоматов или деперсонализированные транзакционные данные — получают доступ внешние разработчики. API (application programming interface) — программный интерфейс, который позволяет одной компьютерной программе «общаться» с другой.

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

«АРI – это способ обмена данными. Ореn API трактуется очень по-разному. Пример Open API в чистом виде — когда разработчик получает доступ к API платформы вроде Facebook и пишет на его основе собственное приложение, которое, например, позволит ему следить за SMМ-отчетностью. При этом сама платформа не тратит ресурсы на создание такого сервиса.

Интернет-эквайринг — это тоже Open API, просто никто его так никогда не называл. У банков давно есть API для работы с юридическими лицами напрямую, минуя личный кабинет — например, для получения выписок, отправки платежек и так далее. Это делается в рамках двусторонних договоров, поэтому называть это Open API будет слишком громко».

Сергей Лукашкин
директор цифровой трансформации ВТБ

В финансовой сфере Open API описывает интерфейс, через который сторонние сервисы могут взаимодействовать с системой банка и обмениваться с ней данными. Open API позволяет, в частности, предлагать продукты банка на маркетплейсах с возможностью приобрести их дистанционно; объединять счета клиента из разных банков в одном приложении; внедрять персональных финансовых советников, которые проанализируют привычки клиента и предложат ему оптимальные стратегии финансового поведения; персонализировать продуктовые предложения благодаря анализу транзакций; интегрироваться с AI и IoT-приложениями для создания максимально удобного клиентского опыта и так далее.

В чем преимущества Open API?
В чем преимущества Open API?

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

Для клиентов (как физических, так и юридических лиц) Open Banking означает в первую очередь повышение качества услуг. Сюда можно отнести, в частности:

• Более продуманные и «user-friendly» интерфейсы, повышение скорости всех процессов.
• Расширение продуктовой линейки и удобный поиск выгодных предложений, например, депозитов.
• Расширение доступа к кредитным продуктам (за счет ускорения анализа данных по транзакциям и повышения прозрачности скоринга заемщиков).
• Персонализация продуктового предложения (за счет более глубокого анализа финансовых привычек и поведения).
• Ведение личных финансов и анализ счетов из разных банков на одной платформе.

Преимущества открытых интерфейсов для банков на первый взгляд не так очевидны — у клиента появляется больше возможностей для выбора продуктов и смены провайдеров, в результате чего банкам нужно прикладывать больше усилий, чтобы оставаться конкурентоспособными. Тем не менее от внедрения Open API могут выиграть и сами банки:

• Диджитализация банковских сервисов может привести к росту выручки за счет расширения каналов продаж и новых вариантов монетизации.
• Open Banking может улучшить показатели вовлеченности и удержания клиентов и позволит предлагать им больше дополнительных сервисов. По оценкам PwC, наиболее популярная активность клиента в банковском приложении сегодня — это проверка баланса, на которую он тратит всего 0,9 минуты в день. Открытые интерфейсы могут улучшить эту статистику.
• Open API позволят финансовым институтам собирать и анализировать большее количество информации о клиентах и предлагать им персонализированные услуги, что может положительно повлиять на выручку (клиент с большей вероятностью купит такую услугу или продукт).
• Более глубокий скоринг позволит банкам выдавать больше кредитов по выгодным ставкам, что может привлечь дополнительную аудиторию.
• Единожды инвестировав свои ресурсы в разработку Open API, банки смогут пользоваться преимуществами инновационных решений без дополнительных затрат на IT-разработку.

Open API в мире — что происходит на зарубежных рынках?
Open API в мире — что происходит на зарубежных рынках?

Наиболее известный подход к регулированию в сфере Open Banking — европейский, в основе которого лежит платежная директива PSD2 (Payment Services Directive). Первая версия директивы была принята еще в 2007 году и предлагала правила и гайдлайны для эффективного развития платежных сервисов в Европейском Союзе. Однако с развитием технологий PSD стало недостаточно для того, чтобы гарантировать безопасность потребителя и при этом поощрять инновации и конкуренцию. В результате в 2013 году был предложен первый драфт второй версии платежной директивы — PSD2. К 14 сентября 2019 года PSD2 должен вступить в полную силу — к этому моменту банки должны полностью соответствовать требованиям директивы, ключевые из которых:

1. Наличие у банков более строгой процедуры аутентификации. PSD2 вводит понятие Strong Customer Authentication — двухфакторной аутентификации, которая основана на использовании двух или более элементов, относящихся к категориям «знание» (что-то, что знает только пользователь), «владение» (что-то, что есть только у клиента) и «наследственность» (уникальная характеристика пользователя).
2. Предоставление банками данных о пользователях сертифицированным TPPs (third party providers). Директива вводит несколько ключевых терминов, которые характеризуют разные виды TPPs:

• PISP (Payment Initiation Service Provider) — провайдер, который предоставляет платежный сервис и может инициировать платеж от имени клиента. К таким можно отнести, например, сервисы, осуществляющие P2P-переводы;
• AISP (Account Information Service Provider) — провайдер, который предоставляет консолидированную информацию о платежных аккаунтах клиента. Такие провайдеры могут анализировать потребительские привычки пользователя или агрегировать информацию о его счетах в разных банках на одной платформе.
• PIISP (Payment Instrument Issuer Service Provider) — провайдер, который может проверить наличие определенной суммы на счете пользователя.

При этом передача данных возможна только с согласия субъекта этих данных, что гарантирует их безопасность.

Шведская платформа открытого банкинга Tink утверждает, что лидирующие европейские банки не смогли обеспечить необходимые технологии для предоставления TPPs доступа к своим данным к 14 июня 2019 года — предварительному дедлайну, поставленному за 3 месяца до финальной даты. Tink попытался опробовать 84 APIs, представляющие 2500 банков на 12 рынках. Хотя 69% APIs были готовы к назначенной дате, их качество оказалось недостаточным для соответствия регуляторным стандартам.

Великобритания
Великобритания

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

В 2012 году был создан Open Data Institute, целью которого стали исследования в области открытой технологии передачи данных. В 2014 году институт выпустил отчет, в котором рассказывал о возможностях API для data sharing. Спустя год по запросу HM Treasury была сформирована организация Open Banking Working Group, чтобы «изучать, как данные могут быть использованы, чтобы помогать людям платить, экономить, давать и брать взаймы и инвестировать деньги, и обеспечивать стандарты для защиты этих данных». Наконец, в августе 2016 году Competition and Markets Authority (CMA) опубликовало директиву, которая требовала от девяти крупнейших банков страны предоставлять лицензированным стартапам данные о клиенте.

Дедлайном для внедрения открытых интерфейсов стало 13 января 2018 года. Тем не менее к тому моменту только четыре банка — Allied Irish Bank, Danske Bank, Lloyds Banking Group и Nationwide Building Society — оказались к этому готовы. Barclays, Bank of Ireland, RBS и HSBC запросили дополнительные шесть недель, а банк Cater Allen, дочерняя компания Santander, получил еще год. Open Banking Implementation Entity (OBIE), созданная в 2016 году для внедрения Open Banking, в январе 2019 года раскрыла, что на рынке Великобритании уже есть 100 регулируемых TPPs, и 17 из них используют открытые интерфейсы. Технология Open Banking использовалась 17,5 млн раз в ноябре 2018 года — существенный рост по сравнению с 6,5 млн в сентябре.

«Согласно принятому в Великобритании акту, девять крупнейших банков должны были внедрить Open API и дать доступ к своим данным другим, небольшим банкам или финтех-сервисам. Акт должен был повысить конкуренцию на рынке физлиц и малого бизнеса, дать больший доступ этой аудитории к банковским услугам и сделать их менее зависимыми от каждого из банков.

При этом была создана отдельная структура Open Banking Implementation Entity (openbanking.org.uk), существующая на взносы этих банков. Она контролирует внедрение Open API и дает рекомендации по осуществлению перехода. Для реализации концепции Open Banking была прописана дорожная карта, на мой взгляд, вполне логичная. Однако реализована пока лишь малая часть, причем скорее информационная, чем транзакционная».

Источник: rb.ru