(программистское)
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 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)