(программистское)
Aug. 27th, 2011 05:51 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jsnAm I missing something huge, or did Yahoo indeed went to great lengths to make their OpenID *and* OAuth support utterly useless (borderline harmful, in fact) for any purposes related to, eh, identification? It's called "Open *ID*", for Pete's sake. The consumer should be given an unique, recognizable, human readable identification name or URL or something. What they give you instead is a pair of Last name, First name (practically guaranteed to be non-unique, and user-editable anyway), and God-awful random token a few miles long, useless for every practical intent and purpose. No usable nickname, no profile link, no email, nothing. WTF were they thinking? So okay, OpenID was a damn mess to start with, but then they go ahead and implement the new shiny OAuth spec, hooray! Oh wait, here we go again: no nickname, no profile link, and an ugly useless random token. F-ng atrocious.
no subject
Date: 2011-08-28 08:28 am (UTC)Мне кажется, тут есть некоторая путаница. OpenID обеспечивает узнаваемость identity для сервера, а уж как сервер обеспечивает для этого GUI - совершенно другой вопрос. Пример - я использую wordpress.com как провайдера моей идентичности для сервера stackoverflow.com. Однако на вордпрессе и на stackoverflow меня зовут совершенно по-разному. У этого есть две причины: а) я могу не хотеть, чтобы меня звали одинаково и б) что такое "зовут", на разных сайтах может пониматься кардинально по-разному. Т.е. та идентичность, о которой идёт речь - это не человеческая, а серверная идентичность. Она может совпадать с человеческой в виде email, url, или чего ещё, но совершенно не обязана.
Вся эта малоосмысленная шняга с unique id -- который, на самом-то деле, привязан не к паре provider / account, а к туплу provider / account / consumer, что гораздо хуже
Это, как я понимаю, из соображений приватности/безопасности - сервису А не обязательно знать, как меня зовут на сервисе Б, даже если оба опираются на один источник.
и нынешний упадок openid во многом вызван этими тенденциями, я считаю.
А что, упадок? Я, например, наоборот замечаю, что всё больше сайтов пускают по openid. Я, впрочем, на статистический охват не претендую, чисто anecdotal.
Однако, один из наиболее заманчивых API таких внешних ресурсов -- это identity service.
Ваши слова бы да этим ресурсам в уши... Но это ж не беда протокола авторизации, что у провайдера после авторизации нет правильного API. Но яха вроде OpenSocial поддерживает - /people/@me/@self, говорит, у них есть и после oauth доступно. Правда, что там внутри, не знаю.
no subject
Date: 2011-08-28 08:54 am (UTC)Ну вот нет, в исходной рационали identity предполагалась для показа человеку. Никак разумно показать идентити вида random token нельзя, full stop. То, что у вас разные ники на разных сервисах is besides the point; задачей OpenID являлось привязать (скажем) комменты к одному аккаунту, а не к одному человеку. То есть, для любой практической цели важно, что comment1 и comment2 (а также purchase5 и action114) совершены от одного и того же аккаунта. То, что у владеца этого аккаунта есть также ещё аккаунты в других местах с другим ником, совершенно неважно.
сервису А не обязательно знать, как меня зовут на сервисе Б
Сервис -- это железка же, что она вообще может знать :) Пойнт про понятную человеку identity был очень важным в изначальном обосновании пользы OpenID.
А что, упадок?
Ну да. Все новые сервисы запускающиеся в первую голову реализуют facebook / twitter OAuth, и многие вообще на этом останавливаются -- потому что этого достаточно для того, чтобы впустить почти кого угодно. Те, кто не останавливается, видят очень маленькое количество реально используемых openid logins, насколько я понимаю; бОльшая часть -- это логины через OAuth.
Но это ж не беда протокола авторизации
Абсолютно. Я ни разу не сказал худого слова про OAuth, только про Yahoo :) Про opensocial спасибо, надо будет поиграться как-нибудь. Однако проблема-то с Yahoo в том, что если разрешать вход через openid, yahoo-шные люди приходят с вот такими бесполезными identities, и ничего с ней сделать потом нельзя, в том числе прогнать через opensocial (это ж openid, не oauth).
no subject
Date: 2011-08-28 09:14 am (UTC)задачей OpenID являлось привязать (скажем) комменты к одному аккаунту
Вот тут есть противоречие - аккаунт и показ человеку - разные вещи. Т.е. как называется аккаунт внутри и как он показывается снаружи - в ЖЖ, возможно, одно и то же, но совершенно не обязательная вещь. Т.е. сцуп, например, за смену ника бабло берёт - но нормальный сервис мог бы это делать совершенно бесплатно, скажем.
Все новые сервисы запускающиеся в первую голову реализуют facebook / twitter OAuth
Эти сервисы, по-моему, не совсем понимают, зачем нужен oauth, но это другая грустная история. T.e. зачем для комментирования в третьем сервисе просить авторизацию доступа к своему фейсбуку (и, главное, получать!) вместо использования протокола, который для этого предназначен, и даже имеет Attribute Exchange Extension специально для передачи данных вместе с identity - мне не совсем ясно. С моей кочки картина немного другая, но вполне возможно, что кочка просто низковата.
Если действительно сторонние сервисы массово используют oauth вместо openid для identity management - мне кажется, это такой disaster waiting to happen, т.к. явно нарушает принцип минимальных привилегий. Впрочем, принцип неуловимого Джо тоже никто не отменял...
Те, кто не останавливается, видят очень маленькое количество реально используемых openid logins, насколько я понимаю; бОльшая часть -- это логины через OAuth.
Признаться, тут я не совсем понял - ведь это identity consumer выбирает, что использовать, фейсбук тот же поддерживает и то, и сё - т.е. как его попросят, так и зайдут, это выбор писателя сервиса. Или вы имеете в виду, что провайдеры OpenID видят мало использований их ID? Интересно было бы поглядеть на статистику того-же фейсбука, хотя понятно, что по oauth можно сделать больше, должны больше и пользоваться.
yahoo-шные люди приходят с вот такими бесполезными identities, и ничего с ней сделать потом нельзя, в том числе прогнать через opensocial (это ж openid, не oauth).
Вот тут:
http://developer.yahoo.com/blogs/ydn/posts/2009/12/yahoo_openid_now_with_attribute_exchange/
нам пишут о поддержке Attribute Exchange, разве это не помогает?
no subject
Date: 2011-08-28 09:47 am (UTC)Вот эта разность -- архитектурная астронавтика, в данном случае. Иными словами, это позволяет сделать конзьюмера, в котором система знает, что пять данных покупок или комментов были сделаны одним аккаунтом, но увидеть этого чисто глазами, просматривая совокупный лог или ветки дискуссий, нельзя. Увидеть комментарий и сказать "а, да это же тот чувак из дикуссии неделю назад" -- нельзя. Или "а, да это же тот же чувак, с которым я спорил на другом форуме". И т.д.
Смена ника -- или перерегистрация аккаунта -- это про другое. Речь не идёт про то, чтобы осложнить жизнь тем, кто хочет скрыть identity, а про то, чтобы устроить её разумно для тех, которые готовы предоставлять свою identity. Анонимизированные токены эту идею убивают напрочь, при этом, на мой взгляд, это была бОльшая часть ценности OpenID как такового.
Эти сервисы, по-моему, не совсем понимают, зачем нужен oauth, но это другая грустная история. T.e. зачем для комментирования в третьем сервисе просить авторизацию доступа к своему фейсбуку (и, главное, получать!) вместо использования протокола, который для этого предназначен, и даже имеет Attribute Exchange Extension специально для передачи данных вместе с identity - мне не совсем ясно.
Нет, тут тоже совершенно несогласен. Во-первых, identity API -- это частный случай API, и ровно для этого OAuth и создавался. Во-вторых, identity API может и должен быть разный у разных провайдеров identity, чтобы цвели сто цветов -- и это нельзя решить в OpenID через костыли вроде SREG / AX. В-третьих, часто хорошая, годная интеграция не сводится чисто к identity. Вообще это длинная тема, можно как-нибудь отдельно. В целом -- OpenID как таковой решает очень узкую подзадачу из области, которая на самом деле гораздо шире, и будет развиваться дальше. В OAuth-е пока что вроде бы есть всё, чтобы это развитие в дальнейшем.
Признаться, тут я не совсем понял
Я имею в виду, что функцией login via openid из негикового населения пользуется очень мало народу, а функцией login via facebook / twitter -- которая повсеместно реализована через OAuth -- пользуются все. Я бы и сам не морочился с реализацией OpenID сейчас, если бы не а) совместимость, и б) я в России, стране с самой большой в мире популяцией негиковых владельцев OpenID.
AX / SREG: да, конечно, yahoo поддерживает AX и SREG. Разумеется, наиболее бесполезным возможным образом: они отдают first name и last name, больше ничего. Ну я писал в посте, собственно.
no subject
Date: 2011-08-28 08:06 pm (UTC)Так в том-то и дело, что опенид для этого не сделан. Т.е. я не читал мысли его создателей, но из чтения доков, слушания их лекций на конференциях и т.п. я делаю именно такой вывод. Openid решает следующую задачу - как пользоваться логином с других сайтов, не имея доступа к их клиентской базе и внутренностям и не зная ничего о их внутренней структуре.
Ценность идеи именно в этом, ПМСМ - иметь возможность зеркалить чужие эккаунты в своей системе, при этом не будучи зависимым ни от чего в чужой системе. Разумеется, после этого возникает вопрос - ок, эккаунт я отзеркалил, теперь мне надо для него делать GUI, а как это сделать, если я не знаю таких-то и таких-то интересных атрибутов, которые есть у всех остальных экаунтов у меня в системе? Для этого, как я понимаю, и есть AX, но далеко не все его поддерживают одинаково.
identity API -- это частный случай API, и ровно для этого OAuth и создавался.
Теоретически вы абсолютно правы, API есть API, и можно сделать правильный API через OAuth.
Практически же выходит вот какая штука. OAuth - протокол авторизации, и может обеспечивать доступ к чему угодно. Поскольку юзеры в жизни не будут читать экранчики, которые им показывает фейсбук (и любой другой провайдер), а сразу нажимают "Allow", большинство из них даёт сайтам доступ к гораздо большему количеству APIs и данных, чем нужно для того, чтобы узнать identity и связать их. Хорошо, если на провайдере позаботились о том, чтобы уметь выдавать read-only tokens, а если нет?
В результате, мы имеет миллионы авторизованных токенов, валяющихся на тысяче сайтов и ждущих какого-нибудь червяка, который их соберёт и устроит такие лулзы, что об этом будет говорить вся Одесса.
Причём сделано это исключительно потому, что протокол односторонней анонимной идентификации, сделанный специально для этого - не используют, а настраивать более мощный протокол авторизации, выставляя там правильные границы - никто не желает и не умеет.
Во-вторых, identity API может и должен быть разный у разных провайдеров identity
Этот сентимент мне не совсем понятен - мне, например, хотелось бы, чтобы был единый протокол, с помощью которого я могу делать поддержку third-party identity, а не 20 протоколов и 20 кусков кода, которые я должен буду поддерживать, отлаживать и сопровождать. Мне кажется, требования в 99% случаев, когда нужна identity, вполне одинаковые и хорошо покрываются OpenID+AX/SREG, если их делать правильно.
no subject
Date: 2011-08-28 08:37 pm (UTC)OpenID как задумка был ничего, но то, что реально выросло, достаточно бесмысслено. С одной стороны, у нас есть livejournal.com, как первый reference implementation, и как большой игрок на этом поле. Он не отдаёт никаких AX / SREG, тупо ограничиваясь одним URL-ем в качестве identity. Таких же, как он -- ещё тысяча помельче. С другой стороны, у нас есть Yahoo, тоже немелкий, который отдаёт совершенно бесполезный token, и малополезную дурь в AX-атрибутах.
Итого: ваша реализация конзьюмера либо а) будет давать вменяемый UI, когда AX-ов нет, и будет совершенно неюзабельна в случае с Yahoo, либо б) будет давать обманчивый и неправильный, но прилично выглядящий, UI для случая Yahoo и непонятно что для случая отсутствия AX-ов, либо ц) выкручиваться мутными, тошнотворными эвристиками типа гигантского switch statement внутри на предмет "а кто у нас сегодня провайдер".
Rationale и мотивация OpenID (в девичестве Yadis) излагась нашим старым другом Фитцпатриком, когда он его создавал, конкретно с прицелом на то, что identity URL не будет требовать отдельных мучений по UI. Сам ли Брэд потом ударился в астронавтику, или комитет какой подыграл -- я не в курсе, но сама проблема "как же нам теперь делать UI" была придумана после, вместе с идеей отделить identity per se от human recognizable identity.
Что до подтверждения пермиссий: 1) в openid эта проблема тоже есть для AX-атрибутов. По-хорошему, пользователя надо спрашивать, готов ли он отдать email третьим лицам. Совсем не все имплементации это делают, 2) в OAuth конзьюмер не анонимен, в отличие от OpenID. Отозвать все токены конкретного конзьюмера при первых признаках стрёма -- минутное дело; facebook, полагаю, это делает посто роботом, 3) пока что пользователи демонстрируют адекватную вменяемость в области чтения диалогов, которые спрашивает OAuth, и 4) если вы не хотите давать ничего, кроме чтения identity, то никто не заставляет такой API вообще реализовывать, или давать к нему OAuth-доступ через простой незаметный диалог.
Мне кажется, требования в 99% случаев, когда нужна identity, вполне одинаковые и хорошо покрываются OpenID+AX/SREG, если их делать правильно.
Их нереально делать правильно. Жёстко заданная схема AX всегда мешала бы своей жёсткостью сервисам, которые хотят большего. Мягко заданная схема AX приводит, как мы видим (машет рукой в сторону своего git log-а) к упомянутому вами зоопарку из 20 кусков кода, которые приходится поддерживать и сопровождать.
no subject
Date: 2011-08-28 09:48 pm (UTC)OpenID (в девичестве Yadis)
Ядис это не совсем то, как мне кажется. Ядисом отыскивают endpoints для сервисов, в том числе - openid. Ещё один уровень абстракции, если кому мало было :)
но сама проблема "как же нам теперь делать UI" была придумана после, вместе с идеей отделить identity per se от human recognizable identity.
Ну проблема-то изначально была, потому что понятия об identity у всех разные - кому почтовый адрес с зипкодом, а кому ник с няшными котиками. Просто когда проект вырос из "давайте свяжем два уютных бложика" до размера индустирального - проблемы и полезли.
в OAuth конзьюмер не анонимен, в отличие от OpenID.
ггг, да, только у очень многих провайдеров есть такая штука, как anonymous/anonymous. Потому как по-другому раздавать consumer keys всяким мобилам и installable apps довольно трудно, да и толку с того, что у 9000 инсталяций одной программы один и тот же consumer key, довольно мало.
Токены, конечно, отозвать можно, только для этого надо знать, что их спёрли. А когда это узнают, будет уже поздно. Токены сейчас у большинства провайдеров вечные, а у твиттера, например, насколько я понимаю, ещё и без всяких permissions. У гугла, насколько я понимаю, один и тот же scope даёт доступ как на чтение контактов, так и на запись, и отдельного только для чтения нет. Ну и т.д. Т.е. нормально делать, конечно, можно - но никто ж не делает! В OpenID принципиальная односторонность заложена изначально.
no subject
Date: 2011-08-28 10:33 pm (UTC)Ядис это не совсем то, как мне кажется
Initially referred to as Yadis (an acronym for "Yet another distributed identity system"),[38] it was named OpenID after the openid.net domain name was given to Six Apart to use for the project. (http://en.wikipedia.org/wiki/Openid#History)
Ну проблема-то изначально была, потому что понятия об identity у всех разные
В рамках OpenID identity всегда была тождественна URLу.
только у очень многих провайдеров есть такая штука, как anonymous/anonymous
Вы путаете с прямым углом, по-моему.
1. OAuth для confidential [web app] clients и OAuth для public/native clients -- это два заметно разных протокола.
2. Анонимный доступ не описан в спецификации OAuth ни для одного из них (beyond the scope of this document or something).
3. Механизм аутентикации public/native clients исчерпывающе описан в спеке, и ничего довольно трудного в нём нет. Разумеется, consumer key там не фигурирует (в том смысле, в котором он используется в confidential [web app] clients). Однако, он совершенно не является анонимным.
Я лично не встречал упоминаемых вами чисто анонимных OAuth-ных ключей. But then again, I'm not an expert.
В твиттере доступ токена чётко определён при регистрации приложения.
В гугле определены scopes для read-only как минимум для некоторых API, по беглому просмотру; глубже я не копал.
Принципиальная одностороннесть OpenID серьёзно ограничивает его применимость для реальных задач (e.g. когда вам нужно что-то большее, чем однонаправленный трансфер identity, вы попадаете на либо вторую аутентикацию, либо довольно дикое сооружение из двух провайдеров / двух конзьюмеров, которые являют собой довольно жалкое ad-hoc подобие oauth).
no subject
Date: 2011-08-29 03:20 am (UTC)Ну не таких уж и разных. Различия есть, не до степени разных протоколов. Там callback такой, тут callback сякой. Или я не понял, что имелось в виду?
Я лично не встречал упоминаемых вами чисто анонимных OAuth-ных ключей. But then again, I'm not an expert.
У гугля ключ anonymous/anonymous. См.: http://code.google.com/apis/accounts/docs/OAuth_ref.html#SigningOAuth
Что касается твиттера, я, по-видимому, был неправ, т.к. читал их API давно и сейчас там горадо больше уровней доступа, чем я помнил. То ли я невнимательно читал, то ли они их добавили.
Принципиальная одностороннесть OpenID серьёзно ограничивает его применимость для реальных задач (e.g. когда вам нужно что-то большее, чем однонаправленный трансфер identity, вы попадаете на либо вторую аутентикацию
Моё скромное мнение, что это не баг, а фича. Каждой задаче - свой инструмент. Мне кажется, что для OpenID вполне есть ещё место под солнцем, особенно в сценариях типа "закомментируй под своим фейсбучным логином" - а вот сделать правильный и безопасный openID на порядок легче, чем правильный и безопасный Oauth. Для более глубокой интеграции, конечно, нужен API сложнее.
no subject
Date: 2011-08-29 06:14 am (UTC)Различие маленькое, но существенное :) Public/native app, в отличие от confidential app, изначально обладает пользовательским логином и паролем (и/или, в случае, если у нас аутентикация по сетчатке, то сканом сетчатки). Соответственно, токен оно получает в обмен на логин, пароль, и скан сетчатки (а не через 3-legged, который принят для confidential). Иными словами, утечка токенов из клиентов, которые уже обладают всеми user credentials, doesn't seem to be a realistic concern.
no subject
Date: 2011-08-29 07:17 am (UTC)no subject
Date: 2011-08-28 09:55 am (UTC)Фейсбук не является OpenID provider-ом, насколько я могу видеть.
no subject
Date: 2011-08-28 07:10 pm (UTC)Я был уверен, что фейсбук поодерживает openid, но вы правы - он только consumer. Это эпичский фейл с их стороны, ПМСМ, причём совершенно не имеющий рационального обьяснения.
no subject
Date: 2011-08-28 07:39 pm (UTC)Представьте себе, что FB таки реализовал бы OpenID as THE way to authenticate FB users. Во-первых, каждый конзьюмер, желающий такой же степени удобства, как с OAuth/OG, должен был бы предоставлять для FB отдельный "nascar link", в терминологии OpenID. Во-вторых, всю информацию, которую FB желает отдавать конзьюмерам, им пришлось бы втискивать в AX attributes, которые нестандартны по определению -- то есть конзьюмерам пришлось бы всё равно делать отдельный протокол парсер под FB. On top of that, развитие Open Graph-а вело бы к непрерывной тасовке этого самого набора AX attributes, что сделало бы жизнь конзьюмеров совершенным адом. Наконец, для случаев, когда интеграция не сводится к передаче identity information, всё равно пришлось бы реализовывать OAuth, в дополнение к OpenID, и значительной части реальных конзьюмеров пришлось бы поддерживать одновременно два стандарта -- с соответствующими удобствами для пользователя (я не представляю себе, как это можно удобно сделать, не заставляя пользователя проходить повторную авторизацию для доступа к чему-либо кроме identity).
Словом, ну реально, это был бы сущий ад. OpenID реально совершенно не подходит для всех этих современных штук. OpenID относительно выносим для случаев, когда ничего, кроме identity в виде URL-а, вам не требуется -- ни аватара, ни имени, ни данных почитать, ничего. Такие случаи бывают, но они совершенно точно не исчерпывают все распространённые в наше время use case-ы.
no subject
Date: 2011-08-28 08:06 pm (UTC)Да, openid не покрывает advanced cases - но мой пойнт как раз в том, что 99% cases, которые я вижу - вовсе не advanced.
no subject
Date: 2011-08-28 08:16 pm (UTC)no subject
Date: 2011-08-28 08:30 pm (UTC)Это, ПМСМ, gaping security hole - доверять какому-то сайту постить от моего имени комментарии в фейсбуке. Потому как никакого способа сказать "этот комментарий можно, а остальные нельзя", натурально, нет. Т.е. теперь вопрос о появлении червяка, который утащит эти токены и устроит всем фейсбучникам много лулзов - это вопрос только "когда".
Ну и - это ведь уже далеко не identity, это write access. Это совершенно другой юзкейс.
no subject
Date: 2011-08-28 08:48 pm (UTC)Разумеется, это не identity. Интеграция с federated login в общем случае не сводится к identity. Which is exactly the point I'm trying to make.
Токены фейсбучные утекают регулярно, я полагаю. Фейсбуковская автоматика ловит, полагаю, такие случаи на взлёте и не вспотев. Но будут и fuck up-ы, чего ж. Не следует думать, что вовлечённые стороны не в курсе этого риска.