oauth за и против opensource
Вчера в комментах к недавнему посту Давида Мзареуляна обсудили один неприятный, и, видимо, неустранимый недостаток OAuth:
Если имеется мегапопулярное открытое приложение, и злое приложение начинает использовать тот же секрет/ключ, обманывая доверчивых пользователей, и портя их данные, сервер может либо забанить ключ вообще (нехорошо: страдают юзеры популярного приложения), либо для этого конкретного ключа показывать огромное предупреждение «злое приложение Х испортит ваши данные», но надёжной защиты всё равно нет. Она возможна только в случае веб-приложений, что нам доказано примером hd-dvd aacs.
Вообще, вряд ли эту проблему можно считать недостатком технологии — она призвана решать другую задачу, и неплохо справляется со своим делом. Однако минус есть минус. Впрочем, спам тоже неискореним.
Зато сегодня пришла другая радостная новость: у спецификации OAuth появилась лицензия, и это окончательно гарантирует свободу технологии. Почему радость? Дело в том, что зачастую стандарты создаются сформированными под них структурами, которые сразу учитывают вопросы лицензирования. Однако в случае слабо связанных сообществ, работающих над стандартом (например, OpenID или OAuth), лицензирование — менее запланированный и зачастую более трудоёмкий процесс. Сейчас он завершён, ура : )
Мне кажется, создатели OAuth немного зря смешали две задачи: задачу контроля над тем, какое приложение работает с сайтом, и задачу частичного делегирования юзером прав приложению.
Вторая — действительно мегарулез. Первая — всё-таки может решаться разными способами или же вовсе не решаться (может оно и не нужно вовсе в определённых ситуациях), и не факт, что навязывание конкретного способа — это хорошо.
david_m,я думаю, первую проблему можно скорее сформулировать как задачу прозрачной для юзера передачи токенов приложению. Если бы они этого не описали, в большинстве случаев приходилось бы копипастить ключи вручную. Вообще, наверное, всё могут решить сервера, принимающие произвольные ключи консьюмера с пустыми секретами, но какой-то это неудачный путь : (
а что касается второй — протокол её не решает. В спеке не сказано ничего о том, как именно определять запрашиваемые привилегии. Поэтому тут каждый делает по-своему. Мне вот нравится namespace-like вариант гугла.
arty,Ну, протокол просто говорит — чуваки, вам не обязательно иметь боевой пароль юзера! Вы можете просто дать ему токен, он пойдёт на сайт, его авторизует, и всё будет хорошо. Вот вам рекомендуемый протокол для этого.
В общем, как показывает практика API разных сервисов, это не совсем очевидная логика, и хорошо, что OAuth её формализует.
А что там у гугла такое? Я как-то не смотрел. Но, кстати, у того же гугла в их AJAX API просто выдаётся API key и всё, без секрета. Он им (для их задач) видимо, не нужен.
david_m,если быть занудно точным, то все токены выдаются сервером : )
и мне кажется, что не менее важная часть спеки - это описание трёх способов передачи токена
у гугла есть параметр scope, который для контактов, например, имеет значение http://www.google.com/m8/feeds/ , а для календаря — http://www.google.com/calendar/feeds/
arty,