(программистское)

[jsn]

Am 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.

Comments

[jsn.livejournal.com]

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

Вот эта разность -- архитектурная астронавтика, в данном случае. Иными словами, это позволяет сделать конзьюмера, в котором система знает, что пять данных покупок или комментов были сделаны одним аккаунтом, но увидеть этого чисто глазами, просматривая совокупный лог или ветки дискуссий, нельзя. Увидеть комментарий и сказать "а, да это же тот чувак из дикуссии неделю назад" -- нельзя. Или "а, да это же тот же чувак, с которым я спорил на другом форуме". И т.д.

Смена ника -- или перерегистрация аккаунта -- это про другое. Речь не идёт про то, чтобы осложнить жизнь тем, кто хочет скрыть 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, больше ничего. Ну я писал в посте, собственно.

[stas]

Увидеть комментарий и сказать "а, да это же тот чувак из дикуссии неделю назад" -- нельзя. Или "а, да это же тот же чувак, с которым я спорил на другом форуме". И т.д.

Так в том-то и дело, что опенид для этого не сделан. Т.е. я не читал мысли его создателей, но из чтения доков, слушания их лекций на конференциях и т.п. я делаю именно такой вывод. 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, если их делать правильно.

[jsn.livejournal.com]

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

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 кусков кода, которые приходится поддерживать и сопровождать.

[stas]

Мне всё-таки кажется, что один API и 20 атрибутов - которые вполне реально свести к одной схеме, покрывающей 90% случаев, типа - имя, картинка, много ли надо? - это всё-таки лучше, чем 20 разных API.

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 принципиальная односторонность заложена изначально.

[jsn.livejournal.com]

Identity API -- это не 20 разных API в реальной жизни. В реальной жизни это почти всегда API вида "http get [url.json]", и всё. Да, разумеется, у гугла всё тут сильно заморочнее. Но у гугла и OpenID такой, что без поллитры не разберёшь -- библиотеки носят с собой special case по этому поводу.

Ядис это не совсем то, как мне кажется

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).

[stas]

1. OAuth для confidential [web app] clients и OAuth для public/native clients -- это два заметно разных протокола.

Ну не таких уж и разных. Различия есть, не до степени разных протоколов. Там 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 сложнее.

[jsn.livejournal.com]

Ну не таких уж и разных. Различия есть, не до степени разных протоколов. Там callback такой, тут callback сякой. Или я не понял, что имелось в виду?

Различие маленькое, но существенное :) Public/native app, в отличие от confidential app, изначально обладает пользовательским логином и паролем (и/или, в случае, если у нас аутентикация по сетчатке, то сканом сетчатки). Соответственно, токен оно получает в обмен на логин, пароль, и скан сетчатки (а не через 3-legged, который принят для confidential). Иными словами, утечка токенов из клиентов, которые уже обладают всеми user credentials, doesn't seem to be a realistic concern.

[stas]

А, до меня дошло. Вы имели в виду 2-legged oauth, а не oob oauth. Да, в этом случае у аппликации уже есть доступ, выданный тем или иным способом до того.