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

[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]

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. Да, в этом случае у аппликации уже есть доступ, выданный тем или иным способом до того.