Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 180
Таки OAuth или OAuth 2?
Оба.
Большинство — OAuth 2, но на твиттере пока первый.
Большинство — OAuth 2, но на твиттере пока первый.
Первый ад и коровники. Второй нормальный и имеет RFC. Но есть одна маааленькая неувязочка. Информацию по пользователю все отдают как во что гаразд и стандарта нет. Так что приходится городить на каждого провайдера свою доставалку информации о клиенте.
А просто аутентификацию все одинаково реализуют? У всех пути одинаковы?
на второй — стандарта еще нет, есть довольно активно изменяющийся «черновик» стандарта.
А на первый — да выглядит адско, но не требует SSL, есть фиксированный стандарт и рабочие проверенные библиотеки.
Думаю что первый за счет своих плюшек проживет довольно долго, потому как второй Oauth идет по пути намеренного упрощения, что сужает сценарии использования т.к. SSL-must-have и предположение о том, что SSL не скомпроментирован (которое в общем наивно в свете всех новых техник...).
А на первый — да выглядит адско, но не требует SSL, есть фиксированный стандарт и рабочие проверенные библиотеки.
Думаю что первый за счет своих плюшек проживет довольно долго, потому как второй Oauth идет по пути намеренного упрощения, что сужает сценарии использования т.к. SSL-must-have и предположение о том, что SSL не скомпроментирован (которое в общем наивно в свете всех новых техник...).
У нас более-менее получилось сделать универсально, в конфиге просто описываем ожидаемые поля возврата и делаем маппинг под свои. С email-ами проблема, иногда их приходится сочинять из имеющегося никнейма, но в нашем случае oauth-пользователь имеет ограниченный доступ, поэтому нормально.
Когда читал первые материалы по OAuth, то идея показалась очень интересной, но глядя на портяки кода для каждого сайта я каждый раз задумываюсь, то ли я неправильно понял в первый раз, то ли сайты как-то неправильно его реализуют, то ли ещё что, но почемуто нельзя, чтобы пользователь ввёл в простой инпут имя сайта, предоставляющего OAuth, а я должен предусмотреть на каких сайтах с OAuth мой посетитль может быть зарегистрирован. Причём, насколько я понимаю, догадаться о том какие сайт его предоставляют и как они пересекаются с моей аудиторией я должен сам.
Согласен, разная реализация крайне напрягает. Причём отличия настолько незначительны. В одном случае запрос надо делать через GET, в другом через POST, где-то redirect надо указывать в настройках приложения, а где-то передавать параметром. Плюс больше всего (лично меня) напрягают разные URL для запросов.
Вот например Вконтакте (без параметров):
oauth.vk.com/authorize (ссылка для авторизации и получения code)
api.vk.com/oauth/access_token (получения токена)
api.vk.com/method/getProfiles (метод для получения анкетной инфы)
А вот Facebook:
www.facebook.com/dialog/oauth
graph.facebook.com/oauth/access_token
graph.facebook.com/me
При этом передаваемые параметры тоже отличаются. К чем я это всё… а то что действительно стандарт вроде есть, а реализация различается настолько, что к каждому новому провайдеру нужен свой подход и это печально.
Жду не дождусь OAuth 3.0.
Вот например Вконтакте (без параметров):
oauth.vk.com/authorize (ссылка для авторизации и получения code)
api.vk.com/oauth/access_token (получения токена)
api.vk.com/method/getProfiles (метод для получения анкетной инфы)
А вот Facebook:
www.facebook.com/dialog/oauth
graph.facebook.com/oauth/access_token
graph.facebook.com/me
При этом передаваемые параметры тоже отличаются. К чем я это всё… а то что действительно стандарт вроде есть, а реализация различается настолько, что к каждому новому провайдеру нужен свой подход и это печально.
Жду не дождусь OAuth 3.0.
А зачем вы так наивно смешиваете авторизацию и обращения к Апи? Последние урлы в обоих блоках это уже работа с АПИ.
OAuth 2.0 довольно простая и понятная штука, только осваивать ее надо не по экспериментам а почитав драфт страндарта ( который кстати еще не устаканился). тогда и вопросов не будет — надо или не надо передавать в урле или регистрировать приложение. Там все просто — есть то, что приложение должно делать — все «имена и фамилии» там совпадают, а есть то, что может делать (или может не делать). И тут уже на усмотрение реализующего. Вас же не удивляет что на разных сайтах страницы называются по-разному, так почему же претензии к адресам\endpoint'ам?
Это касается и редиректов\урлей — в реальности нужно минимум 2, (максимум 3 адреса еще один удобен для получения неподписанного токена, хотя часто это делают прям в момент выдачи авторизационного кода). А все параметры которые нужно передавать — зафиксированы в драфте стандарта. даже имена совпадают…
OAuth 2.0 довольно простая и понятная штука, только осваивать ее надо не по экспериментам а почитав драфт страндарта ( который кстати еще не устаканился). тогда и вопросов не будет — надо или не надо передавать в урле или регистрировать приложение. Там все просто — есть то, что приложение должно делать — все «имена и фамилии» там совпадают, а есть то, что может делать (или может не делать). И тут уже на усмотрение реализующего. Вас же не удивляет что на разных сайтах страницы называются по-разному, так почему же претензии к адресам\endpoint'ам?
Это касается и редиректов\урлей — в реальности нужно минимум 2, (максимум 3 адреса еще один удобен для получения неподписанного токена, хотя часто это делают прям в момент выдачи авторизационного кода). А все параметры которые нужно передавать — зафиксированы в драфте стандарта. даже имена совпадают…
Поймите меня правильно, меня действительно напрягает то, что протокол реализован у разных провайдеров немного по-разному. И в основном всё это было риторически…
Протокол описывается стандартом. Вернее пока еще draft 27 (ого, недавно был 25) — tools.ietf.org/html/draft-ietf-oauth-v2-27
Никто его не реализует по-своему. Ну есть только версии одного драфта — кто-то реализовывал версию 22, кто-то 14, но там детали обычному пользователю не сильно заметны.
Endpoint'ы для запроса токена у всех разные (хотя суть их — как описывает стандарт). И у нас тоже свои имена endpoint'ов, это нормально, 2 строки в конфиге для каждого провайдера — не много работы.
Никто его не реализует по-своему. Ну есть только версии одного драфта — кто-то реализовывал версию 22, кто-то 14, но там детали обычному пользователю не сильно заметны.
Endpoint'ы для запроса токена у всех разные (хотя суть их — как описывает стандарт). И у нас тоже свои имена endpoint'ов, это нормально, 2 строки в конфиге для каждого провайдера — не много работы.
На самом деле в .NET есть прекрасная библиотека DotNetOpenAuth, которая, при желании, спрячет от вас все детали реализации. Вот только там абстракция довольно глубокая (чуть ли не отвязка от http протокола), а сам протокол OAuth довольно простой, чтобы его можно было реализовать и руками. Прочтите один-два раза стандарт и все встанет на свои места.
PS Хотя я допускаю что отдельные деятели могли накосячить в своей реализации, или схалтурничать
PS Хотя я допускаю что отдельные деятели могли накосячить в своей реализации, или схалтурничать
Во-первых, по отношению к пользователю намного дружелюбнее будет предоставлять на выбор несколько заготовленных вариантов.
Во-вторых, OAuth изначально задумывался как протокол авторизации, что подразумевает априорную информацию не только о конкретных OAuth-powered сайтах, но и о ресурсах/действиях на них, требующих авторизации.
Уже когда OAuth начали использовать и для простой аутентификации, стандарт стал пытаться поддерживать оба workflow.
Во-вторых, OAuth изначально задумывался как протокол авторизации, что подразумевает априорную информацию не только о конкретных OAuth-powered сайтах, но и о ресурсах/действиях на них, требующих авторизации.
Уже когда OAuth начали использовать и для простой аутентификации, стандарт стал пытаться поддерживать оба workflow.
стандарт не стал пытаться поддерживать оба workflow, он как был авторизацией так и остался. Просто сайты предоставили некоторые отдельные апи не для совершения действий от имени пользователя а для получения информации об этом пользователе. Т.к. информация у них «надежная» (т.е. вы доверяете тому, что ФБ вас не обманет, отдавая email пользователя), то вы можете использовать ее для того, чтобы аутентифицировать клиента у себя на сайте.
Это никак не противоречит единственному предназначению протокола OAuth 2.0 — авторизации.
:)
Это никак не противоречит единственному предназначению протокола OAuth 2.0 — авторизации.
:)
Разная реализация только у одной вещи под названием взять данные о пользователе. И эта часть вообще не описана в OAuth. То что описано в draft работает если сайт заявляет совместимость с oAuth 2.0
Ну вот смотрю что у разных сайтов разные URL, различающиеся не только доменом, но и путями. Беглый просмотр стандарта тоже не показал, что пути им специфицируются. То есть для реализации аутентификации пользователя на произвольном сервере, мне нужно сделать поле для ввода полного URL а не домена. И хорошо если хватит одного поля, а не несколько URL вводить нужно будет пользователю.
Ну вот смотрю что у разных сайтов разные URL, различающиеся не только доменом, но и путями.
Внимательно посмотрите и сравните со стандартом. Увидите, что на самом деле пути специфицированы.
То есть для реализации аутентификации пользователя на произвольном сервере, мне нужно сделать поле для ввода полного URL а не домена.
Вы не сможете сделать реализацию аутентификации пользователя на произвольном домене. Потому что вам требуется иметь уникальный идентификатор и секретный хеш от этого сервера. А если у вас они есть, то и url все необходимые у вас есть.
Внимательно посмотрите и сравните со стандартом. Увидите, что на самом деле пути специфицированы.
То есть для реализации аутентификации пользователя на произвольном сервере, мне нужно сделать поле для ввода полного URL а не домена.
Вы не сможете сделать реализацию аутентификации пользователя на произвольном домене. Потому что вам требуется иметь уникальный идентификатор и секретный хеш от этого сервера. А если у вас они есть, то и url все необходимые у вас есть.
Поле для ввода URL OAuth от пользователя? да вы герой, ну или кандидат на новости о взломе…
Oauth не предполагает доверие всем подряд ( в отличии от OpenId) — вы, как владелец сервиса, сами определяете, каким внешним OAuth сервисам будете доверять.
Oauth не предполагает доверие всем подряд ( в отличии от OpenId) — вы, как владелец сервиса, сами определяете, каким внешним OAuth сервисам будете доверять.
Я как раз не люблю OAuth. Не люблю связывать свой эмейл (в случае с гмейлом) или профиль социалки (контактик) с каким-то левым сайтом…
А фейсбука (90% зарубежных OAuth авторизаций требуют его и чуть ли не только его) у меня вообще нету.
А фейсбука (90% зарубежных OAuth авторизаций требуют его и чуть ли не только его) у меня вообще нету.
Это не говоря о том, что OAuth любит запрашивать всякую инфу. И нельзя снять галочку с «предоставить эту инфу» — можно либо полностью согласиться, либо идти лесом и остаться незарегистрированным гостем.
в фэйсбуке было можно некоторое время. Сейчас — давно не пользовался. можно было предоставить только Core needs ( без которых нельзя), а остальное опционно отозвать. Но это авторская реализация, стандарт такому не обязывает (хотя дает возможности сделать)
А если вы слабо доверяете приложению — я бы туда даже емейл не вбивал, не говоря о том, что авторизовывать его на ФБ…
А если вы слабо доверяете приложению — я бы туда даже емейл не вбивал, не говоря о том, что авторизовывать его на ФБ…
Никто вам не запрещает в любой момент отключить доступ к вашему аккаунту, это делается в настройках профиля.
Может быть просто loginza?
или ulogin
Loginza и прочие подобные сервисы проще, но!
— нет возможностей для кастомизации
— по отзывам часто глючит
— вы не застрахованы от того, что в какой-то момент сервис просто «упадёт»
— нет возможностей для кастомизации
— по отзывам часто глючит
— вы не застрахованы от того, что в какой-то момент сервис просто «упадёт»
За месяц более 17М входов через ulogin, я подозреваю что они заботятся о том, чтобы у них не падали сервера.
Ходят слухи, что можно кастомизировать кнопки, обратившись в техподдержку.
Ходят слухи, что можно кастомизировать кнопки, обратившись в техподдержку.
у Ulogin зато есть свои плюшки, падает/ломается все…
нет, для гадов, требующих регистрацию — только bugmenot
Об этом написано в тексте «Почему OAuth, а не виджет».
Меня не устраивают функционал, дизайн и надежность виджета
Меня не устраивают функционал, дизайн и надежность виджета
омг зачем, oauth2 и так простой
Использую в своем проекте ее. Но из-за невозможности настроить ее, часть пользователей проходят мимо. Жалоба, например, логинза хочет иметь доступ к контактам из гмеила. Захрен ее это надо не ясно. Со стимом рабоатет коряво.
Спрошу здесь, оффтопиком:
Интересно почитать про то как написать сервер OAuth?
Интересно почитать про то как написать сервер OAuth?
могу нарватся на звание Капитана, но берете спецификацию версии, которую хотите реализировать и делаете. Есть сущности тоукена, рефреш тоукена, кода авторизации. Жонглируйте в своем приложении как хотите. В некоторой мере использование 3rd parties библиотек скорее создает ограничения, чем преимущество, так как имплементация что на сервере что на клиенте очень тривиальная.
Я пользую github.com/honza/oauth-service =)
Есть еще на основе всяких REST-фрэймворков для django типа tastypie/piston.
Вообще ведь не очень сложно написать используя что-то типа django'вской django-tastypie — я думаю в каждом языке/фреймворке найдется куча аналогов.
Есть еще на основе всяких REST-фрэймворков для django типа tastypie/piston.
Вообще ведь не очень сложно написать используя что-то типа django'вской django-tastypie — я думаю в каждом языке/фреймворке найдется куча аналогов.
Очень просто. Берете стандарт указанный выше и пишите по нему серверную часть. Никакой ракетной науки там нет. Реализация именно сервера займет максимум страницу кода. Если остальные свистелки добавлять типа админки, регистрации сайтов и т.п. то немного побольше.
провайдер? мне — да, интересно. смотря какой язык
Можно написать свой, например, на Rails для этого есть Doorkeeper:
doorkeeper
wiki/Example-Applications
wiki
doorkeeper
wiki/Example-Applications
wiki
Я не люблю зависеть от всяких loginza или ulogin
Предпочитаю сам к сайту прикрутить django-social-auth, где представлены следующие бэкенды для авторизации:
OpenId, OAuth, Twitter, Facebook, Orkut, Google OAuth, Google OAuth2, LinkedIn, GitHub, Bitbucket, Dropbox, Flickr, BrowserID, Instagram, Vkontakte, MSN Live Connect, Skyrock, Yahoo OAuth, Evernote OAuth, Yandex OAuth and OpenID, Mail.ru OAuth, Odnoklassniki.ru а еще отдельно добавляю last.fm, tumblr.com бэкенды.
Предпочитаю сам к сайту прикрутить django-social-auth, где представлены следующие бэкенды для авторизации:
OpenId, OAuth, Twitter, Facebook, Orkut, Google OAuth, Google OAuth2, LinkedIn, GitHub, Bitbucket, Dropbox, Flickr, BrowserID, Instagram, Vkontakte, MSN Live Connect, Skyrock, Yahoo OAuth, Evernote OAuth, Yandex OAuth and OpenID, Mail.ru OAuth, Odnoklassniki.ru а еще отдельно добавляю last.fm, tumblr.com бэкенды.
Там еще foursquare есть и еще какие-то. Ну и свой бэкенд не сложно написать если у сайта есть Oauth API или OpenID. С loginza/ulogin своего бэкенда не подключишь)
Кстати практически никакой сервис типа loginza/ulogin не поддерживает Mozilla'вский BrowserID.
Какой процент пользователей использует BrowserID? Пока это только фишки, которые, возможно, стартанут в будущем… Вероятно, если BrowserID станет популярен, то loginza/ulogin их добавят.
Ну некоторые гики пользуют и то мало среди них русских. Кстати, поддержка BrowserID добавлена в django-social-auth по моей наводке.
Естественно по статистике этих самых ulogin/loginza окажется что доля никакая — потомучто никто не поддерживает.
Я вот к примеру не хочу писать какие-либо комменты или регистрироваться от лица своих аккаунтов на твиттере или фейсбуке. Мне удобнее BrowserID.
Естественно по статистике этих самых ulogin/loginza окажется что доля никакая — потомучто никто не поддерживает.
Я вот к примеру не хочу писать какие-либо комменты или регистрироваться от лица своих аккаунтов на твиттере или фейсбуке. Мне удобнее BrowserID.
можешь пожалуйста дать пару django сайтов где этот плагин используется?
Всё замечательно, но один момент — чтобы мне, например сделать авторизацию через OAuth на том же Вконтакте или Фейсбуке — надо там зарегистрироваться…
Да, надо. Если вдуматься, это логично. С чего бы тому же ВКонтакту или Фейсбуку давать доступ практически ко всем своим механизмам какому-то неизвестному сайту? Один из немаленьких плюсов авторизации по OAuth это как раз доступ к API сервера. Так зарегистрированный пользователь оставит на сайте в лучшем случае свой пол, город и возраст. А обычно и вовсе ограничится требуемым минимумом. А с зашедшего со ВКонтакта — столько можно инфы натащить, что ой :)
Не то, чтобы эта инфа была нужна, но наличие возможности её получить — не помешает.
Не то, чтобы эта инфа была нужна, но наличие возможности её получить — не помешает.
Ну я как вебмастер, например, хочу дать пользователям возможность зайти через ВКонтакт. Но сам не согласен с его условиями регистрации, что делать?
Использовать vkontakteid.ru, например. Там OpenID.
Вы так минусуете, как будто есть другие варианты :)
OpenID хорош до тех пор пока вы не наткнулись на самописного опенид провайдера который отдает трэш по желанию автора. Поддерживать openId только от сайта Х — странно, т.к. провайдеров очень много, обычно поддерживают «любой openId»
Захотят подсунуть треш — кто мешает зарегать под это дело новый email на яндексе или гугле?
Как по мне, OpenID хорош тем, что, в отличие от OAuth, он таки предназначен именно для аутентификации. А то, что описывает автор в статье — это типичный misuse, использование не по назначению. Отсюда и геморрой с индивидуальным подключением каждого сайта, что для аутентификации явно перебор.
Для сервиса OpenID удобен тем, что не требуется реализовывать особую поддержку для разных сайтов. Пользователь ввёл свой url — и его проверка выполняется одинаково, вне зависимости от того, на какой сайт он ведёт. При желании, можно реализовать упрощённый вход для некоторых крупных OpenID провайдеров спрашивая имя юзера, а не url, но это мелочь ничего принципиально не усложняющая.
Для пользователей OpenID удобен тем, что они могут контролировать какая информация к нему привязана, включая полное отсутствие этой информации. Кроме того, это позволяет не давать левым сервисам доступ (даже ограниченный) к своим аккаунтам в других сервисах. И других плюсов тоже куча, хотя, да, большая их часть нафиг не нужна людям, которые не видят ничего плохого в выкладывании моря информации о себе в сеть, связывания вместе информации о себе находящейся на разных сайтах, и предоставления доступа к этой информации кому попало.
Как по мне, OpenID хорош тем, что, в отличие от OAuth, он таки предназначен именно для аутентификации. А то, что описывает автор в статье — это типичный misuse, использование не по назначению. Отсюда и геморрой с индивидуальным подключением каждого сайта, что для аутентификации явно перебор.
Для сервиса OpenID удобен тем, что не требуется реализовывать особую поддержку для разных сайтов. Пользователь ввёл свой url — и его проверка выполняется одинаково, вне зависимости от того, на какой сайт он ведёт. При желании, можно реализовать упрощённый вход для некоторых крупных OpenID провайдеров спрашивая имя юзера, а не url, но это мелочь ничего принципиально не усложняющая.
Для пользователей OpenID удобен тем, что они могут контролировать какая информация к нему привязана, включая полное отсутствие этой информации. Кроме того, это позволяет не давать левым сервисам доступ (даже ограниченный) к своим аккаунтам в других сервисах. И других плюсов тоже куча, хотя, да, большая их часть нафиг не нужна людям, которые не видят ничего плохого в выкладывании моря информации о себе в сеть, связывания вместе информации о себе находящейся на разных сайтах, и предоставления доступа к этой информации кому попало.
Знаете, зарегать много аккаунтов на гугле — куда сложнее чем написать свой сервис openID который каждый раз будет отдавать псевдо-правдивые данные. Все же тут направление — обойти запрет массовой регистрации. Крупные сервисы с этим стараются бороться.
OpenId, со всеми их namespace и расширениями — та еще «бядаа» к тому же там вроде есть фундаментальные проблемы (сейчас сходу не вспомню) и кроме «быстрой регистрации» оно ни на что особо не годен.
И да, вы не можете доверять «любому» OpenID сервису для аутентификации ( или вам аутентифицировать надо только по полному OpenID имени, т.е. логин будет не удобный centur а centur.myopenid.com, т.е. юзернейм-на-сервисе. Потому что на другом сервисе под тем же ником может быть другой пользователь.
И да, никто не мешает для своего openid сервера на centur.myhackenid.com отдавать чужой email. Если активно используете email — прийдется валидировать владельца все равно, а в случае с Oauth — вы доверяете конкретному сервису и даже можете получить больше данных чем из openid, т.к. сервис что-то делает обязательным, а openid предлагает определить набор предоставляемых данных самому пользователю
Да, с OpenId тоже можно доверять 1-2 сервакам, но тогда вся его openness исчезает.
OpenId, со всеми их namespace и расширениями — та еще «бядаа» к тому же там вроде есть фундаментальные проблемы (сейчас сходу не вспомню) и кроме «быстрой регистрации» оно ни на что особо не годен.
И да, вы не можете доверять «любому» OpenID сервису для аутентификации ( или вам аутентифицировать надо только по полному OpenID имени, т.е. логин будет не удобный centur а centur.myopenid.com, т.е. юзернейм-на-сервисе. Потому что на другом сервисе под тем же ником может быть другой пользователь.
И да, никто не мешает для своего openid сервера на centur.myhackenid.com отдавать чужой email. Если активно используете email — прийдется валидировать владельца все равно, а в случае с Oauth — вы доверяете конкретному сервису и даже можете получить больше данных чем из openid, т.к. сервис что-то делает обязательным, а openid предлагает определить набор предоставляемых данных самому пользователю
Да, с OpenId тоже можно доверять 1-2 сервакам, но тогда вся его openness исчезает.
Вы смешиваете в одну кучу разные задачи.
OpenID решает одну простую проблему: избавляет юзера от необходимости придумывать на каждом сайте логин/пароль и вводить своё имя, ник и email. Что увеличивает вероятность того, что юзер таки зарегистрируется на сайте, а не плюнет и закроет страничку увидев очередную форму регистрации. Причём OpenID никак не уменьшает безопасность или приватность если юзер воспользуется возможностью поднять OpenID-провайдер на своём сайте.
Это не избавляет сайт от необходимости проверять email юзера (впрочем, юзеру кликнуть reply-send или по ссылке в письме обычно не очень трудно) или использовать капчу для защиты от массовых регистраций.
Что касается «неудобного логина centur.myopenid.com» то это не так — OpenID предоставляет возможность получить ник юзера, который по сути и есть короткий предпочитаемый логин.
Что касается попытки избежать ввода капчи и проверки email при работе с доверенными сервисами — никто не мешает точно так же доверять тем же самым сервисам при работе с ними по OpenID — если вы доверяете гуглу по OAuth, почему вы считаете, что по OpenID он вам пришлёт какие-то другие данные, которым нельзя точно так же доверять? При таком подходе распознав «доверенного» OpenID-провайдера вы просто пропускаете запрос капчи и валидацию email, только и всего.
Если же вам категорически необходимо полностью отказаться от своей собственной формы регистрации (оставив только вход через чужие сервисы), вы почему-то не хотите реализовывать проверку капчи и email-а, и вам жизненно необходимо получить кучу дополнительной информации о пользователе (вроде страны/города) — тогда да, ничего кроме как использовать не по назначению OAuth и морочиться описанным в статье геморроем вам не остаётся. Просто понимайте, почему и для чего вы это делаете — что этот подход не облегчает жизнь пользователю, более того он активно нарушает privacy пользователя, а в плане реализации он просто заменяет одни задачи (реализацию капчи и проверки email) на другие (описанные в статье).
OpenID решает одну простую проблему: избавляет юзера от необходимости придумывать на каждом сайте логин/пароль и вводить своё имя, ник и email. Что увеличивает вероятность того, что юзер таки зарегистрируется на сайте, а не плюнет и закроет страничку увидев очередную форму регистрации. Причём OpenID никак не уменьшает безопасность или приватность если юзер воспользуется возможностью поднять OpenID-провайдер на своём сайте.
Это не избавляет сайт от необходимости проверять email юзера (впрочем, юзеру кликнуть reply-send или по ссылке в письме обычно не очень трудно) или использовать капчу для защиты от массовых регистраций.
Что касается «неудобного логина centur.myopenid.com» то это не так — OpenID предоставляет возможность получить ник юзера, который по сути и есть короткий предпочитаемый логин.
Что касается попытки избежать ввода капчи и проверки email при работе с доверенными сервисами — никто не мешает точно так же доверять тем же самым сервисам при работе с ними по OpenID — если вы доверяете гуглу по OAuth, почему вы считаете, что по OpenID он вам пришлёт какие-то другие данные, которым нельзя точно так же доверять? При таком подходе распознав «доверенного» OpenID-провайдера вы просто пропускаете запрос капчи и валидацию email, только и всего.
Если же вам категорически необходимо полностью отказаться от своей собственной формы регистрации (оставив только вход через чужие сервисы), вы почему-то не хотите реализовывать проверку капчи и email-а, и вам жизненно необходимо получить кучу дополнительной информации о пользователе (вроде страны/города) — тогда да, ничего кроме как использовать не по назначению OAuth и морочиться описанным в статье геморроем вам не остаётся. Просто понимайте, почему и для чего вы это делаете — что этот подход не облегчает жизнь пользователю, более того он активно нарушает privacy пользователя, а в плане реализации он просто заменяет одни задачи (реализацию капчи и проверки email) на другие (описанные в статье).
Да, да, и еще тысячу раз «да». Всё верно.
Вот только подавляющему большинству пользователей наплевать на свою privacy, но, в то же время, очень тяжко нажать хотя бы одну лишнюю клавишу.
Мне (как подавленному меньшинству) это тоже очень грустно, но (как админ нескольких ресурсов) я не имею права проигнорировать эту тенденцию.
Вот только подавляющему большинству пользователей наплевать на свою privacy, но, в то же время, очень тяжко нажать хотя бы одну лишнюю клавишу.
Мне (как подавленному меньшинству) это тоже очень грустно, но (как админ нескольких ресурсов) я не имею права проигнорировать эту тенденцию.
Лично я — не смешиваю, я их очень хорошо отличаю.
OpenId — это быстрая регистрация. Проблема «быстрой регистрации» в том, что ее очень любят боты.
OAuth 1.0 и 2.0 — это способ авторизации стороннего приложения для доступа к ресурсам от имени пользователя. Для аутентификации это используется так, что спрашивается емейл пользователя и этому ответу доверяем.
Касательно «кликнуть по ссылке» — это не так, пользователи обычно ленивы и не ходят в почту, кривая почта может попасть в спам или вообще быть убитой на сервере, не дойдя до ящика пользователя. Все это не увеличивает количество пользователей с проверенными email.
В случае с доверием ЛЮБОМУ OpenID провайдеру (доверять 1-2-3 и не доверять другим — работает, но выглядит дико) — есть простая проблема. Я напишу свой openId сервер таким образом, что он будет ВСЕГДА генерить рэндомные комбинации юзернейма, email на моем домене ( или на mailinator.com) и будет сам активировать присланные письма. И добро пожаловать в мир миллиона халявно зарегистрированных аккаунтов на вашем сервере.
Если же мы доверяем «только нескольким» серверам Oauth\OpenID — то мы предполагаем что там и email уже валидный, можно самому не валидировать (если там не валидный- это значит большие проблемы), и что сами сервисы умеют хорошо защищаться от массовой регистрации аккаунтов у них самих, ну хотя бы получше чем вы сами.
Но даже в этом случае (это касательно «удобного логина») никто не защитит вас от сценария, когда вы зареганы на OpenID-Provider-1 и желаемый login у вас user1 а почта user1@gmail.com, а я зареган на OpenID-Provider-2, а вот никнейм (суть логин) я вписал тоже user1. А еще если мой провайдер кривой и НЕ проверяет почту на владение (т.е. при вводе почты вам нужно перейти по ссылке ) или я как-то смог подтвердить почту user1@gmail.com, то я легко зайду под вашим аккунтом в сайт, который доверяет обоим провайдерам.
Поэтому мечты об удобном предпочитаемом логине user1, а не user1.OpenId-Provider-1 идут далеко и надолго. Это вроде очевидно.
В остальном же про капчу\емейл и т.д, в общем возражений нету и я говорил примерно то же самое что и вы. Для меня OAuth технически удобней OpenID, даже если он используется не по назначению.
А так — почта, только почта может честно, уникально и удобно идентифицировать юзера ;)
OpenId — это быстрая регистрация. Проблема «быстрой регистрации» в том, что ее очень любят боты.
OAuth 1.0 и 2.0 — это способ авторизации стороннего приложения для доступа к ресурсам от имени пользователя. Для аутентификации это используется так, что спрашивается емейл пользователя и этому ответу доверяем.
Касательно «кликнуть по ссылке» — это не так, пользователи обычно ленивы и не ходят в почту, кривая почта может попасть в спам или вообще быть убитой на сервере, не дойдя до ящика пользователя. Все это не увеличивает количество пользователей с проверенными email.
В случае с доверием ЛЮБОМУ OpenID провайдеру (доверять 1-2-3 и не доверять другим — работает, но выглядит дико) — есть простая проблема. Я напишу свой openId сервер таким образом, что он будет ВСЕГДА генерить рэндомные комбинации юзернейма, email на моем домене ( или на mailinator.com) и будет сам активировать присланные письма. И добро пожаловать в мир миллиона халявно зарегистрированных аккаунтов на вашем сервере.
Если же мы доверяем «только нескольким» серверам Oauth\OpenID — то мы предполагаем что там и email уже валидный, можно самому не валидировать (если там не валидный- это значит большие проблемы), и что сами сервисы умеют хорошо защищаться от массовой регистрации аккаунтов у них самих, ну хотя бы получше чем вы сами.
Но даже в этом случае (это касательно «удобного логина») никто не защитит вас от сценария, когда вы зареганы на OpenID-Provider-1 и желаемый login у вас user1 а почта user1@gmail.com, а я зареган на OpenID-Provider-2, а вот никнейм (суть логин) я вписал тоже user1. А еще если мой провайдер кривой и НЕ проверяет почту на владение (т.е. при вводе почты вам нужно перейти по ссылке ) или я как-то смог подтвердить почту user1@gmail.com, то я легко зайду под вашим аккунтом в сайт, который доверяет обоим провайдерам.
Поэтому мечты об удобном предпочитаемом логине user1, а не user1.OpenId-Provider-1 идут далеко и надолго. Это вроде очевидно.
В остальном же про капчу\емейл и т.д, в общем возражений нету и я говорил примерно то же самое что и вы. Для меня OAuth технически удобней OpenID, даже если он используется не по назначению.
А так — почта, только почта может честно, уникально и удобно идентифицировать юзера ;)
Все это не увеличивает количество пользователей с проверенными email.От жеж дался Вам этот проверенный email! Я, как и все, зареган на сотнях сайтов. И при этом практически никто из них никогда не присылает мне никаких писем. Ибо для их функциональности это не требуется. Вопрос1: нафига им всем мой email? Вопрос2: нафига мне им давать свой настоящий, регулярно читаемый email?
Регистрация на сайте нужна для того, чтобы отличать одного пользователя от другого. Для этого нужен логин+пароль либо OpenID, email для этого не нужен.
Сайтам, которые требуют email, но письма от которых мне не нужны (т.е. практически всем) я как правило подсовываю специально под это дело открытый ящик на яндексе. И захожу в него исключительно тогда, когда ожидаю получить письмо проверяющее мой email. Ну и радости вам от такого проверенного email? (При необходимости, точно так же заводится фейковый аккаунт в каком-нить фейсбуке, на тот же левый email, и используется для регистрации/логина на сайтах.)
А в тех случаях, когда пользователь заинтересован в получении писем от вашего сайта — он сам побеспокоится указать настоящий email и без проблем верифицирует его.
В общем, получается так, что единственная реальная причина по которой абсолютное большинство сайтов может так сильно хотеть узнать мой активно используемый email — спам и реклама. А регистрация на сайте — это просто удобный повод этот email получить.
неа, для того чтобы вы могли отличать одного пользователя от другого — вам не нужна регистрация. Можно тупо взять юзерагента+ плагины с версиями и получится очень уникальная строка. Где-то в юса-вузе это уже показали на практике.
Регистрация это способ предоставить пользователю, и только ему, персонализированное взаимодействие с сайтом. например хранение документов пользователя в гугль докс. Для этого нужен некий «разделяемый секрет», который знает пользователь и который может проверить сайт (эээ пароль ;) и хэш пароля у сайта в простейшем случае).
Если приложение не хочет или не может хранить инфу для проверяемого секрета, оно может перевалить эту обязанность другому сайту ( это некоторая вольная интерпретация). Например если наш сайт Х доверяет тому, как гугл хранит и защищает пароли пользователей, то мы, делая вход через гугл, декларируем следующее: «Я доверяю гуглу, поэтому я не буду сам проверять ваш пароль, а пусть гугл проверит ваш пароль на нем, а мне скажет ваш логин. Вот как он скжет, так я вас и залогиню». Все, вы можете не хранить хэши паролей вообще, а просто собрать набор сайтов, которым вы доверяете и жить на этом «доверии».
Если один из таких доверенных сайтов фэйлит — у вас проблемы, т.к. в чужой акк на вашем сервере можно зайти обманув доверенный сервер.
OpenId изначально не предполагает такой уровень доверия, OpenId говорит как бы — «Сайт, вот тебе строка моего логина на сайте, по стандартному протоколу ты можешь получить обо мне всю информацию что я завел».
Но это никак не подтвердит что вы — именно тот человек, который это заводил. Поэтому для быстрой регистрации опенид — допустим, а вот для дальнейшего регулярного входа на сайт — должно быть то же самое «доверие» к провайдеру. А провайдер может поручиться только за записи, которые явно с ним связаны, поэтому сайт должен держать связь логин+провайдер, что на самом деле ружит идею опенид почти полностью, потому как предполагалось что сайты будут доверять ЛЮБОМУ опенид провайдеру.
А все-таки насчет масс регистрации — одно дело когда сайт — это форум, ну пришли боты, потроллили и все такое. А другое дело — когда это некий сервис предоставляющий демо-услугу, а за больший объем хотящий денег. Вто там массовая регистрация позволит получить услугу в большем объеме (маленькими демо-кусочками) и возможно нанесет финансовый ущерб сайту.
Все в итоге зависит от того, что именно вы предоставляете и насколько важна для вас регистрация.
Регистрация это способ предоставить пользователю, и только ему, персонализированное взаимодействие с сайтом. например хранение документов пользователя в гугль докс. Для этого нужен некий «разделяемый секрет», который знает пользователь и который может проверить сайт (эээ пароль ;) и хэш пароля у сайта в простейшем случае).
Если приложение не хочет или не может хранить инфу для проверяемого секрета, оно может перевалить эту обязанность другому сайту ( это некоторая вольная интерпретация). Например если наш сайт Х доверяет тому, как гугл хранит и защищает пароли пользователей, то мы, делая вход через гугл, декларируем следующее: «Я доверяю гуглу, поэтому я не буду сам проверять ваш пароль, а пусть гугл проверит ваш пароль на нем, а мне скажет ваш логин. Вот как он скжет, так я вас и залогиню». Все, вы можете не хранить хэши паролей вообще, а просто собрать набор сайтов, которым вы доверяете и жить на этом «доверии».
Если один из таких доверенных сайтов фэйлит — у вас проблемы, т.к. в чужой акк на вашем сервере можно зайти обманув доверенный сервер.
OpenId изначально не предполагает такой уровень доверия, OpenId говорит как бы — «Сайт, вот тебе строка моего логина на сайте, по стандартному протоколу ты можешь получить обо мне всю информацию что я завел».
Но это никак не подтвердит что вы — именно тот человек, который это заводил. Поэтому для быстрой регистрации опенид — допустим, а вот для дальнейшего регулярного входа на сайт — должно быть то же самое «доверие» к провайдеру. А провайдер может поручиться только за записи, которые явно с ним связаны, поэтому сайт должен держать связь логин+провайдер, что на самом деле ружит идею опенид почти полностью, потому как предполагалось что сайты будут доверять ЛЮБОМУ опенид провайдеру.
А все-таки насчет масс регистрации — одно дело когда сайт — это форум, ну пришли боты, потроллили и все такое. А другое дело — когда это некий сервис предоставляющий демо-услугу, а за больший объем хотящий денег. Вто там массовая регистрация позволит получить услугу в большем объеме (маленькими демо-кусочками) и возможно нанесет финансовый ущерб сайту.
Все в итоге зависит от того, что именно вы предоставляете и насколько важна для вас регистрация.
«Сайт, вот тебе строка моего логина на сайте, по стандартному протоколу ты можешь получить обо мне всю информацию что я завел».Это как?! Во-первых, по OpenID вам никто никаких логинов не даёт. Вам дают url. Во-вторых, суть OpenID — это возможность проверить, что регистрирующийся или логинящийся человек действительно «контролирует» эту url.
Но это никак не подтвердит что вы — именно тот человек, который это заводил.
И хотя для некоторых сайтов возможно автоматически определить url узнав имя аккаунта на этих сайтах, суть от этого не меняется — спросив у юзера имя аккаунта вместо url вы просто немного улучшили юзабитили, но всё-равно вы первым делом вычисляете по аккаунту url, и проверяете по OpenID именно этот url.
Откуда Вы вообще взяли эту идею про связь «логин+провайдер» и каким боком тут OpenID?
Да, торопился ( выезжал на работу) и невнимательно выразился. Вы правы, OpenId действительно про доказательство контроля конкретного url, и «логин» там может только улучшить юзабилити, все равно будет сформирован ожидаемый урл. Все так.
И там далее, насколько помню, есть механизм, чтобы получить данные, которые ввел владелец урла, чтобы быстрее зарегистрировать владельца на сайте.
Но вот OpenId протокол не подтверждает, что пользователь, владеющий урлом, действительно владеет теми данными, которые он ввел. И создавать на основе этого аккаунт без проверки «владения» заявленным email не обойтись. Это необходимо в «общем» случае.
Если использовать только проверенные сервера-провайдеры openId (частный случай), которые сами требуют валидации email, тогда все ок.
Но такой подход противоречит самой идее OpenID — когда ты можешь войти на сайт, используя любой, даже собственный OpenId провайдер на домашнем сервере
И там далее, насколько помню, есть механизм, чтобы получить данные, которые ввел владелец урла, чтобы быстрее зарегистрировать владельца на сайте.
Но вот OpenId протокол не подтверждает, что пользователь, владеющий урлом, действительно владеет теми данными, которые он ввел. И создавать на основе этого аккаунт без проверки «владения» заявленным email не обойтись. Это необходимо в «общем» случае.
Если использовать только проверенные сервера-провайдеры openId (частный случай), которые сами требуют валидации email, тогда все ок.
Но такой подход противоречит самой идее OpenID — когда ты можешь войти на сайт, используя любой, даже собственный OpenId провайдер на домашнем сервере
Да, и к чему Вы продолжаете постоянно упоминать массовую регистрацию? Использование OpenID не мешает параллельно защищаться от массовой регистрации, это уже много раз упоминалось. Если лень прикрутить капчу — это основание для отказа от OpenID — дело Ваше, но надо отдавать себе отчёт, что это не с OpenID что-то не так, а просто Вам лениво.
Да не в капче дело, и не в лени. Я пытаюсь сказать, что openId — это только способ быстрой РЕГИСТРАЦИИ, после которой надо еще отдельно аутентифицировать пользователя.
Максимум, что можно использовать для секрета аутентификации — это сам url, владение которым пользователь заявил. А вот делать на основе этого «владения» предположения, что он владеет и email, который был возвращен провайдером — нельзя, email надо проверять отдельно ( или использовать только тех провайдеров, которые делают эту проверку за вас, т.е. ограниченный список)
Пустить на сайт означает аутентифицировать, а не зарегистрировать. Я могу зарегать аккаунт на ваш email, но без доступа к вашему ящику, я не смогу провалидировать мое «заявление» о том «я — владелец ящика». Эта проверка нужна для определенных сценариев
А OAuth в текущем виде и в сценарии его общепринятого «нетрадиционного использования» сможет именно подтвердить АУТЕНТИФИКАЦИЮ пользователя.
В этом вся разница, которую я хотел донести.
Максимум, что можно использовать для секрета аутентификации — это сам url, владение которым пользователь заявил. А вот делать на основе этого «владения» предположения, что он владеет и email, который был возвращен провайдером — нельзя, email надо проверять отдельно ( или использовать только тех провайдеров, которые делают эту проверку за вас, т.е. ограниченный список)
Пустить на сайт означает аутентифицировать, а не зарегистрировать. Я могу зарегать аккаунт на ваш email, но без доступа к вашему ящику, я не смогу провалидировать мое «заявление» о том «я — владелец ящика». Эта проверка нужна для определенных сценариев
А OAuth в текущем виде и в сценарии его общепринятого «нетрадиционного использования» сможет именно подтвердить АУТЕНТИФИКАЦИЮ пользователя.
В этом вся разница, которую я хотел донести.
OpenID это не способ регистрации! Это способ именно аутентификации пользователя, а что вы будете с этим делать дальше — регистрировать аккаунт или логинить в уже существующий — дело ваше.
OpenID позволяет аутентифицировать пользователя. Пользователя, а не его email. Вы постоянно говорите «пользователь», а подразумеваете при этом «проверенный email». А это разные понятия.
Изначально, на заре веба, email при регистрации на большинстве сайтов требовался для фичи «восстановление пароля». С OpenID нужды в этой фиче больше нет. Возникает вопрос: нафига большинству веб-проектов email пользователя? Отправлять пользователю разные полезные письма? Ну, если письма действительно полезные — пользователь сам побеспокоится о том, чтобы указать свой реальный email. И какая вам разница, пользователь указал настоящий email или левый, свой или чужой? На случай указания чужого email-а, просто добавляйте в письма ссылку «я не регистрировался на вашем сайте, кто-то использовал мой email» — будет вам валидация наоборот.
OpenID позволяет аутентифицировать пользователя. Пользователя, а не его email. Вы постоянно говорите «пользователь», а подразумеваете при этом «проверенный email». А это разные понятия.
Изначально, на заре веба, email при регистрации на большинстве сайтов требовался для фичи «восстановление пароля». С OpenID нужды в этой фиче больше нет. Возникает вопрос: нафига большинству веб-проектов email пользователя? Отправлять пользователю разные полезные письма? Ну, если письма действительно полезные — пользователь сам побеспокоится о том, чтобы указать свой реальный email. И какая вам разница, пользователь указал настоящий email или левый, свой или чужой? На случай указания чужого email-а, просто добавляйте в письма ссылку «я не регистрировался на вашем сайте, кто-то использовал мой email» — будет вам валидация наоборот.
ОКей… С точки зрения сферического коня — вы правы OpenId можно использовать для аутентификации и для регистрации. Вопрос — нужно ли?
Есть несколько «неудобств» OpenId, с которыми «обычно» не соглашаются интерфейс-дизайнеры:
1. Для аутентификации — надо ввести руками строку\урль, OAuth позволяет сделать то же самое действие одним кликом, или даже прозрачно на яваскрипте (см. StackOverflow например).
2. Для регистрации — надо провалидировать email (если он нужен, а в сервисах он обычно нужен, домашние странички васи даже регистрации не должны требовать ;) ).
Платформа предлагающая OAuth в этом случае «обычно» берет на себя проверку все того же пресловутого email (да да, кроме твиттера, которому даже переход на OAuth 2.0 не поможет), т.к. сервис-сайт все равно регистрируется для доступа к «платформе», то он может выбрать те, что предоставляют проверенные данные.
Итак п.1 неудобен т.к. батхертит пользователей — надо вбить урл вместо клика на кнопке «войти»
п.2 отвратитетелен тем, что сайт-сервис все равно должен проверить необходимые ему данные, это значит что для email нужно генерить линк, отправлять на почту, ждать захода по этому линку, после чего ставить галочку что да, пользователь наконец-то проверен и у него гарантированно правильный email.
Про полезность писем — вопрос другой. В большинстве случаев если сервис спрашивает, значит считает что письма полезные ( и попробуй переубеди его ;) ), т.е. email чаще нужен, чем нет.
Можно избежать п.2 и пускать только пользователей определенного набора провайдеров OpenID, которые сами требуют валидацию нужных вам данных.
Это, во-первых, приводит к ситуации, когда приходят в саппорт юзеры и начинают ныть — «А почему вы пускаете OpenA и не пускаете OpenB, это дискриминация» или «А почему вы не пускаете всех подряд, вот у меня дома на роутере стоит свой OpenId провайдер, я хочу чтобы ваш сервис верил тому, что он „рассказывает“.
Во-вторых — сводит удобство OpenID, как универсального и провайдеро-независимого решения, на нет. т.к. появляется зависимость от провайдера.
В чем преимущество OAuth — есть удобство общего назначения, в виде доступа к API конкретной платформы: получить данные о пользователе, на стене написать, календарик попросить и что-нить полезное показать, подсказать друзей которые уже на сервисе и все такое.
Есть частное удобство для пользователя — он чаще уже залогинен в сервис платформы (ибо он часто пользуется соцсетью, куда чаще чем своим „провайдером“, которые часто ничего кроме „провайдера OpenId“ и не предоставляют). И в этом случае — ему надо сделать максимум 2 клика ( кнопка войти и кнопка разрешить доступ приложению) чтобы оказаться на сайте. А в идеале (повторный заход) — вообще в один клик. И все, остальное делают сервисы, автоматически, ну 1-2 редиректа в фоне пролетят, юзер и не заметит.
И вот именно этот сценарий, который удобен как юзеру, так и сайту (заботящемуся о легком входе к себе, но требующему некоторой проверенной информации для работы) побеждает.
А OpenId c его идеологией и свистоплясками слишком неудобен для всех сторон:
1. Юзеру надо вводить урль ( что обычно длинее логина, а если вводить логин — надо выбрать правильного своего провайдера).
2. Сервису надо в любом случае проверить данные о пользователе от провайдера, или довериться конкретному провайдеру (что приведет к ограничениям описанным ранее и аннулирует преимущества OpenId)
Ну и кому, кроме убежденных гиков, нужна эта „морская свинка“ от мира аутентификации и регистрации под названием OpenID 2.0?
Юзерам лень что-то делать, а сервисы хотят переложить не нужную им работу на других (валидация данных).
Все, силы разума в очередной раз победили вселенское сферическое добро.
Есть несколько «неудобств» OpenId, с которыми «обычно» не соглашаются интерфейс-дизайнеры:
1. Для аутентификации — надо ввести руками строку\урль, OAuth позволяет сделать то же самое действие одним кликом, или даже прозрачно на яваскрипте (см. StackOverflow например).
2. Для регистрации — надо провалидировать email (если он нужен, а в сервисах он обычно нужен, домашние странички васи даже регистрации не должны требовать ;) ).
Платформа предлагающая OAuth в этом случае «обычно» берет на себя проверку все того же пресловутого email (да да, кроме твиттера, которому даже переход на OAuth 2.0 не поможет), т.к. сервис-сайт все равно регистрируется для доступа к «платформе», то он может выбрать те, что предоставляют проверенные данные.
Итак п.1 неудобен т.к. батхертит пользователей — надо вбить урл вместо клика на кнопке «войти»
п.2 отвратитетелен тем, что сайт-сервис все равно должен проверить необходимые ему данные, это значит что для email нужно генерить линк, отправлять на почту, ждать захода по этому линку, после чего ставить галочку что да, пользователь наконец-то проверен и у него гарантированно правильный email.
Про полезность писем — вопрос другой. В большинстве случаев если сервис спрашивает, значит считает что письма полезные ( и попробуй переубеди его ;) ), т.е. email чаще нужен, чем нет.
Можно избежать п.2 и пускать только пользователей определенного набора провайдеров OpenID, которые сами требуют валидацию нужных вам данных.
Это, во-первых, приводит к ситуации, когда приходят в саппорт юзеры и начинают ныть — «А почему вы пускаете OpenA и не пускаете OpenB, это дискриминация» или «А почему вы не пускаете всех подряд, вот у меня дома на роутере стоит свой OpenId провайдер, я хочу чтобы ваш сервис верил тому, что он „рассказывает“.
Во-вторых — сводит удобство OpenID, как универсального и провайдеро-независимого решения, на нет. т.к. появляется зависимость от провайдера.
В чем преимущество OAuth — есть удобство общего назначения, в виде доступа к API конкретной платформы: получить данные о пользователе, на стене написать, календарик попросить и что-нить полезное показать, подсказать друзей которые уже на сервисе и все такое.
Есть частное удобство для пользователя — он чаще уже залогинен в сервис платформы (ибо он часто пользуется соцсетью, куда чаще чем своим „провайдером“, которые часто ничего кроме „провайдера OpenId“ и не предоставляют). И в этом случае — ему надо сделать максимум 2 клика ( кнопка войти и кнопка разрешить доступ приложению) чтобы оказаться на сайте. А в идеале (повторный заход) — вообще в один клик. И все, остальное делают сервисы, автоматически, ну 1-2 редиректа в фоне пролетят, юзер и не заметит.
И вот именно этот сценарий, который удобен как юзеру, так и сайту (заботящемуся о легком входе к себе, но требующему некоторой проверенной информации для работы) побеждает.
А OpenId c его идеологией и свистоплясками слишком неудобен для всех сторон:
1. Юзеру надо вводить урль ( что обычно длинее логина, а если вводить логин — надо выбрать правильного своего провайдера).
2. Сервису надо в любом случае проверить данные о пользователе от провайдера, или довериться конкретному провайдеру (что приведет к ограничениям описанным ранее и аннулирует преимущества OpenId)
Ну и кому, кроме убежденных гиков, нужна эта „морская свинка“ от мира аутентификации и регистрации под названием OpenID 2.0?
Юзерам лень что-то делать, а сервисы хотят переложить не нужную им работу на других (валидация данных).
Все, силы разума в очередной раз победили вселенское сферическое добро.
В общем и целом — да, всё так. Но есть мелкие нюансы. :)
Во-первых, что касается входа одним кликом без ввода url. Я довольно часто пользуюсь OpenID, но не помню, когда последний раз ручками вводил url — обычно я успеваю нажать только первую букву, и браузер сам предлагает вписать нужную url. Так что на самом деле разница между одним кликом, и одной буквой и парой кликов не так велика.
Во-вторых, что касается проверки email — при использовании OAuth пользователи десятка крупных сервисов могут не валидировать свой email, а всех остальных пользователей вы фактически (предполагая, что своей регистрации у вас нет) вынуждаете сначала открыть аккаунт на одном из этих крупных сервисов а потом снова зайти на ваш сайт. При использовании OpenID (предполагая что эти же крупные сервисы поддерживают и OAuth и OpenID) пользователи этих сервисов точно так же избавлены от необходимости верифицировать свой email (т.к. конкрентно этим провайдерам вы доверяете), а остальные спокойно регистрируются используя любые OpenID провайдеры но вынуждены верифицировать свой email. Таким образом разница в юзабилити в данном случае как раз в пользу OpenID — ведь верифицировать email намного проще открытия аккаунта в крупных соц. сетях (в процессе чего всё-равно придётся верифицировать свой email).
Таким образом, разница в юзабилити между OpenID и OAuth не так уж и существенна. А если сайт предоставляет возможность входа и по OpenID и по OAuth то юзабилити вообще никак не страдает.
Но даже если допустить, что преимущества OAuth перед OpenID в плане юзабилити процесса логина бесспорны и очень важны — это плюс, но нельзя ведь учитывать одни плюсы, игнорируя при этом минусы, верно? А минусов у OAuth хватает. Безусловно, все эти минусы магическим образом становятся плюсами если вашему сайту действительно необходимо работать с функциональностью соц. сети — писать на стене и т.п., но мы ведь обсуждаем использование OAuth не для того, для чего оно изначально было предназначено, а исключительно как замену аутентификации и не более того.
С моей точки зрения, предоставление сайтам лишней информации о себе (включая информирование сайта соц. сети на какие другие сайты я логинюсь используя их OAuth) — это громадное зло, которое ещё выйдет боком этому миру. Но на некоторые грабли просто необходимо сначала наступить, ибо пока жаренный петух в жопу не клюнет голова работать не начнёт. Использование OpenID, по крайней мере, оставляет шанс избежать сообщения лишней информации о себе третьей стороне подняв свой провайдер OpenID. OAuth такого шанса не даёт — разве что регистрировать кучу отдельных fake аккаунтов в соц. сети исключительно для логина на разные сайты.
Резюмируя наше длительное общение. Хотите иметь описанный в статье геморрой ради того, чтобы сэкономить юзеру ввод одной буквы и один клик при регистрации/логине — дело Ваше, вреда от этого никакого нет. А вот если Вы сделаете вход только по OAuth, без OpenID и/или отдельной регистрации — это уже будет однозначное зло. Разумеется, это касается только сайтов, где OAuth используется не по прямому назначению, а исключительно для аутентификации.
Во-первых, что касается входа одним кликом без ввода url. Я довольно часто пользуюсь OpenID, но не помню, когда последний раз ручками вводил url — обычно я успеваю нажать только первую букву, и браузер сам предлагает вписать нужную url. Так что на самом деле разница между одним кликом, и одной буквой и парой кликов не так велика.
Во-вторых, что касается проверки email — при использовании OAuth пользователи десятка крупных сервисов могут не валидировать свой email, а всех остальных пользователей вы фактически (предполагая, что своей регистрации у вас нет) вынуждаете сначала открыть аккаунт на одном из этих крупных сервисов а потом снова зайти на ваш сайт. При использовании OpenID (предполагая что эти же крупные сервисы поддерживают и OAuth и OpenID) пользователи этих сервисов точно так же избавлены от необходимости верифицировать свой email (т.к. конкрентно этим провайдерам вы доверяете), а остальные спокойно регистрируются используя любые OpenID провайдеры но вынуждены верифицировать свой email. Таким образом разница в юзабилити в данном случае как раз в пользу OpenID — ведь верифицировать email намного проще открытия аккаунта в крупных соц. сетях (в процессе чего всё-равно придётся верифицировать свой email).
Таким образом, разница в юзабилити между OpenID и OAuth не так уж и существенна. А если сайт предоставляет возможность входа и по OpenID и по OAuth то юзабилити вообще никак не страдает.
Но даже если допустить, что преимущества OAuth перед OpenID в плане юзабилити процесса логина бесспорны и очень важны — это плюс, но нельзя ведь учитывать одни плюсы, игнорируя при этом минусы, верно? А минусов у OAuth хватает. Безусловно, все эти минусы магическим образом становятся плюсами если вашему сайту действительно необходимо работать с функциональностью соц. сети — писать на стене и т.п., но мы ведь обсуждаем использование OAuth не для того, для чего оно изначально было предназначено, а исключительно как замену аутентификации и не более того.
С моей точки зрения, предоставление сайтам лишней информации о себе (включая информирование сайта соц. сети на какие другие сайты я логинюсь используя их OAuth) — это громадное зло, которое ещё выйдет боком этому миру. Но на некоторые грабли просто необходимо сначала наступить, ибо пока жаренный петух в жопу не клюнет голова работать не начнёт. Использование OpenID, по крайней мере, оставляет шанс избежать сообщения лишней информации о себе третьей стороне подняв свой провайдер OpenID. OAuth такого шанса не даёт — разве что регистрировать кучу отдельных fake аккаунтов в соц. сети исключительно для логина на разные сайты.
Резюмируя наше длительное общение. Хотите иметь описанный в статье геморрой ради того, чтобы сэкономить юзеру ввод одной буквы и один клик при регистрации/логине — дело Ваше, вреда от этого никакого нет. А вот если Вы сделаете вход только по OAuth, без OpenID и/или отдельной регистрации — это уже будет однозначное зло. Разумеется, это касается только сайтов, где OAuth используется не по прямому назначению, а исключительно для аутентификации.
;) Если говорить о дополнительных средствах типа подсказки от браузера — то тогда недалеко и до LastPass — автоввод регистрационных данных, генерация и запоминание паролей и все такое. Но это по сути сторонние фичи. в случае Raw — OpenID проигрывает OAuth по юзабилити. Даже мне не нравится вводить первую букву, т.к. серфинг все же идет при помощи мыши, а не клавы ;)
Написание на стены и все такое — это необязательно надо пользовать, но комфортно и удобно получить дополнительные фичи за 1 проход…
Базовый запрос в OpenId может быть тоже строгий и сайт может попросить от провайдера максимум информации о юзере — кладем все поля в required и пользователь не получит доступа, пока все не расскажет.
Протокол никак не меняет возможность сайта запросить максимум лишней инфы не пускать пока не получит.
Oauth чаще всего сообщает базовую инфу о пользователе которая доступна публично (facebook) либо пользователь явно видит — сайт хочет получить доступ к email (google пишет).
Также уже сейчас некоторые реализации OAuth позволяют подменять прям на лету важную инфу ( анонимный email в facebook или мультиаккаунт в Google). А для OpenId это вряд ли будут делать.
Сайты без old-style регистрации — конечно же зло, а вот просто без OpenID — не вижу проблем. У нас только Old-style + Facebook + Google, и все довольно хорошо.
А насчет заставлять регистрироваться на сайте соцсети — ну с 99% вероятностью (высосано из пальца, но фактически примерно так и есть) у всех моих знакомых есть аккаунт в соцсети, но что такое OpenId и как им правильно пользоваться — от силы знают 5%. А уж аккаунты в OpenId провайдерах (кроме ЖЖ, потому что это сначала соцсеть, а потом уже провайдер) — если у 3х людей найду — буду удивлен.
А гемморой из статьи получать не нужно, надо читать спеки и реализовывать, там не сложно. А главное — всегда понимать, что именно ты делаешь в коде и для чего.
Спасибо за приятное и пламенное общение ;)
Написание на стены и все такое — это необязательно надо пользовать, но комфортно и удобно получить дополнительные фичи за 1 проход…
Базовый запрос в OpenId может быть тоже строгий и сайт может попросить от провайдера максимум информации о юзере — кладем все поля в required и пользователь не получит доступа, пока все не расскажет.
Протокол никак не меняет возможность сайта запросить максимум лишней инфы не пускать пока не получит.
Oauth чаще всего сообщает базовую инфу о пользователе которая доступна публично (facebook) либо пользователь явно видит — сайт хочет получить доступ к email (google пишет).
Также уже сейчас некоторые реализации OAuth позволяют подменять прям на лету важную инфу ( анонимный email в facebook или мультиаккаунт в Google). А для OpenId это вряд ли будут делать.
Сайты без old-style регистрации — конечно же зло, а вот просто без OpenID — не вижу проблем. У нас только Old-style + Facebook + Google, и все довольно хорошо.
А насчет заставлять регистрироваться на сайте соцсети — ну с 99% вероятностью (высосано из пальца, но фактически примерно так и есть) у всех моих знакомых есть аккаунт в соцсети, но что такое OpenId и как им правильно пользоваться — от силы знают 5%. А уж аккаунты в OpenId провайдерах (кроме ЖЖ, потому что это сначала соцсеть, а потом уже провайдер) — если у 3х людей найду — буду удивлен.
А гемморой из статьи получать не нужно, надо читать спеки и реализовывать, там не сложно. А главное — всегда понимать, что именно ты делаешь в коде и для чего.
Спасибо за приятное и пламенное общение ;)
Этот комментарий — странный запутаный гон, написанный в пробке на мкаде.
И добро пожаловать в мир миллиона халявно зарегистрированных аккаунтов на вашем сервере.Как я уже на это отвечал выше — используй капчу, Люк! Проверяй кол-во регистраций с одного IP. Если на сайте есть форма обычной регистрации (с логином и паролем) — всё это в любом случае надо делать.
ну хотя бы получше чем вы самиЭто иллюзия. На самом деле «вы сами» — это вариант «неуловимого джо, который нафиг никому не нужен». А вот для крупных соц. сетей разработка утилит для массовой регистрации аккаунтов поставлена на поток — почитайте журнал «Хакер», там в каждом номере по паре (новых) таких утилит упоминается.
Поэтому мечты об удобном предпочитаемом логине user1, а не user1.OpenId-Provider-1 идут далеко и надолго.Не вижу связи. Вы опять приплели к логинам email-ы. Предпочитаемый короткий логин/ник выдаётся в соответствии с ником юзера полученным по OpenID — если он свободен. Если он занят — юзеру предлагается выбрать другой короткий логин/ник. Email-ы здесь вообще не при чём.
…если мой провайдер кривой … сайт, который доверяет обоим провайдерамЭто проблема сайта. Не надо доверять кривым OpenID провайдерам, которые не проверяют email-ы. Вообще, речь вроде шла о доверии только 3-5 крупным сайтам, так что проблема надуманная.
идея openId именно в том, что сайт доверяет ЛЮБОМУ провайдеру, а не фиксированному набору, т.к. «любой провайдер» может быть вашим приватным и стоять на вашем сервере. Цель — единое место хранения ваших данных, чтобы сервера не хранили у себя их отдельно, а обновляли на основе ответа от некоего централизованного сервера ( вашего провайдера). чтобы вы могли свое имя поменять в провайдере и все сайты вас переименовали.
А как вы хотели? Вы получаете доступ к информации о пользователях. Держатели этой информации желают знать кто и зачем использует их сервис. Чтобы в случае чего блокировать ваше приложение и передавать ваши данные в соответствующие органы.
Ребяты, я вот чего не понимаю.
Пусть есть сайт, у него есть пользователи, зарегистрированные через email (классика), и есть пользователи, входящие через OAuth.
Есть пользователь с ником Василий Иванович, которого все знают. И тут ему решил кто-то нагадить. Кто-то регистрируется неважно где с таким же именем, потом входит на сайт через OAuth, и совершает действия, порочащие доброе имя Василий Иваныча.
Вопрос: как с этим бороться? Пользователя всеравно нужно показывать в своей системе с каким-то ником, даже если он зашел через OAuth. При классической регистрации два одинаковых ника не будет. При входе через OAuth — вполне себе обычная ситуация.
Что делать?
Пусть есть сайт, у него есть пользователи, зарегистрированные через email (классика), и есть пользователи, входящие через OAuth.
Есть пользователь с ником Василий Иванович, которого все знают. И тут ему решил кто-то нагадить. Кто-то регистрируется неважно где с таким же именем, потом входит на сайт через OAuth, и совершает действия, порочащие доброе имя Василий Иваныча.
Вопрос: как с этим бороться? Пользователя всеравно нужно показывать в своей системе с каким-то ником, даже если он зашел через OAuth. При классической регистрации два одинаковых ника не будет. При входе через OAuth — вполне себе обычная ситуация.
Что делать?
Проверять уникальность ника. А что, есть другие варианты?
Т.е. даже после входа через OAuth у Вас должна появиться его учетка в БД. ID, Nickname и т.д.
Тогда в чем прелесто OAuth, если пользователь всеравно должен придумывать ник на сайте?
И еще непонятно — как авторизовать пользователя после того, как у него оявится учетка на сайте? Снова через OAuth? Или требовать ввод пароля, чтоб потом авторизовать по логину-паролю?
А если он же захочет войти из-под другого провайдера, то его нужно рассматривать как другую личность или как уже зарегистрированного пользователя? А по каким критериям? По нику + email? А если у него нет email?
И еще непонятно — как авторизовать пользователя после того, как у него оявится учетка на сайте? Снова через OAuth? Или требовать ввод пароля, чтоб потом авторизовать по логину-паролю?
А если он же захочет войти из-под другого провайдера, то его нужно рассматривать как другую личность или как уже зарегистрированного пользователя? А по каким критериям? По нику + email? А если у него нет email?
1. Не «все равно», а в случае конфликта имен. Этого не избежать.
2. Никто не мешает ему автоматом сгенерировать пароль (либо просто предоставить возможность указать пароль для входа через стандартную схему). Но и OAuth должен остаться доступным. Храните его OauthID (по идее, это комбинация oAuthID и ProviderID), потом всегда сможете проверить, существует ли учетка.
3. Конечно, стоит проверять его email, и объединять учетки. Ник ни в коем случае не является показателем, в лучшем случае предложите указать свои прочие учетки (вход через них является подтверждением, т.е. email вроде и необязателен). Как-то так.
На самом деле на Хабре есть несколько статей с подобным обсуждением, одну из них вроде и я создавал.
2. Никто не мешает ему автоматом сгенерировать пароль (либо просто предоставить возможность указать пароль для входа через стандартную схему). Но и OAuth должен остаться доступным. Храните его OauthID (по идее, это комбинация oAuthID и ProviderID), потом всегда сможете проверить, существует ли учетка.
3. Конечно, стоит проверять его email, и объединять учетки. Ник ни в коем случае не является показателем, в лучшем случае предложите указать свои прочие учетки (вход через них является подтверждением, т.е. email вроде и необязателен). Как-то так.
На самом деле на Хабре есть несколько статей с подобным обсуждением, одну из них вроде и я создавал.
Изучать вопрос чуть глубже.
Вы когда доверяете OAuth провайдеру — вы доверяете ему целиком. Например Facebook отдает вам емейл этого ВасильВаныча.
Если Facebook позволил злоумышленнику зарегаться на почту ВасильВаныча и не проверил что почта действительно принадлежит тому, кто регистрируется- грош цена такому провайдеру, бежать оттуда и не доверять.
Если же провайдер (я.ру) не позволяет регаться на чужую почту — то все ок, при входе через OAuth обычно следует запрос к API — «Вот у меня есть токен, скажи мне, сервис, какой email у того, кто мне этот токен авторизовал (а это был юзер)». Сервис тебе честно отвечает — email: vasil@vanych.ru.
Все, если в бд уже есть такой зарегистрированный пользователь — того кто сидит на «другом конце интернета» можно логинить как этого пользователя.
Если в бд нету — заводим нового, логиним.
Если злоумышленник угонит аккаунт в ФБ — сможет зайти и к вам на сервис (это кстати серьезный вектор атаки), т.к. вы доверяете ФБ, а злодей смог его обмануть.
Если злоумышленник угонит почту — очевидно что он сможет угнать и фб и ваш сайт, восстановив пароль на угнанную почту.
Собственно надежность авторизации через сторонние сервисы — это доверие к этим сервисам, в том, что «их труднее сломать чем ваш собственный сервис».
Вы когда доверяете OAuth провайдеру — вы доверяете ему целиком. Например Facebook отдает вам емейл этого ВасильВаныча.
Если Facebook позволил злоумышленнику зарегаться на почту ВасильВаныча и не проверил что почта действительно принадлежит тому, кто регистрируется- грош цена такому провайдеру, бежать оттуда и не доверять.
Если же провайдер (я.ру) не позволяет регаться на чужую почту — то все ок, при входе через OAuth обычно следует запрос к API — «Вот у меня есть токен, скажи мне, сервис, какой email у того, кто мне этот токен авторизовал (а это был юзер)». Сервис тебе честно отвечает — email: vasil@vanych.ru.
Все, если в бд уже есть такой зарегистрированный пользователь — того кто сидит на «другом конце интернета» можно логинить как этого пользователя.
Если в бд нету — заводим нового, логиним.
Если злоумышленник угонит аккаунт в ФБ — сможет зайти и к вам на сервис (это кстати серьезный вектор атаки), т.к. вы доверяете ФБ, а злодей смог его обмануть.
Если злоумышленник угонит почту — очевидно что он сможет угнать и фб и ваш сайт, восстановив пароль на угнанную почту.
Собственно надежность авторизации через сторонние сервисы — это доверие к этим сервисам, в том, что «их труднее сломать чем ваш собственный сервис».
PS: уникальные ники — зло, авторизуйте по email ;). В моем описании выше email от ника ничем не отличается, только вот я не видел провайдеров, которые гарантировали бы уникальность ника\имени. Зато уникальность email — гарантируется ;)
А если человек зареган у провайдера без email, то как быть?
И я так и не понял, как отображать на сайте человека, зашедшего через OAuth. Проверять уникальность ника, и если ник неуникален требовать ввода другого ника?
И я так и не понял, как отображать на сайте человека, зашедшего через OAuth. Проверять уникальность ника, и если ник неуникален требовать ввода другого ника?
Генерировать пользователю ник (user15646465) и выводить информер с предложением сменить ник.
Так, а что нужно сохранять в базе пользователей при первом входе через OAuth?
Вот что вырисовывается:
1. Случай если ник уникален:
1. Ник
2. email
3. пароль — оставляем пустым
4. флаг — регистрация по OAuth
2. Случай если ник неуникален:
1. Случайный ник типа user15646465
2. email
3. пароль — оставляем пустым
4. флаг — регистрация по OAuth с неуникальным ником
3. Случай если email не указан:
Требовать указать email, не пуская дальше. После указания email проверяется уникальность. Если email неуникален — не пускаем дальше. Если email уникален, действуем далее по пункту 1 и 2.
Так?
Вот что вырисовывается:
1. Случай если ник уникален:
1. Ник
2. email
3. пароль — оставляем пустым
4. флаг — регистрация по OAuth
2. Случай если ник неуникален:
1. Случайный ник типа user15646465
2. email
3. пароль — оставляем пустым
4. флаг — регистрация по OAuth с неуникальным ником
3. Случай если email не указан:
Требовать указать email, не пуская дальше. После указания email проверяется уникальность. Если email неуникален — не пускаем дальше. Если email уникален, действуем далее по пункту 1 и 2.
Так?
Вообще, рекомендую обратить внимание на такую вещь, как real_name. В том или ином виде он есть у всех вышеупомянутых провайдеров (в отличие от email). Я планирую вообще отказаться от того, чтобы логин где-то фигурировал на сайте, кроме как в странице входа. У меня входящие через OAuth получают ник вида vk_{VK_uid} — пусть некрасиво, но они (пользователи ВК) его и не видят. Все их сообщения подписываются их реальным именем. А регистрирующимся обычным путем при необходимости я сообщаю, что префикс vk_ — зарезервирован.
> Все их сообщения подписываются их реальным именем.
Как люди друг друга будут различать, если имена у нескольких совпадут?
Ну то есть как другие пользователи будут понимать, что этот вася пупкин — это старенький, а этот вася пупкин — средненький, а этот вася пупкин — новенький?
Как люди друг друга будут различать, если имена у нескольких совпадут?
Ну то есть как другие пользователи будут понимать, что этот вася пупкин — это старенький, а этот вася пупкин — средненький, а этот вася пупкин — новенький?
несколько неполных совпадений (имя-фамилия) у меня есть. плюс, разумеется, всякие вовы путины и д.медведевы, которые всегда будут появляться, какие механизмы отсева не предусматривай. но с последними все понятно и без механизмов, а с первыми — никаких проблем не возникает. конфликтных ситуаций пока не возникало, и я их не предвижу. есть еще аватары, подписи, стиль сообщений и пр. да и не настолько часто они пересекаются, эти тезки — вы вот, IRL, когда крайний раз со своим полным тезкой встречались?
Я делал так: пользователь входит первый раз. Запрашиваю у oauth/openid email (это самый важный индентификатор). Генерирую пользователю ник (в любом случае). Далее все верно. Если провайдер oauth не отдает мыло — спрашиваю его у пользователя и не пускаю дальше. Пароль в данном случае вообще не нужен.
Можете пойти путем Ldap и создать DN. Что-то типа:
CN=Karen Berge,CN=admin,DC=corp,DC=Fabrikam,DC=COM
CN=Karen Berge,CN=admin,DC=corp,DC=Fabrikam,DC=COM
писал длинный ответ, но он прохерился, то ли хабром то ли хромом. Больше ниасилю, извините.
Вкратце — рассматривайте о-провайдера как способ получить «логин и пароль», если раньше вы спрашивали это у пользователя, то теперь есть третья сторона, которой доверяет и пользователь и вы, т.н. «удостоверяющая сторона» — УС. И эта УС сообщает вам «логин-пароль» для пользователя (логин- емейл, пароль например userid в сервисе, они не меняются ни у кого из провайдеров, хотя пароль в общем — не нужен, вы же доверяете УС когда она сообщает вам email).
Но вам все равно прийдется заводить пользователя у себя в сервисе как и при обычной регистрации — все те же проверки, валидации и т.д.
И логинить вы его будете также как при обычной авторизации, только логин-пароль вы получаете не напрямую, а через УС.
Если пользователь входит через другой провайдер, то вы можете проверить совпадение email — этого достаточно чтобы предположить, что это тот же пользователь. Т.е. если гугль и фб возвращают при авториизации один и тот же емейл — надо логинить в один и тот же аккаунт
Вкратце — рассматривайте о-провайдера как способ получить «логин и пароль», если раньше вы спрашивали это у пользователя, то теперь есть третья сторона, которой доверяет и пользователь и вы, т.н. «удостоверяющая сторона» — УС. И эта УС сообщает вам «логин-пароль» для пользователя (логин- емейл, пароль например userid в сервисе, они не меняются ни у кого из провайдеров, хотя пароль в общем — не нужен, вы же доверяете УС когда она сообщает вам email).
Но вам все равно прийдется заводить пользователя у себя в сервисе как и при обычной регистрации — все те же проверки, валидации и т.д.
И логинить вы его будете также как при обычной авторизации, только логин-пароль вы получаете не напрямую, а через УС.
Если пользователь входит через другой провайдер, то вы можете проверить совпадение email — этого достаточно чтобы предположить, что это тот же пользователь. Т.е. если гугль и фб возвращают при авториизации один и тот же емейл — надо логинить в один и тот же аккаунт
Не все сервисы из перечисленных выше отдают по API e-mail пользователя.
Хе. Во первых в рамках одной соц. сети у вас клиенты будут уникальные. Если вам требуется уникальность на вашем сайте, можно или указывать откуда пришел пользователь т.е. уникальной должна быть связка пользователь-соц.сеть или же вы при первой регистрации выдаете пользователю форму со сменой ника на вашем ресурсе.
Так это же разные Василии Ивановичи. Надо их как-то наглядно отличать на сайте, а не показывать одинаково до степени смешения.
Вот только с OAuth 1.0 надо бы поосторожней. Я сам с твиттером еще не интегрировался ( ибо он, гад email не отдает, а мыло нужно), но насколько я помню — по стандарту OAuth 1.0 все параметры, подписываемые ключем, должны быть СПЕЦИАЛЬНО упорядочены:
tools.ietf.org/html/rfc5849
3.4.1.3.2. Parameters Normalization
The parameters collected in Section 3.4.1.3 are normalized into a single string as follows:
…
2. The parameters are sorted by name, using ascending byte value ordering. If two or more parameters share the same name, they are sorted by their value.
…
(этот порядок еще называется lexicographical byte value ordering)
Так что с «подставьте вот в эту строчку свое» — можно немного пролететь, если не помнить про этот порядок.
tools.ietf.org/html/rfc5849
3.4.1.3.2. Parameters Normalization
The parameters collected in Section 3.4.1.3 are normalized into a single string as follows:
…
2. The parameters are sorted by name, using ascending byte value ordering. If two or more parameters share the same name, they are sorted by their value.
…
(этот порядок еще называется lexicographical byte value ordering)
Так что с «подставьте вот в эту строчку свое» — можно немного пролететь, если не помнить про этот порядок.
Можно просто после возвращение с твиттера показать страницу где пользователь должен ввести свой почтовый адрес. И подтвердить его на почте. Понятно что такое не удобно но многие такое практикуют. Все равно потом в другом браузере он сможет просто через твитер войти и сайт уже будет знать что у этого аккаунта твиттера такое-то мыло и уже дальше работать с пользователем. Например на сайте www.fashiolista.com/ (написан на python/django) именно так и сделано.
параметры в этой строке *уже* упорядочены
ага, только что сделает пользователь вашего кода, когда ему понадобится что-то добавить?
Правильно, добавит в конец, т.к. http похрен на порядок параметров, и будет прав. А вот oauth — не похрен. Поэтому про специальное упорядочивание перед подписыванием — стоит упомянуть более явно.
Правильно, добавит в конец, т.к. http похрен на порядок параметров, и будет прав. А вот oauth — не похрен. Поэтому про специальное упорядочивание перед подписыванием — стоит упомянуть более явно.
Почему-то автор не упоминает о таком важном моменте как уникальный коллбек, для того чтобы можно было идентифицировать пользователя, возвращаемого oauth сервером. Чтобы коллбек был уникален, достаточно добавлять к redirect_uri какой-либо параметр и присваивать в качестве значение генерируемый хеш. А также записывать этот хеш в сессию и сравнивать после возврата пользователя на сайт.
Иначе возможно атака в которой злоумышленник нажимает на ссылку авторизации, получает код, но не переходит на сайт для обмена кода на токен. Ссылка с кодом отдается жертве, и перейдя по ней, жертва привязывается к учетке злоумышленника. В результате злоумышленник может войти на сайт под видом жертвы.
А OpenID в данной статье незаслуженно унижен. Не вижу никаких сложностей с тем чтобы явно указывать сервер авторизации openid в ссылке на сайте (войти через гугл, войти через жж). Что в данном случае меняется? Для пользователя абсолютно ничего. Он так же нажимает на ссылку, переходит на сайт гугла и разрешает авторизацию. Зато в качестве большого бонуса, не надо писать кучу кода. Там где только oauth — пишутся небольшие классы для общего интерфейса авторизации. Там где openid — меняется только адрес ссылки логина (site.com/login/?realm={google|yandex|etc...}) и используется единый класс с разными значениями auth_realm.
Иначе возможно атака в которой злоумышленник нажимает на ссылку авторизации, получает код, но не переходит на сайт для обмена кода на токен. Ссылка с кодом отдается жертве, и перейдя по ней, жертва привязывается к учетке злоумышленника. В результате злоумышленник может войти на сайт под видом жертвы.
А OpenID в данной статье незаслуженно унижен. Не вижу никаких сложностей с тем чтобы явно указывать сервер авторизации openid в ссылке на сайте (войти через гугл, войти через жж). Что в данном случае меняется? Для пользователя абсолютно ничего. Он так же нажимает на ссылку, переходит на сайт гугла и разрешает авторизацию. Зато в качестве большого бонуса, не надо писать кучу кода. Там где только oauth — пишутся небольшие классы для общего интерфейса авторизации. Там где openid — меняется только адрес ссылки логина (site.com/login/?realm={google|yandex|etc...}) и используется единый класс с разными значениями auth_realm.
про уникальный коллбек я упомянул, читайте, пожалуйста, внимательнее, перед тем как предъявлять претензии. кстати, из упомянутых 7 сервис-провайдеров по-моему (не скажу, что на 100% уверен — специально не считал) только 3 разрешают менять коллбек непосредственно в запросе. Остальные — жестко посылают на юг, если коллбэк отличается от прописанного в натройках приложения.
Вк, фейсбук, твиттер, маил.ру, фликр — разрешают хеш в коллбеке. Для всего остального есть мастеркард OpenId. С одноклассниками не вязался еще, попробую :)
Упс, приношу извинения — параметры действительно работают. Недоглядел :\ все дело в mod_rewrite — у меня коллбэк — это параметр некоего общего для всех скрипта, и добавление еще одного параметра для сервера выглядело как изменение заданного в настройках коллбэка, на что он вполне заслуженно ругался. На нормальные параметры (через ?) они не ругаются. Завтра поправлю, когда высплюсь :)
остальные кстати правильно делают, вообще если приложение регалось и указало базовый урль то по стандарту надо слать в лес, если return_uri не на базовом.
Если нельзя дописывать return_uri — есть параметр state, его все провайдеры по стандарту должны передавать без изменений (а реализация гугла тут «жжот» и нарушает) — по нему и ориентируемся.
Если нельзя дописывать return_uri — есть параметр state, его все провайдеры по стандарту должны передавать без изменений (а реализация гугла тут «жжот» и нарушает) — по нему и ориентируемся.
>(а реализация гугла тут «жжот» и нарушает) — по нему и ориентируемся
чем жжот она, простите? тоже стэйт передает вроде без проблем.
хеш в редирект_ури это work around. в будущем redirect_uri будут статичны везде, это очевидно. use state
чем жжот она, простите? тоже стэйт передает вроде без проблем.
хеш в редирект_ури это work around. в будущем redirect_uri будут статичны везде, это очевидно. use state
Стандарт (текущий) подразумевает проверку что return_uri находится на том же «пути» (домен) что и зарегистрирован в сервере, а не 100% совпадает. Гугль требует 100% совпадения.
Тогда непонятно нахрена его передавать, если 100% совпадение с тем, что уже есть у гугла. тот же OAuth подразумевает что надо использовать зареганый, если не передано вообще. У гугла return_uri был required ( возможно сейчас поменяли)
Тогда непонятно нахрена его передавать, если 100% совпадение с тем, что уже есть у гугла. тот же OAuth подразумевает что надо использовать зареганый, если не передано вообще. У гугла return_uri был required ( возможно сейчас поменяли)
все правильно. в будущем будет возможно регать несколько колбэков поэтому передавать надо. 100% совпадение — давно пора всем так делать.
По OpenID. "(войти через гугл, войти через жж). Что в данном случае меняется?"
"-"
1. OAuth еще и дает мне доступ к API провайдера (что, в том числе, позволяет мне дать пользователю набор «вкусных» функций), а OpenID не дает ничего.
2. Независимо от того, выполнен пользователем вход на OpenID-провайдере, или нет, он *должен* ввести у меня свой идентификатор
"+"
1. Мне не надо регистрироваться на провайдере.
2. Мне не надо писать отдельную реализацию клиентской части для каждого очередного провайдера.
Итог: если мы заботимся о пользователе — OAuth лучше, если о себе — OpenID
"-"
1. OAuth еще и дает мне доступ к API провайдера (что, в том числе, позволяет мне дать пользователю набор «вкусных» функций), а OpenID не дает ничего.
2. Независимо от того, выполнен пользователем вход на OpenID-провайдере, или нет, он *должен* ввести у меня свой идентификатор
"+"
1. Мне не надо регистрироваться на провайдере.
2. Мне не надо писать отдельную реализацию клиентской части для каждого очередного провайдера.
Итог: если мы заботимся о пользователе — OAuth лучше, если о себе — OpenID
Давайте порассуждаем немного логически. Если сайт предоставляет уникальный функционал по работе с соц. сетями (работа с изображениями/фото/френдлента), то да, доступ к api, бесспорно, играет важную роль. Но в 90% случаев рядовых сайтов нужна просто авторизация.
Теперь давайте про идентификатор. Разрешать какие-угодно внешние oauth/openid провайдеры, конечно, глупо. И в реальной жизни нашей целью скорее станет конкретный набор социальных сервисов. В случае с гуглом/яндеком для OpenId идентификаторы не нужны и, как я писал выше, для пользователя внешне все выглядит точно также.
Теперь давайте про идентификатор. Разрешать какие-угодно внешние oauth/openid провайдеры, конечно, глупо. И в реальной жизни нашей целью скорее станет конкретный набор социальных сервисов. В случае с гуглом/яндеком для OpenId идентификаторы не нужны и, как я писал выше, для пользователя внешне все выглядит точно также.
Насчет первого — склонен согласиться. Я б даже сказал, что 95% рядовых сайтов той же loginзы хватило б выше крыши. Я про другой случай.
А разве гугл/яндекс не пошлют меня лесом, если я отправлю к ним пользователя, не зная его идентификатор? ЖЖ, помнится мне, в таком случае прямо сообщал (причем не мне, а пользователю) что-то вроде: «сайт ХХХ попросил у вас идентификации, которую вы не можете предоставить» — после того, как юзер вводил свой логин и пароль на ЖЖ. Да и спецификации явно требуют передавать провайдеру идентификатор.
А разве гугл/яндекс не пошлют меня лесом, если я отправлю к ним пользователя, не зная его идентификатор? ЖЖ, помнится мне, в таком случае прямо сообщал (причем не мне, а пользователю) что-то вроде: «сайт ХХХ попросил у вас идентификации, которую вы не можете предоставить» — после того, как юзер вводил свой логин и пароль на ЖЖ. Да и спецификации явно требуют передавать провайдеру идентификатор.
> А разве гугл/яндекс не пошлют меня лесом, если я отправлю к ним пользователя, не зная его идентификатор?
Конкретно гугл и яндекс не пошлют. ЖЖ, блоггер и ряд других — пошлют. Попробуйте сами взять любую библиотеку openid для любого языка и скормить ей эти discovery url: www.google.com/accounts/o8/id
openid.yandex.ru/
Конкретно гугл и яндекс не пошлют. ЖЖ, блоггер и ряд других — пошлют. Попробуйте сами взять любую библиотеку openid для любого языка и скормить ей эти discovery url: www.google.com/accounts/o8/id
openid.yandex.ru/
>Иначе возможно атака в которой злоумышленник нажимает на ссылку авторизации, получает код, но не переходит на сайт для обмена кода на токен. Ссылка с кодом отдается жертве, и перейдя по ней, жертва привязывается к учетке злоумышленника. В результате злоумышленник может войти на сайт под видом жертвы.
true story www.youtube.com/watch?v=KRNsaPx7X-M&feature=g-hist
true story www.youtube.com/watch?v=KRNsaPx7X-M&feature=g-hist
если злоумышленник может так сделать — это MitM, там такая сложная техника не нужна — фэйкаем сайт и перехватываем нативные логин-пароль. Остальное — overcomplicated.
вы не поняли техники, это не mitm. все делается очень элегантно и просто, одной лишь CSRF через 
ну ютуб еще не смотрел. Но вообще если на вашем сайте можно каким-то образом разместить левую ссылку на сайт злодея — беда не в oAuth.
А заключительный шаг обмена кода на access токен вообще не даст вашему приложению ничего, потому что токен максимум что — выдан для чужого приложения, маскирующегося под ваше, а стандарт требует на последнем этапе проверки client'а тоже.
Это с ходу. Возможно в ютубе что-то интересное, но пока нет времени изучить — не могу обосновать.
А заключительный шаг обмена кода на access токен вообще не даст вашему приложению ничего, потому что токен максимум что — выдан для чужого приложения, маскирующегося под ваше, а стандарт требует на последнем этапе проверки client'а тоже.
Это с ходу. Возможно в ютубе что-то интересное, но пока нет времени изучить — не могу обосновать.
зачем размещать на моем сайте? много кто разрешает размещать картинки или ссылки, но тем не менее что мешает разместиь на funnypictures.com/addr.html и подкинуть «жертве». очень легко.
после проведения атаки производится disconnect from facebook — вообще никаких отпечатков.
>А заключительный шаг обмена кода на access токен вообще не даст вашему приложению ничего, потому что токен максимум что — выдан для чужого приложения, маскирующегося под ваше, а стандарт требует на последнем этапе проверки client'а тоже.
я все знаю. я не получаю access_token -он хранится на сервере. я вообще не трогаю oauth ресурсы жертвы. OAuth Callback Forgery
после проведения атаки производится disconnect from facebook — вообще никаких отпечатков.
>А заключительный шаг обмена кода на access токен вообще не даст вашему приложению ничего, потому что токен максимум что — выдан для чужого приложения, маскирующегося под ваше, а стандарт требует на последнем этапе проверки client'а тоже.
я все знаю. я не получаю access_token -он хранится на сервере. я вообще не трогаю oauth ресурсы жертвы. OAuth Callback Forgery
Посмотрел видео.
Хомяков конечно крут, наверное…
Но вот мне кажется он, или вы, допустили одну ошибку:
Следующее высказывание, если все соблюдают протокол, НЕ верно (это цитата из вашего коммента, но в видео вроде суть похожая):
«жертва привязывается к учетке злоумышленника».Попробую объяснить по шагам почему это не может быть ошибкой OAuth протокола (хотя с этим, как выясняется, у меня плохо, мутно объясняю).
Действующие лица:
Вы — сайт
Юзер — человек сидящий напротив компа
Злодей — тот кто перехватил свой редирект и хочет подсунуть его юзеру (в видео — Егор ;) ).
ФБ — сервер OAuth 2.0, и по совместительству ресурс-провайдер, который по access-токену расскажет какой email и FB-ID у пользователя, который выдал токен.
Итак, как на самом деле выглядит OAuth 2.0 процесс. Пропустим начало и перейдем к тому моменту, про которое говорится в видео. Как это в реальности:
1. В результате перехода по редиректу с ФБ на return_uri, который демонстрировался в видео, вы, как сайт, получаете некий токен1 (авторизованный пользователем код), от ФБ. Никакой привязки к учетке конкретного юзера на сайте еще не произошло, как и не произошло логина его на сайт.
2. В момент получения этого токен1, сайт должен сделать завершающий шаг — получить от ФБ Access токен и Refresh токен. Очевидно что канал между Сайтом и ФБ не скомпроментирован и там сайт может получить честный Access токен (а-токен) того пользователя, который сказал «да разрешить» и был отправлен редиректом ( это или юзер или злодей из видео.
3. После получения a-токена, сайт может сделать только одно — обратиться за ресурсом к ФБ (который по совместительству...). Сайт передает токен и запрашивает страницу ФБ/me, чтобы получить информацию о том пользователе который подписал токен ( а сайт еще даже не знает кто это вообще).
4. После получения данных о юзере, сайт принимает решение (это очевидно объязательный шаг.)
4.1 если пользователь есть в БД (найден email для сайтового аккаунтХ или для маньяков — совпадение FB-Id для аккаунтаХ), сайт может смело залогинить юзера в аккаунтХ
4.2 Если пользователя нет в БД — можно его зарегистрировать автоматически ( т.к. есть емейл и «оно проверено», ну еще сайты спрашивают другие обязательные поля, если их не отдал ФБ/me) и потом сразу залогинить
Все. На этом шаге у нас есть некто, залогинившийся в аккаунтХ на сайте ( или некто, создавший АккаунтZ и залогиненный в него).
Теперь вернемся к видео: для начала о чем рассказывает Егор — он рассказывает о библиотеке omniauth, это частная реализация протокола. Возможно в ней есть ошибка, хотя странно, т.к. спека довольно внятная и коряво ее сделать — надо постараться. И все же вернемся к самой «атаке».
Предположение что теперь можно зайти с ФБ аккаунтом Злодея на сервис — верное, вы зайдете в тот аккаунт, который сделал или нашел для вас сайт (АккаунтХ — аккаунт зареганый на email злодея или АккаунтZ, созданный на основе email злодея).
Но этот аккаунт привязан к собственному email злодея, т.к. шаг 3, на котором сайт запрашивает ФБ/me должен вернуть данные о том, кто авторизовал токен. А токен авторизовал злодей, и только потом он перехватил свой редирект и подсунул юзеру (редирект уже вел на сайт, на ФБ никто не ходил). Предполагать что с какого-то бодуна ФБ вернет данные произвольного юзера (неизвестного ФБ, т.к. запрос к me делает сайт, а там нет куки залогиненного фб юзера) — очень самонадеяно.
Т.е. все, что получил злодей, подсунув пользователю свою ссылку с токеном — это всего лишь то, что юзер зарегистрировался для злодея на сайте и что-то мог поделать там (хотя пользователь должен был бы обратить внимание что неком логин-контроле стоит не его имя или совсем не его email).
Ну или юзер зашел в аккаунт злодея на сайте.
Это все, что может произойти, если все стороны работают в соответствии с протоколом и без багов.
Да, невнимательный юзер в этом случае может облажаться и оставить какие-нить данные в аккаунте злодея, но это НЕ атака НА ПРОТОКОЛ и это не сложнее того, что прийти за чужой комп и залогиниться в СВОЙ почтовый ящик, надеясь, что юзер отправит что-то по почте, а вы потом зайдете в свой ящик и почитаете это. Реализуемо, но это опять же, на 99% социальная атака, а не уязвимость протокола.
Где может быть суровый косяк еще — в библиотеке OmniAuth ( о которой рассказывает Егор). Я не видел ее и не знаю, но по опыту имплементации OAuth2.0 в своем проекте — есть еще одна грабля (она кстати описана в хауту или даже в самом драфте вроде, надо смотреть, но это в общем не секретное знание):
Если после редиректа юзер приходит на сайт и несет некий токен, а сам в это время уже залогинен на сайте ( есть Auth кука сайта) — сайт должен игнорировать токены и ничего из П.3-П.4 НЕ ДЕЛАТЬ.
Допускаю (чисто эмпирически), что сайты описанные в видео, или даже сама OmniAuth НЕ проверяют залогиненность пользователя, когда тот приходит на Redirect_uri. И просто проводят все действия п.п.3-4 или сразу логинят, но где-то неправильно извлекают email и в итоге Access токен злодея действительно привязывается к учетке залогиненного пользователя.
А еще к этому абзацу смотри NB в конце
Это косяк сайтов, либы но никак не протокола OAuth 2.0. Так что или Егор ошибся (возможно, принял одну ошибку за другую), или вы неправильно интерпретировали видео (слишком короткий фрагмент, чтобы глубоко понять о чем вообще идет речь в докладе).
Да, как можно этого избежать в 100% случаев. Шаг 4 должен делать следующее
4.1 НЕ ЛОГИНИМ, а идем на новый п.5.
4.2 Регистрируем Аккаунт, но не логиним, а идем на п.5
п.5 Отправляем пользователя на авторизацию ПОВТОРНО, т.е. отправляем на подписание токена, со скопами и все такое, но очевидно с другим state, т.е. по сути имитируем повторное нажатие на кнопку «login with FB» на сайте.
Т.к. ваше приложение честный юзер уже авторизовал ( это пока без злоумышленника), то все шаги пройдут незаметно для пользователя: логин на ФБ он уже недавно делал, приложению разрешения давал и все ок, если все правильно, то пользователь после 2х редиректов и еще одного запроса ФБ/me, только уже все без злодея ( который как-то подсунул ссылку ранее), пользователь окажется в СВОЕМ аккаунте, т.к. у него уже будет своя ссылка и он авторизовал токен ранее (т.е. у пользователя уже есть аккаунт на сайте).
Если ранее была такая атака, то после этой процедуры юзер увидит окошко «приложение запрашивает разрешение», т.к. ваш сайт честным юзером еще не был авторизован, его, по истории, авторизовал злодей для своего аккаунта ФБ.
Собственно все. Надеюсь описал понятно, готов защищать свою позицию даже против Егора, как автора предполагаемой ( кстати предполагаете вы, Егор не говорил что уязвимость в OAuth, описывается уязвимость в OmniAuth)
NB: пересматривал видео после написания всего ответа, заметил упоминание именно такого момента (0:33 «Ставлю img src=этот коллбэк, подкидываю другому пользователю который в данный момент на этом сайте АУТЕНТИФИЦИРОВАН»). Собственно что я и сказал абзацем ранее — либа или сайт делают странные, неправильные вещи, они повторно аутентифицируют повторно пользователя, который УЖЕ АУТЕНТИФИЦИРОВАН.
Извините ноOAuth Callback Forgery — BUSTED!
Хомяков конечно крут, наверное…
Но вот мне кажется он, или вы, допустили одну ошибку:
Следующее высказывание, если все соблюдают протокол, НЕ верно (это цитата из вашего коммента, но в видео вроде суть похожая):
«жертва привязывается к учетке злоумышленника».Попробую объяснить по шагам почему это не может быть ошибкой OAuth протокола (хотя с этим, как выясняется, у меня плохо, мутно объясняю).
Действующие лица:
Вы — сайт
Юзер — человек сидящий напротив компа
Злодей — тот кто перехватил свой редирект и хочет подсунуть его юзеру (в видео — Егор ;) ).
ФБ — сервер OAuth 2.0, и по совместительству ресурс-провайдер, который по access-токену расскажет какой email и FB-ID у пользователя, который выдал токен.
Итак, как на самом деле выглядит OAuth 2.0 процесс. Пропустим начало и перейдем к тому моменту, про которое говорится в видео. Как это в реальности:
1. В результате перехода по редиректу с ФБ на return_uri, который демонстрировался в видео, вы, как сайт, получаете некий токен1 (авторизованный пользователем код), от ФБ. Никакой привязки к учетке конкретного юзера на сайте еще не произошло, как и не произошло логина его на сайт.
2. В момент получения этого токен1, сайт должен сделать завершающий шаг — получить от ФБ Access токен и Refresh токен. Очевидно что канал между Сайтом и ФБ не скомпроментирован и там сайт может получить честный Access токен (а-токен) того пользователя, который сказал «да разрешить» и был отправлен редиректом ( это или юзер или злодей из видео.
3. После получения a-токена, сайт может сделать только одно — обратиться за ресурсом к ФБ (который по совместительству...). Сайт передает токен и запрашивает страницу ФБ/me, чтобы получить информацию о том пользователе который подписал токен ( а сайт еще даже не знает кто это вообще).
4. После получения данных о юзере, сайт принимает решение (это очевидно объязательный шаг.)
4.1 если пользователь есть в БД (найден email для сайтового аккаунтХ или для маньяков — совпадение FB-Id для аккаунтаХ), сайт может смело залогинить юзера в аккаунтХ
4.2 Если пользователя нет в БД — можно его зарегистрировать автоматически ( т.к. есть емейл и «оно проверено», ну еще сайты спрашивают другие обязательные поля, если их не отдал ФБ/me) и потом сразу залогинить
Все. На этом шаге у нас есть некто, залогинившийся в аккаунтХ на сайте ( или некто, создавший АккаунтZ и залогиненный в него).
Теперь вернемся к видео: для начала о чем рассказывает Егор — он рассказывает о библиотеке omniauth, это частная реализация протокола. Возможно в ней есть ошибка, хотя странно, т.к. спека довольно внятная и коряво ее сделать — надо постараться. И все же вернемся к самой «атаке».
Предположение что теперь можно зайти с ФБ аккаунтом Злодея на сервис — верное, вы зайдете в тот аккаунт, который сделал или нашел для вас сайт (АккаунтХ — аккаунт зареганый на email злодея или АккаунтZ, созданный на основе email злодея).
Но этот аккаунт привязан к собственному email злодея, т.к. шаг 3, на котором сайт запрашивает ФБ/me должен вернуть данные о том, кто авторизовал токен. А токен авторизовал злодей, и только потом он перехватил свой редирект и подсунул юзеру (редирект уже вел на сайт, на ФБ никто не ходил). Предполагать что с какого-то бодуна ФБ вернет данные произвольного юзера (неизвестного ФБ, т.к. запрос к me делает сайт, а там нет куки залогиненного фб юзера) — очень самонадеяно.
Т.е. все, что получил злодей, подсунув пользователю свою ссылку с токеном — это всего лишь то, что юзер зарегистрировался для злодея на сайте и что-то мог поделать там (хотя пользователь должен был бы обратить внимание что неком логин-контроле стоит не его имя или совсем не его email).
Ну или юзер зашел в аккаунт злодея на сайте.
Это все, что может произойти, если все стороны работают в соответствии с протоколом и без багов.
Да, невнимательный юзер в этом случае может облажаться и оставить какие-нить данные в аккаунте злодея, но это НЕ атака НА ПРОТОКОЛ и это не сложнее того, что прийти за чужой комп и залогиниться в СВОЙ почтовый ящик, надеясь, что юзер отправит что-то по почте, а вы потом зайдете в свой ящик и почитаете это. Реализуемо, но это опять же, на 99% социальная атака, а не уязвимость протокола.
Где может быть суровый косяк еще — в библиотеке OmniAuth ( о которой рассказывает Егор). Я не видел ее и не знаю, но по опыту имплементации OAuth2.0 в своем проекте — есть еще одна грабля (она кстати описана в хауту или даже в самом драфте вроде, надо смотреть, но это в общем не секретное знание):
Если после редиректа юзер приходит на сайт и несет некий токен, а сам в это время уже залогинен на сайте ( есть Auth кука сайта) — сайт должен игнорировать токены и ничего из П.3-П.4 НЕ ДЕЛАТЬ.
Допускаю (чисто эмпирически), что сайты описанные в видео, или даже сама OmniAuth НЕ проверяют залогиненность пользователя, когда тот приходит на Redirect_uri. И просто проводят все действия п.п.3-4 или сразу логинят, но где-то неправильно извлекают email и в итоге Access токен злодея действительно привязывается к учетке залогиненного пользователя.
А еще к этому абзацу смотри NB в конце
Это косяк сайтов, либы но никак не протокола OAuth 2.0. Так что или Егор ошибся (возможно, принял одну ошибку за другую), или вы неправильно интерпретировали видео (слишком короткий фрагмент, чтобы глубоко понять о чем вообще идет речь в докладе).
Да, как можно этого избежать в 100% случаев. Шаг 4 должен делать следующее
4.1 НЕ ЛОГИНИМ, а идем на новый п.5.
4.2 Регистрируем Аккаунт, но не логиним, а идем на п.5
п.5 Отправляем пользователя на авторизацию ПОВТОРНО, т.е. отправляем на подписание токена, со скопами и все такое, но очевидно с другим state, т.е. по сути имитируем повторное нажатие на кнопку «login with FB» на сайте.
Т.к. ваше приложение честный юзер уже авторизовал ( это пока без злоумышленника), то все шаги пройдут незаметно для пользователя: логин на ФБ он уже недавно делал, приложению разрешения давал и все ок, если все правильно, то пользователь после 2х редиректов и еще одного запроса ФБ/me, только уже все без злодея ( который как-то подсунул ссылку ранее), пользователь окажется в СВОЕМ аккаунте, т.к. у него уже будет своя ссылка и он авторизовал токен ранее (т.е. у пользователя уже есть аккаунт на сайте).
Если ранее была такая атака, то после этой процедуры юзер увидит окошко «приложение запрашивает разрешение», т.к. ваш сайт честным юзером еще не был авторизован, его, по истории, авторизовал злодей для своего аккаунта ФБ.
Собственно все. Надеюсь описал понятно, готов защищать свою позицию даже против Егора, как автора предполагаемой ( кстати предполагаете вы, Егор не говорил что уязвимость в OAuth, описывается уязвимость в OmniAuth)
NB: пересматривал видео после написания всего ответа, заметил упоминание именно такого момента (0:33 «Ставлю img src=этот коллбэк, подкидываю другому пользователю который в данный момент на этом сайте АУТЕНТИФИЦИРОВАН»). Собственно что я и сказал абзацем ранее — либа или сайт делают странные, неправильные вещи, они повторно аутентифицируют повторно пользователя, который УЖЕ АУТЕНТИФИЦИРОВАН.
Извините но
в п.3 читать «сайт передает а-токен»
… Интересно, этот коммент кто-нибудь осилит и осмыслит полностью при первом прочтении ;)?
… Интересно, этот коммент кто-нибудь осилит и осмыслит полностью при первом прочтении ;)?
ААА ну ненадо было столько текста я же пьяный;
> кстати предполагаете вы, Егор не говорил что уязвимость в OAuth, описывается уязвимость в OmniAuth
кстати этот егор это я. не буду отвечать на каждый из тезисов просто вкратце распишу свои.
1; Oauth grant_type = code — web based — Очевидно. А любое web based lолжно защищаться от csrf это тоже очевидно. В основоном на редиректах реализации протокола защита должна быть встроена. Иначе ее тупо не будет. Insecure -by-default means insecure уже не раз это показывал )
2. вы опять таки недоконца поняли суть современных авторизационных систем/
есть МАСТЕР аккаунт на сайте pinterest.com есть FB аккаунт. Если бы был только ФБ логин то никаких проблем по логине в хакерский ФБ небыло бы, тк сидеть из под чужого акка не есть проблема. Но сейчас большинство(ну или много) работают по схеме МАСТЕР-СОЦИАЛ КОНЕКШЕНЫ.
Задача хакера — прикрепить свой СОЦ КОНЕКШН к МАСТЕРу на сайте. после прикрепления он заходит через свой ФБ сразу в МАСТЕР юзера.
2. и это не только уязвимость в omniauth. но и в огромном количестве других имплементаций включая самодельные(что и советуется в ОП посте)
КАЖДАЯ деталь web based протокола должна быть продумана с точки зрения web based аттак. Оставлять это на откуп разработчика неправильно. исходя из этого это остается уязвимостью в oauth. пусть и зачастую потенциальной(если сайт не работает по схеме МАСТЕР-СОЦИАЛКИ а работает на основе самих социалок)
> кстати предполагаете вы, Егор не говорил что уязвимость в OAuth, описывается уязвимость в OmniAuth
кстати этот егор это я. не буду отвечать на каждый из тезисов просто вкратце распишу свои.
1; Oauth grant_type = code — web based — Очевидно. А любое web based lолжно защищаться от csrf это тоже очевидно. В основоном на редиректах реализации протокола защита должна быть встроена. Иначе ее тупо не будет. Insecure -by-default means insecure уже не раз это показывал )
2. вы опять таки недоконца поняли суть современных авторизационных систем/
есть МАСТЕР аккаунт на сайте pinterest.com есть FB аккаунт. Если бы был только ФБ логин то никаких проблем по логине в хакерский ФБ небыло бы, тк сидеть из под чужого акка не есть проблема. Но сейчас большинство(ну или много) работают по схеме МАСТЕР-СОЦИАЛ КОНЕКШЕНЫ.
Задача хакера — прикрепить свой СОЦ КОНЕКШН к МАСТЕРу на сайте. после прикрепления он заходит через свой ФБ сразу в МАСТЕР юзера.
2. и это не только уязвимость в omniauth. но и в огромном количестве других имплементаций включая самодельные(что и советуется в ОП посте)
КАЖДАЯ деталь web based протокола должна быть продумана с точки зрения web based аттак. Оставлять это на откуп разработчика неправильно. исходя из этого это остается уязвимостью в oauth. пусть и зачастую потенциальной(если сайт не работает по схеме МАСТЕР-СОЦИАЛКИ а работает на основе самих социалок)
Ну привет, Егор ;).
Жаль что не ознакомились, я вот ваше видео в итоге раза 4 пересмотрел, чтобы понять суть описываемой проблемы.
Да, пока я действительно не понял что такое мастер аккаунт в ваших терминах.
Мастер это акк на сайте Х, в который вы можете войти через ФБ ( т.е. есть у сайта связка «ФБ-что-то»-> Аккаунт1-на-сайте? )
Если почитать OAuth, то за исключением удобства http\TLS — там вообще нет привязки к протоколу передачи данных. Можно взять и реализовать это на TCP\IP. Сурово но можно. Сам OAuth описывает порядок взаимодействия сторон,3-legged-oauth, а не то, как надо использовать http. Просто для удобства он полагается на http|s — так приводить примеры проще, иначе общая теория выносит мозг
Жаль что не ознакомились, я вот ваше видео в итоге раза 4 пересмотрел, чтобы понять суть описываемой проблемы.
Да, пока я действительно не понял что такое мастер аккаунт в ваших терминах.
Мастер это акк на сайте Х, в который вы можете войти через ФБ ( т.е. есть у сайта связка «ФБ-что-то»-> Аккаунт1-на-сайте? )
Если почитать OAuth, то за исключением удобства http\TLS — там вообще нет привязки к протоколу передачи данных. Можно взять и реализовать это на TCP\IP. Сурово но можно. Сам OAuth описывает порядок взаимодействия сторон,3-legged-oauth, а не то, как надо использовать http. Просто для удобства он полагается на http|s — так приводить примеры проще, иначе общая теория выносит мозг
Кстати если обратите внимание, стандарты на протоколы часто не регламентируют употребление конкретной версии или способа защиты типа TLS 1.2 или такой-то алгоритм шифования. Просто говорят — имплементатор должен сделать надежно, на момент написания стандарта надежным считается технология X версии 1.2.3.7 и алгоритм шифрования Y, не менее 1024 бит. Как вы понимаете, после окончательного утверждения стандарта, правки в него не очень удобно вносить, а уж следить за изменяющимся ландшафтом надежности TLS или криптоалгоритмов — вообще не дело авторов. Поэтому конкретное применение HTTP|S в стандарте не обозначает что этот конкретный стандарт может работать только по http|s, в случае с OAuth 2.0 можно реализовать протокол хоть на голубиной почте ( если определенным образом голубей «защитить» от перехвата и подмены). Поэтому рекомендации о конкретной защите от Web-Based атак в протоколе общего типа — бессмысленны и даже вредны, так как запутывает реализатора.
Давайте попробуем кратко и по существу ;)
1. Вы утверждаете что уязвим протокол OAuth 2.0 или уязвима конкретная либа, его реализующая, omniauth?
1.1 Если либа — вопросов нет, криворуких программистов на свете много и их либы — довольно жалкие поделия.
1.2 Если говорите что сама концепция ( а «протокол» это порядок действий и соглашение о форматах) OAuth 2.0, то будьте любезны просмотреть драфт протокола и сказать какое именно место протокола уязвимо.
Это 2 очень принципиальных поинта — уязвимость реализации и уязвимость всей идеи. Хочется точно понять, что именно вы утверждаете.
Я вот утверждаю, что идея прописана правильно ( возможно в ней есть еще мелкие недочеты, но не фундаментальные ошибки), а конкретные либы, как частная реализация идеи — не интересны.
2. Поясните что же именно скрывается под мастер аккаунтом, потому как я не понимаю, из видео — это какой-то аккаунт на сайте, не более того.
3. Если вы настаиваете что идея уязвима, а не либа, предложу в PM способ проверить уязвимость идеи на примере конкретного сайта, в котором есть Login With Facebook и где не составит проблем понять, действительно ли проблема в протоколе или проблема в реализации. Я, юзер, перейду по сформированной вами ссылке-редиректу на этот сайт с токеном FB. Открою честно, в In-Private режиме Google Chrome, чтобы не было шансов того, что я залогинен. После этого если вы скажете содержимое моей текущей истории на сайте (а вы предполагаете что потом вы сможете зайти со своим ФБ в мой мастер? аккаунт, правильно же), мы обнародуем результаты и наверное прославимся, т.к. найдем фундаментальную уязвимость в протоколе OAuth 2.0.
Устраивает?
1. Вы утверждаете что уязвим протокол OAuth 2.0 или уязвима конкретная либа, его реализующая, omniauth?
1.1 Если либа — вопросов нет, криворуких программистов на свете много и их либы — довольно жалкие поделия.
1.2 Если говорите что сама концепция ( а «протокол» это порядок действий и соглашение о форматах) OAuth 2.0, то будьте любезны просмотреть драфт протокола и сказать какое именно место протокола уязвимо.
Это 2 очень принципиальных поинта — уязвимость реализации и уязвимость всей идеи. Хочется точно понять, что именно вы утверждаете.
Я вот утверждаю, что идея прописана правильно ( возможно в ней есть еще мелкие недочеты, но не фундаментальные ошибки), а конкретные либы, как частная реализация идеи — не интересны.
2. Поясните что же именно скрывается под мастер аккаунтом, потому как я не понимаю, из видео — это какой-то аккаунт на сайте, не более того.
3. Если вы настаиваете что идея уязвима, а не либа, предложу в PM способ проверить уязвимость идеи на примере конкретного сайта, в котором есть Login With Facebook и где не составит проблем понять, действительно ли проблема в протоколе или проблема в реализации. Я, юзер, перейду по сформированной вами ссылке-редиректу на этот сайт с токеном FB. Открою честно, в In-Private режиме Google Chrome, чтобы не было шансов того, что я залогинен. После этого если вы скажете содержимое моей текущей истории на сайте (а вы предполагаете что потом вы сможете зайти со своим ФБ в мой мастер? аккаунт, правильно же), мы обнародуем результаты и наверное прославимся, т.к. найдем фундаментальную уязвимость в протоколе OAuth 2.0.
Устраивает?
Почитайте мой коммент ниже, такая привязка не проблема протокола…
Плюсики, избранное.
Сейчас активных проектов нет, но когда займусь в очередной раз чем-то, то прикручу 100%!
А у ЖЖ этой фишки нет, или не стали делать? Вроде я на сайтах «Залогиниться через ЖЖ» видел?
Сейчас активных проектов нет, но когда займусь в очередной раз чем-то, то прикручу 100%!
А у ЖЖ этой фишки нет, или не стали делать? Вроде я на сайтах «Залогиниться через ЖЖ» видел?
Не нравится мне мода делать вход только через социалки, не хочу я давать вам доступ к своим аккаунтам!
Я примерно об эом и гвоорил когда писал про BrowserID
no problem. у меня на сайтах альтернативный вариант всегда есть — региструйтесь, вводите капчу, ждите письмо на ящик со сгенеренным паролем :)
а мне наоборот, мода ужасно нравится — завел себе специальный аккаунт на фейсбуке, через который вхожу на все сайты, где есть вход через соцсети :) огорчает только, что не на всех сайтах он есть :(
а мне наоборот, мода ужасно нравится — завел себе специальный аккаунт на фейсбуке, через который вхожу на все сайты, где есть вход через соцсети :) огорчает только, что не на всех сайтах он есть :(
Спасибо за статью!
Не могли бы вы пояснить еще один момент: как лучше реализовывать обработку таймаута логин состояния? Полученный токен же имеет время жизни?
Не могли бы вы пояснить еще один момент: как лучше реализовывать обработку таймаута логин состояния? Полученный токен же имеет время жизни?
Увы, у всех по-разному. Читайте API :( некоторые присылают refresh_token, с которым нужно получать новый access_token. У кого-то токен бессмертный (впрочем, зависит от затребованных прав) и новый не нужен. К сожалению, большинство критиков OAuth правы — даже в рамках потока аутентификации, каждый извращается кто во что горазд. Я здесь описал необходимый *минимум*, который нужен для входа на сайт через OAuth. Еще раз скажу вышеописанного недостаточно для надежной и безопасной авторизации. Но этого достаточно, чтобы знать где рыть и как сделать «все хорошо».
Про обновление токена я собирался написать в следующей статье — о интеграции инструментов социалок на свои сайты. Пока у меня даже не по всем есть вся инфа. Но это попозже, когда будет время.
Про обновление токена я собирался написать в следующей статье — о интеграции инструментов социалок на свои сайты. Пока у меня даже не по всем есть вся инфа. Но это попозже, когда будет время.
С нетерпением ждём вашу следующую статью!
Читайте драфт стандарта — там это валидный сценарий. А вот насчет недостаточно — хотелось бы послушать, очч любопытна «экспертиза» в этом вопросе.
Я про это упомянул. Что не уделил внимания ни вопросам безопасности, ни воросам обовления токена. ни тупо неуспешным течениям, которые (о, сюрприз!) у всех провайдеров тоже разные, и которые неплохо было бы адекватно парсить. Давно планирую опубликовать развернутую статью о безопасности OAuth (с конкретикой, разумеется), но все не доходят руки. Планов громадье, как обычно, а времени — увы.
Мну интересует что же вы подразумеваете под «вышеописанного недостаточно для надежной и безопасной авторизации», ибо пока что я не согласен, а слушать «критиков OAuth» — ну так 3.14здеть это не мешки ворочать. А вот о «проблемах по существу» еще ни разу не слышал, все как-то соскальзывают или оказывается проблема не в OAuth 2.0.
Удобство — да, не всегда еще удобно, стандарта-то финального нет, только черновики. А вот сомнения в надежности — очень любопытно послушать
Удобство — да, не всегда еще удобно, стандарта-то финального нет, только черновики. А вот сомнения в надежности — очень любопытно послушать
О неуспешных течениях. Одоклассники (ох уж эти одноклассники) даже в неуспешном течении возвращают 200 OK — но с описанием ошибки в теле ответа :)
Подозреваю даже — почему так. Есть маленькая проблема, например, с .NET — когда делается ручной вызов а-ля userInfo через класс WebRequest\WebClient, то любые ответы «НЕ 20x» приводят к вылету соответствующего исключения. Строить бизнес-логику на исключениях — не комильфо, а в спеке написано что регулируется только поле error, остальное — на усмотрение авторов.
7.2 Error Response
…
The OAuth resource access error registration requirement applies only
to «error» code values and not to other means of returning error
indications, including HTTP status codes, or other error-related
result parameters, such as «error_description», «error_uri», or other
kinds of error status return methods that may be employed by the
resource access method. There is no requirement that OAuth resource
access methods employ an «error» parameter.
BTW внутренний сервер у нас поступает точно так же — возвращает 200 и правильное поле error. Это торчат уши используемой платформы.
> Потому что некоторые ресурсы не поддерживают response_type=token.
это какие?
>GET oauth.vk.com/access_token?client_id={client_id}&client_secret={secret_key}& code=7a6fa4dff77a228eeda56603b8f53806c883f011c40b72630bb50df056f6479e52a//полученный в параметрах код
полное несоответствие oauth2 ieft!!! токен должен выпускаться для конкретного redirect_uri и он должен быть параметром для получения тоекна. это банальная csrf дыра, ну что за бред
>sign — трахнутая на все байты md5-подпись
для того и делали https based oauth2 чтобы не париться с подписями. Why, одноклассники? хотя у вас лучше чем у вк.
>1. Здесь OAuth 1.0 и тут всё веселее
да, у твиттера фейл =/
а у яндекса менее гибкое api, хотя статичный redirect_uri неплохое решение
не вижу в статье упоминания state :trollface:
это какие?
>GET oauth.vk.com/access_token?client_id={client_id}&client_secret={secret_key}& code=7a6fa4dff77a228eeda56603b8f53806c883f011c40b72630bb50df056f6479e52a//полученный в параметрах код
полное несоответствие oauth2 ieft!!! токен должен выпускаться для конкретного redirect_uri и он должен быть параметром для получения тоекна. это банальная csrf дыра, ну что за бред
>sign — трахнутая на все байты md5-подпись
для того и делали https based oauth2 чтобы не париться с подписями. Why, одноклассники? хотя у вас лучше чем у вк.
>1. Здесь OAuth 1.0 и тут всё веселее
да, у твиттера фейл =/
а у яндекса менее гибкое api, хотя статичный redirect_uri неплохое решение
не вижу в статье упоминания state :trollface:
>это какие?
одноклассники и майлру response_type=token не поддерживают. мне показалось логичным расписать течение, которое поддерживают все упомянутые провайдеры. как-то проще для админа.
>полное несоответствие oauth2 ieft!!!
и не единственное. а я-то при чем? :)
>не вижу в статье упоминания state
Как это? Вот же… а…
Тьфу, блин — не scope, а state. *confused* поздно было, не заметил, ща исправлю.
Не всеми он поддерживается, вот из общего списка параметров я его и выкинул.
одноклассники и майлру response_type=token не поддерживают. мне показалось логичным расписать течение, которое поддерживают все упомянутые провайдеры. как-то проще для админа.
>полное несоответствие oauth2 ieft!!!
и не единственное. а я-то при чем? :)
>не вижу в статье упоминания state
Как это? Вот же… а…
Тьфу, блин — не scope, а state. *confused* поздно было, не заметил, ща исправлю.
Не всеми он поддерживается, вот из общего списка параметров я его и выкинул.
Совершенно несправедливое отношение к OpenID.
Сегодня любой почтовик имеет свой OpenID-сервер: Гугл, Яндекс, Яху, Рамблер и даже Мейлру!
А самое главное, что OpenID предоставляет мыло, что позволяет вписать его почти в любую систему авторизации. А хваленый OAuth отдает айдишники пользователя, и как их приаязывать к модели пользователя, где емейл обязателен, не понятно. Вот почему после авторизации через FB/Twitter меня заставляют вводить дополнительные данные, что только затягивает процедуру входа.
Сегодня любой почтовик имеет свой OpenID-сервер: Гугл, Яндекс, Яху, Рамблер и даже Мейлру!
А самое главное, что OpenID предоставляет мыло, что позволяет вписать его почти в любую систему авторизации. А хваленый OAuth отдает айдишники пользователя, и как их приаязывать к модели пользователя, где емейл обязателен, не понятно. Вот почему после авторизации через FB/Twitter меня заставляют вводить дополнительные данные, что только затягивает процедуру входа.
fb отдает email насколько я помню. В остальном — генерирую randomhash@mysite.com и пусть юзер обновит если надо
FB да, а твиттер нет, к сожалению.
Сурово, а если пользователь забыл обновить, а потом забыл пароль — хочет восстановить. Вы ему куда восстановление отправите? Выход только один — или требовать ввод email до того как пользователь пойдет дальше или пользоваться провайдерами которые отдают email сами.
Твиттер не отдает и поэтому когда\если мы будем делать твиттер — мы будем заставлять пользователей вводить email, как единственное дополнительное но обязательное поле. Интерфейс-дизайнер хочет сделать это просто навязчивой плашкой, где будут нудеть — «у нас нету вашего email, доступ к некоторым разделам сайта будет ограничен и т.д», что в принципе — вариант неплохой.
Твиттер не отдает и поэтому когда\если мы будем делать твиттер — мы будем заставлять пользователей вводить email, как единственное дополнительное но обязательное поле. Интерфейс-дизайнер хочет сделать это просто навязчивой плашкой, где будут нудеть — «у нас нету вашего email, доступ к некоторым разделам сайта будет ограничен и т.д», что в принципе — вариант неплохой.
>Вот почему после авторизации через FB/Twitter меня заставляют вводить дополнительные данные, что только затягивает процедуру входа.
Прошу заметить что это затягивает процедуру не входа а регистрации. Только при регистрации нужно спросить почту юзера а потом он так-же спокойно будет входить одним нажатием точно так-же как если бы его вообще не спрашивали о почте. Тут можно совершенно определенно сказать что это удобно. Ибо пользователь может и не вспомнить на какую из десятков почт он регился на этом сайте и какой у него пароль… а нажав на кнопочку войти через твиттер, он спокойно войдет не вводя никакую почту(ибо он при самом первом входе ее уже ввел).
Прошу заметить что это затягивает процедуру не входа а регистрации. Только при регистрации нужно спросить почту юзера а потом он так-же спокойно будет входить одним нажатием точно так-же как если бы его вообще не спрашивали о почте. Тут можно совершенно определенно сказать что это удобно. Ибо пользователь может и не вспомнить на какую из десятков почт он регился на этом сайте и какой у него пароль… а нажав на кнопочку войти через твиттер, он спокойно войдет не вводя никакую почту(ибо он при самом первом входе ее уже ввел).
«Гугл, Яндекс, Яху, Рамблер и даже Мейлру!» имеют также и OAuth, а через API спокойно отдают емайл пользователя и еще много чего. Покажите мне сервис, который через OpenID дает больше информации о пользователе, чем через OAuth.
Спасибо за интересную статью, как раз недавно сталкивался с oAuth2 для проекта на GAE, но не осилил. С этой статьей попробую ещё раз.
Как же вы вовремя, съэкономили мне кучу времени
Интересно, а на каком-нибудь из этих сервисов поддерживается 2-LEGGED OAuth?
Большое спасибо за статью. Единственный момент про Твиттер — на РНР с ним можно обойтись функицей file_get_contents и вместо заголовка собирать строку запроса. Ну и в третий раз собирать подпись унд заголовок нет смысла, поскольку после второго получаем идентификатор и имя пользователя, которые спокойно подставляются вот сюда:
twitter.com/users/show.json?screen_name=['screen_name']
twitter.com/users/show.json?screen_name=['screen_name']
Эх, по тумблеру бы кто-ниубдь написал авторизацию. А то я задолбался: там вроде все так же, как в твиттере, но нифига не работает! Все время неправильная сигнатура.
Спасибо автору за систематизированный степ-бай-степ мануал. Единственная статья в рунете дающая исчерпывающее и «без мусора» пояснение. Учитывая прошедшее время неплохо было бы актуализировать некоторые моменты — скрины и ссылки. Интерфейсы разработчиков меняются, опции оказываются в других местах. К примеру у контакта создание приложения теперь тут: http://vk.com/editapp?act=create, фейсбук отказался от группы настроек AuthDialog и раскидал их по другим группам. Также важным было бы упомянуть, что например, Контакт, не отдаёт через API email пользователя — это бы избавило многих от лишних поисков ответа.
Уже имею подключенные все сервисы через oAuth и в своё время долго грыз эту науку. Хорошая статья.
На всякий случай сохраню в избранное — удобно в одном месте все популярные сайты собраны.
P.S. И когда твиттер разродится на oauth 2?..
На всякий случай сохраню в избранное — удобно в одном месте все популярные сайты собраны.
P.S. И когда твиттер разродится на oauth 2?..
При получении access_token для социальной сети ВКонтакте теперь нужно обязательно передавать redirect_uri + можно уже делать и POST-запрос, а у Twitter изменился адрес API: https://api.twitter.com/1.1/ — просьба исправить.
Автору большое спасибо за статью!
Автору большое спасибо за статью!
Почему твиттер oauth is so fucked up?
Только благодаря вашей статье разобрался с работой api моего мира, официальная документация оставляет желать. Спасибо!
На моем ресурсе (аудиотека лекций) все сервисы были доступны без регистрации. В месяц регистрировалось в среднем 1,5K юзеров. Затем я закрыл доступ и ввел обязательную регистрацию. Стало регистрироваться 3,5К юзеров а траффик вообще не просел. Тех кто кривится рожей при виде формы регистрации на самом деле по моей личной статистике не больше 5%, но это именно они пишут обычно, что регистрация бесит ВСЕХ…
Регистрация бесит, возможно, не всех, просто не все, кого она бесит вам об этом сообщают. Проверьте на досуге сколько из ваших 3.5К юзеров сделали регистрацию на одноразовое мыло, можете смело получившееся значение умножить на 10, т.к. большинство про такую возможность не знают — это те, кому ваша регистрация никуда не уперлась кроме как для получения файлов.
Всё уже на доусуге проверено и отфильтровано. Одноразовых ящиков пренебрежимо мало, настоллько что даже и говорить не о чем. Волзможно дело в том что у меня просто более культурная аудитория.А умножать на десять просто исходя из чьих то предрассудков по моему глупо. Слишком уж раздутая проблема.
у меня просто более культурная аудитория
Как тонко вы всех обосрали…
Возможно это специфика вашего контента. Тем, кому он интересен — интересен и ваш сайт, значит мусорных регистраций мало. Но это ситуация нечастая, гораздо чаще когда контент найден поиском на каком то безвестном форуме, регистрация на котором ни в какой пень мне не уперлась, кроме как один раз скачать/просмотреть какой-то документ/видео.
Не совсем понятно, вот мы получили при регистрации, скажем, через Гугл, емейл пользователя (плюс ФИО опционально). И что, он теперь каждый раз через гугл будет ходить? Или мне надо ему сгенерить локальный логин-пароль, если предполагается плотная работа с пользователем?
Сгенерировать локальный профиль на основе данных соц. сети.
Гугл в данном случае считаем авторитарным источником и верим что если он говорит что это пользователь с таким-то email значит это 100% он, а не кто-то другой.
Как делать каждый раз — в зависимости от архитектуры это может быть профиль + привязанные соц аккаунты либо просто берётся email и делается авто-регистрация и и создаётся случайный пароль.
В итоге пользователь сможет войти через соц сеть без ввода пароля, либо по email + пароль, и пароль пользователю можно выслать на email при авто-регистрации либо, так как он пароль не знает, ему для входа придётся использовать функцию сброса пароля.
В общем вариантов много, всё зависит от требований приложения.
Гугл в данном случае считаем авторитарным источником и верим что если он говорит что это пользователь с таким-то email значит это 100% он, а не кто-то другой.
Как делать каждый раз — в зависимости от архитектуры это может быть профиль + привязанные соц аккаунты либо просто берётся email и делается авто-регистрация и и создаётся случайный пароль.
В итоге пользователь сможет войти через соц сеть без ввода пароля, либо по email + пароль, и пароль пользователю можно выслать на email при авто-регистрации либо, так как он пароль не знает, ему для входа придётся использовать функцию сброса пароля.
В общем вариантов много, всё зависит от требований приложения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки