Проще говоря, кто-то может объяснить разницу между OAuth 2 и OAuth 1?
OAuth 1 устарел сейчас? Должны ли мы реализовать OAuth 2? Я не вижу много реализаций OAuth 2; большинство все еще использует OAuth 1, что заставляет меня сомневаться, что OAuth 2 готов к использованию. Это?
Эран Хаммер-Лахав отлично справился с объяснением большинства различий в своей статье Представляем OAuth 2.0. Итак, вот основные отличия:
Больше потоков OAuth, чтобы обеспечить лучшую поддержку приложений, не основанных на браузере.. Это основная критика против OAuth из клиентских приложений, которые не основаны на браузере. Например, в OAuth 1.0 настольные приложения или приложения для мобильных телефонов должны были направить пользователя на открытие своего браузера на нужную услугу, пройти аутентификацию с помощью службы и скопировать токен из службы обратно в приложение. Основная критика здесь - против пользовательского опыта. С OAuth 2.0 теперь есть новые способы для приложения получить авторизацию для пользователя.
OAuth 2.0 больше не требует, чтобы клиентские приложения имели криптографию. Это подтверждает прежний API аутентификации Twitter, который не требовал приложения к хеш-маркерам HMAC и запросам. С OAuth 2.0 приложение может сделать запрос, используя только выданный токен через HTTPS.
Подписи OAuth 2.0 намного менее сложны. Больше не нужно проводить синтаксический анализ, сортировку или кодирование.
OAuth 2.0 Ленты доступа являются "недолговечными".. Обычно токены доступа OAuth 1.0 могут храниться в течение года или более (Twitter никогда не позволяет им истекать). OAuth 2.0 имеет понятие токенов обновления. Хотя я не совсем уверен, что это такое, я предполагаю, что ваши токены доступа могут быть недолговечными (т.е. На основе сеанса), в то время как токены обновления могут быть "временем жизни". Вы должны использовать токен обновления для получения нового токена доступа, а не для повторного авторизации пользователя.
Наконец, OAuth 2.0 должен иметь четкое разделение ролей между сервером, ответственным за обработку запросов OAuth, и сервером, обрабатывающим авторизацию пользователя. Дополнительная информация об этом подробно описана в вышеупомянутой статье.
Я вижу большие ответы здесь, но то, что я пропустил, было некоторыми диаграммами, и поскольку мне пришлось работать с Spring Framework, я наткнулся на их объяснение.
Я нахожу следующие диаграммы очень полезными. Они иллюстрируют разницу в связях между сторонами с OAuth2 и OAuth1.
Предыдущие объяснения являются чрезмерно подробными и сложными ИМО. Проще говоря, OAuth 2 делегирует безопасность протоколу HTTPS. OAuth 1 не требовал этого и, следовательно, имел альтернативные методы борьбы с различными атаками. Эти методы требовали приложения для участия в определенных протоколах безопасности, которые являются сложными и могут быть сложными в реализации. Поэтому проще просто полагаться на HTTPS для обеспечения безопасности, чтобы разработчикам приложений не нужно было об этом беспокоиться.
Что касается ваших других вопросов, ответ зависит. Некоторые службы не хотят требовать использования HTTPS, были разработаны до OAuth 2 или имеют какое-то другое требование, которое может помешать им использовать OAuth 2. Кроме того, было много споров о самом протоколе OAuth 2. Как видите, Facebook, Google и несколько других имеют несколько различные версии реализованных протоколов. Поэтому некоторые люди придерживаются OAuth 1, потому что они более однородны на разных платформах. Недавно протокол OAuth 2 был доработан, но нам еще предстоит выяснить, как его принятие будет принято.
Обратите внимание, что существуют серьезные аргументы безопасности против использования Oauth 2:
Обратите внимание, что они исходят от ведущего автора Oauth 2.
Ключевые моменты:
Oauth 2 не обеспечивает безопасности поверх SSL, в то время как Oauth 1 не зависит от транспорта.
в некотором смысле SSL не является безопасным в том смысле, что сервер не проверяет соединение, а общие клиентские библиотеки позволяют легко игнорировать сбои.
Проблема с SSL/TLS в том, что когда вы не можете проверить сертификат на стороне клиента, соединение все еще работает. Каждый раз, когда игнорирование ошибки приводит к успеху, разработчики собираются сделать это. Сервер не имеет возможности принудительно проверить сертификат, и даже если это возможно, злоумышленник, безусловно, не сможет.
Вы можете отмахнуться от всей своей безопасности, что гораздо труднее сделать в OAuth 1.0:
Вторая общая потенциальная проблема - опечатки. Считаете ли вы это правильным дизайном, если пропустить один символ ('в' https), что аннулирует полную безопасность токена? Или, возможно, отправка запроса (через действительное и проверенное соединение SSL/TLS) в неправильный пункт назначения (например, " http://gacebook.com?"). Помните, что возможность использовать OAuth-токены-носители из командной строки была явно продвинутой защитниками токенов-носителей.
Безопасность протокола OAuth 1.0 (RFC 5849) основывается на предположении, что секретный ключ, встроенный в клиентское приложение, может оставаться конфиденциальным. Однако предположение наивно.
В OAuth 2.0 (RFC 6749) такое наивное клиентское приложение называется конфиденциальным клиентом. С другой стороны, клиентское приложение в среде, в которой трудно сохранить секретный ключ конфиденциальным, называется открытым клиентом. Смотри 2.1. Типы клиентов для деталей.
В этом смысле OAuth 1.0 является спецификацией только для конфиденциальных клиентов.
" OAuth 2.0 и дорога в ад " говорит, что OAuth 2.0 менее безопасен, но нет практической разницы в уровне безопасности между клиентами OAuth 1.0 и конфиденциальными клиентами OAuth 2.0. OAuth 1.0 требует вычисления подписи, но он не повышает безопасность, если он уже уверен, что секретный ключ на стороне клиента может оставаться конфиденциальным. Вычисление подписи - это просто громоздкий расчет без какого-либо практического повышения безопасности. Я имею в виду, что по сравнению с простотой, когда клиент OAuth 2.0 подключается к серверу через TLS и просто представляет client_id и client_secret, нельзя сказать, что громоздкие вычисления лучше с точки зрения безопасности.
Кроме того, в RFC 5849 (OAuth 1.0) ничего не говорится об открытых перенаправителях, а в RFC 6749 (OAuth 2.0) - нет. То есть параметр oauth_callback в OAuth 1.0 может стать дырой в безопасности.
Поэтому я не думаю, что OAuth 1.0 более безопасен, чем OAuth 2.0.
Безопасность OAuth 1.0 основана на вычислении подписи. Сигнатура вычисляется с использованием секретного ключа, где секретный ключ является общим ключом для HMAC-SHA1 (RFC 5849, 3.4.2) или личным ключом для RSA-SHA1 (RFC 5849, 3.4.3). Любой, кто знает секретный ключ, может вычислить подпись. Таким образом, если секретный ключ скомпрометирован, сложность вычисления подписи не имеет смысла, какой бы сложной она ни была.
Это означает, что безопасность OAuth 1.0 основана не на сложности и логике вычисления подписи, а просто на конфиденциальности секретного ключа. Другими словами, для обеспечения безопасности OAuth 1.0 требуется только условие, что секретный ключ может оставаться конфиденциальным. Это может показаться экстремальным, но вычисление подписи не добавляет улучшения безопасности, если условие уже выполнено.
Аналогично, конфиденциальные клиенты OAuth 2.0 полагаются на то же условие. Если условие уже выполнено, есть ли проблема в создании безопасного соединения с использованием TLS и отправке client_id и client_secret на сервер авторизации через защищенное соединение? Есть ли большая разница в уровне безопасности между конфиденциальными клиентами OAuth 1.0 и OAuth 2.0, если оба используют одно и то же условие?
Я не могу найти вескую причину, чтобы OAuth 1.0 обвинял OAuth 2.0. Дело просто в том, что (1) OAuth 1.0 является лишь спецификацией только для конфиденциальных клиентов и (2) OAuth 2.0 упростила протокол для конфиденциальных клиентов и поддерживаемых общедоступных клиентов. Независимо от того, хорошо ли это известно или нет, приложения для смартфонов классифицируются как публичные клиенты (RFC 6749, 9), которые получают выгоду от OAuth 2.0.
Подписи OAuth 2.0 не требуются для фактических вызовов API после того, как маркер был сгенерирован. Он имеет только один токен безопасности.
OAuth 1.0 требует, чтобы клиент посылал два токена безопасности для каждого вызова API и использовал их для генерации подписи. Для подтверждения запроса требуется, чтобы конечные точки защищенных ресурсов имели доступ к учетным данным клиента.
Здесь описывается разница между OAuth 1.0 и 2.0 и как обе работают.
OAuth 2, по-видимому, пустая трата времени (из уст человека, который был сильно вовлечен в это):
https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529
Он говорит (отредактировано для краткости и выделено жирным шрифтом для акцента):
... Я больше не могу быть связан со стандартом OAuth 2.0. Я ушел в отставку с должности ведущего автора и редактора, исключил свое имя из спецификации и покинул рабочую группу. Удаление моего имени из документа, над которым я кропотливо работал три года, и более двух десятков черновиков было нелегким делом. Решение перейти от усилий, которые я возглавлял более пяти лет, было мучительным.
... В итоге я пришел к выводу, что OAuth 2.0 - плохой протокол. WS- * плохо. Это достаточно плохо, что я больше не хочу быть связанным с этим.... По сравнению с OAuth 1.0 спецификация 2.0 является более сложной, менее функциональной, менее полезной, более неполной и, что наиболее важно, менее безопасной.
Чтобы быть ясным, OAuth 2.0 от руки разработчика с глубоким пониманием веб-безопасности, скорее всего, приведет к безопасной реализации. Тем не менее, в руках большинства разработчиков - как показывает опыт последних двух лет - 2.0, вероятно, приведет к небезопасным реализациям.
Если вы хотите увидеть краткое объяснение и подробный поток (с диаграммами) OAuth, вы можете проверить http://oauthbible.com
OAuth 2.0 обещает упростить вещи следующими способами:
Если вам нужно подробное объяснение, вам нужно прочитать обе спецификации:
Если вам нужно четкое объяснение различий потоков, это может помочь вам:
OAuth 1.0 Flow
OAuth 2.0 Flow
С точки зрения безопасности я бы пошел на OAuth 1. См. OAuth 2.0 и путь в ад
цитата из этой ссылки: "Если вы в настоящее время используете 1.0 успешно, игнорируйте 2.0. Он не предлагает реального значения более 1.0 (Im догадывается, что ваши разработчики уже уже определили 1.0 подписей).
Если вы новичок в этом пространстве и считаете себя экспертом по безопасности, используйте 2.0 после тщательного изучения его возможностей. Если вы не эксперт, используйте 1.0 или скопируйте версию 2.0 поставщика, которому вы доверяете, чтобы получить его право (документы API Facebooks - это хорошее место для начала). 2.0 лучше для больших масштабов, но если вы выполняете крупную операцию, у вас, вероятно, есть некоторые эксперты по безопасности на сайте, чтобы понять все это для вас ".