Я искал некоторую информацию в Интернете об этом и попал в RFC для протокола Oauth 1.0: http://tools.ietf.org/html/rfc5849
Вы можете прочитать "Obsoleted by: 6749" вверху, и если вы следуете этой ссылке, вы попадете в RFC-систему авторизации OAuth 2.0.
Исходя из этого, могу ли я уверенно заключить, что OAuth 1.0 устарел в пользу OAuth 2.0?
Спасибо.
Да и Нет.
IETF опубликовала новую версию OAuth 2 obsoleting OAuth 1.x и настоятельно рекомендует новым поставщикам Auth переключиться на OAuth2.
Существует версия OAuth 1.0a, которая исправляет многие из недостатков безопасности, обнаруженных в 1.0, и считается, что она является самой безопасной версией OAuth.
OAuth2 - совершенно новый протокол и не совместим с OAuth 1.x. Основные различия в отношении OAuth 1 перечислены в этой нити.
Однако, не все так же счастливы с новым стандартом. Эран Хаммер-Лахав, ведущий автор и редактор спецификаций OAuth, отказался от комитета, ссылаясь на причины в этом сообщении .
Хомаков, который поднялся до известности своим эксплойтом в Гитубе, не так хорошо говорит о OAuth 2.
Итак, да, OAuth 2 официально заменил OAuth 1.x, но в сети есть противоречивые мнения о том, следует ли использовать OAuth2 или придерживаться OAuth 1.0a.
Да)
Большинство компаний используют 2.0 - например google:
Важно: OAuth 1.0 официально устарел по состоянию на 20 апреля, 2012. Он будет продолжать работать согласно нашей политике устаревания, но мы рекомендуем вам как можно скорее перейти на OAuth 2.0.
но некоторые из них используют 1.0 или 1.0a, как вы можете видеть wiki: OAuth в главе Список поставщиков услуг OAuth
Существует также официальная информация о том, что 1.0 устарел RFC 6749: OAuth 2.0 Authorization Framework
. Эта спецификация заменяет и устаревает OAuth 1.0 протокол, описанный в RFC 5849.
И RFC 5849 Протокол OAuth 1.0
Прямой ответ на ваш вопрос: да. Из OAuth 2.0 spec:
в этой спецификации предполагается, что новые реализации поддерживают OAuth 2.0, как указано в этом документе, и что OAuth 1.0 используется только для поддержки существующих развертываний.
Хотя я предпочитаю OAuth 2.0 и реализовал сервер авторизации 2.0 и внесли свой вклад в спецификацию, я не могу сказать, что один лучше другого. Я считаю, что 2.0 легче работать.
Как полезный протокол, OAuth 1.0 не устарел или не имеет значения. Начиная с версии 1.0a (RFC 5849 - 1.0a), я не знаю об уязвимостях, которые делают ее менее безопасной, чем 2.0, и на самом деле она, пожалуй, более безопасна по умолчанию. 1.0 так же способен обрабатывать большинство случаев использования.
OAuth 2.0 несовместим с OAuth 1.0; это совершенно новый протокол. Конструктивные решения, которые стимулировали разработку 2.0, не были укоренены в недостатках 1.0, само по себе, но, скорее, 2.0 было вызвано стремлением сделать OAuth более простым для реализации и более элегантным для использования случаев, которые были трудными для 1.0 (например, родными приложения).
Некоторые отличия, которые стоит отметить:
2.0 зависит от безопасности, предоставляемой зашифрованными соединениями TLS. 1.0 не требует TLS, и в результате протокол более сложный, поскольку он должен включать в себя свою собственную защиту от атак типа "человек-в-середине". Например, 1.0 полагается на подписанные запросы для доступа к защищенным ресурсам, тогда как 2.0 предлагает гораздо более простой Знак доступа к токену.
2.0 разбивает сервер OAuth на две концептуальные роли : (1) сервер авторизации и (2) сервер ресурсов. Такое разделение проблем естественно связано с предприятиями, где проблемы с авторизацией распределяются по многим серверам, ответственным за различные типы ресурсов.
2.0 различает конфиденциальные и общедоступные клиенты. Публичными клиентами являются те, которые работают на пользовательских устройствах, и поэтому они не могут надежно хранить секреты (жестко закодированные встроенные учетные данные). Различие между конфиденциальными и общедоступными клиентами упрощает принятие решений по безопасной реализации, которые отвечают потребностям разработчиков клиентских приложений.
2.0 вводит несколько типов разрешений авторизации. Каждый тип гранта имеет свой собственный поток протокола, и эти потоки протокола делают OAuth 2.0 адаптированным для нескольких вариантов использования и типов клиентов.
2.0 прилагает большие усилия для расширения. Раздел 8 спецификации содержит положения для определения новых типов токенов доступа, типов грантов и параметров протокола. Например, помимо токенов-носителей, работа переходит в маркеры MAC и Знаки жетонов JWT.
Это субъективно, но можно сказать, что OAuth 2.0 пытается быть гибким во многих случаях использования, где OAuth 1.0 требовал от разработчиков соответствовать их применениям в более жесткой структуре.
Я действительно не думаю, что вы можете сказать, что OAuth 1.0 устарел в пользу OAuth 2.0. Вы можете работать с 1.0, если это соответствует вашим требованиям.
2.0 лучше для больших масштабов, так как Twitter сделал это, и изменил его API с 1 на 1.1, поэтому использовать новый OAuth, но это связано с твиттером. В другом случае может быть 1.0. все еще работает идеально, поэтому нет необходимости обновляться.
OAuth 2.0. должен делать больше похоже на публичное шифрование, открытый ключ. И не частные, не большие новости, так как этот метод известен уже много лет. Таким образом, все еще существуют разные мнения о том, хорошо это или плохо.
Здесь Oauth2.0 и дорога в ад, и здесь OAuth 2.0'bad ' Я думаю, вы можете найти более интересную и подробную информацию о том, что вы хотите.