Каково будущее OAuth 1?

Question

Я собираюсь начать писать API для моего проекта с открытым исходным кодом.Должен ли я использовать OAuth 2 для аутентификации или OAuth 1?

Моя главная проблема с OAuth 1 заключается в том, что я не хочу тратить время на написание API на его основе, если OAuth 1 скоро устареет.

Мой вопрос: скоро OAuth 1 устареет?Кроме того, я думаю, что с точки зрения конечного пользователя API, OAuth 2 кажется проще в реализации.

Должен ли я просто написать OAuth2 API и забыть об OAuth 1 или есть веские причины использовать OAuth 1 сейчас?

Answer 1

Используйте OAuth 2.0.Он стабилен и готов к внедрению.Нет никаких причин, по которым кто-либо должен развертывать OAuth 1.0 на этом этапе.2.0 проще, безопаснее и надежнее.

Что касается 1.0, протокол публикуется, и любой может использовать его сколько угодно.Это информационный RFC и останется таким.Однако, как только 2.0 будет опубликован, 1.0 будет помечен как устаревший.Ни одна бюрократия IETF не должна иметь для вас никакого значения.

Answer 2

OAuth 2 находится в стадии черновика (текущая запись, черновик 16), но OAuth 1 уже находится в RFC ( RFC 5849 ).

Процесс авторизации OAuth 2 проще, чем OAuth 1, но вы можете столкнуться с тем, что вам нужно выбрать черновик, который вы хотите реализовать, и придерживаться его. Когда будет выпущен RFC для OAuth 2, вы должны будете соответствовать ему.

Addon : Если OAuth 1 будет устаревшим, RFC будет устаревшим. IETF переведет RFC в статус «исторический». Скорее всего, они могут сделать OAuth 2 RFC и сделать исторический OAuth 1 RFC. Пока это не произойдет, OAuth 1 действует по сей день.

Надеюсь, эта маленькая информация поможет вам.

Answer 3

Я серьезно волнуюсь за будущее OAuth. С тех пор, как Эран Хаммер, один из основателей OAuth, покинул группу, а позже за ним последовал Дэвид Рекордон.

Они обеспокоены безопасностью и уязвимостью OAuth 2.0. Вот как Hammer описал OAuth2.0

более сложный, менее функционально совместимый, менее полезный, более неполный и самое главное, менее безопасный.

Возможно, пришло время взглянуть на SAML для пользователей OAuth.

Answer 4

Вам следует подумать о своих пользователях (разработчиках) и выбрать соответствующий API на основе этого. Есть ли у них опыт или предпочтения? Если нет, то я бы предпочел OAuth2. Вы также можете принять решение в зависимости от типа организации, с которой вы имеете дело. Я имел дело с людьми, которые предпочитают старые протоколы, потому что они чувствуют себя более зрелыми и безопасными. Это не всегда рационально, но иногда стоит задуматься.

Есть некоторая информация о проектных решениях (почему новая версия?) Вождение Oauth2 доступно.