Как OAuth 2 отличается от OAuth 1?

Ответ 1

Эран Хаммер-Лахав отлично справился с объяснением большинства различий в своей статье Представляем 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, и сервером, обрабатывающим авторизацию пользователя. Дополнительная информация об этом подробно описана в вышеупомянутой статье.

Ответ 2

Я вижу большие ответы здесь, но то, что я пропустил, было некоторыми диаграммами, и поскольку мне пришлось работать с Spring Framework, я наткнулся на их объяснение.

Я нахожу следующие диаграммы очень полезными. Они иллюстрируют разницу в связях между сторонами с OAuth2 и OAuth1.

OAuth 2

OAuth 1

Ответ 3

Предыдущие объяснения являются чрезмерно подробными и сложными ИМО. Проще говоря, OAuth 2 делегирует безопасность протоколу HTTPS. OAuth 1 не требовал этого и, следовательно, имел альтернативные методы борьбы с различными атаками. Эти методы требовали приложения для участия в определенных протоколах безопасности, которые являются сложными и могут быть сложными в реализации. Поэтому проще просто полагаться на HTTPS для обеспечения безопасности, чтобы разработчикам приложений не нужно было об этом беспокоиться.

Что касается ваших других вопросов, ответ зависит. Некоторые службы не хотят требовать использования HTTPS, были разработаны до OAuth 2 или имеют какое-то другое требование, которое может помешать им использовать OAuth 2. Кроме того, было много споров о самом протоколе OAuth 2. Как видите, Facebook, Google и несколько других имеют несколько различные версии реализованных протоколов. Поэтому некоторые люди придерживаются OAuth 1, потому что они более однородны на разных платформах. Недавно протокол OAuth 2 был доработан, но нам еще предстоит выяснить, как его принятие будет принято.

Ответ 4

Обратите внимание, что существуют серьезные аргументы безопасности против использования Oauth 2:

одна мрачная статья

и более технический

Обратите внимание, что они исходят от ведущего автора Oauth 2.

Ключевые моменты:

• Oauth 2 не обеспечивает безопасности поверх SSL, в то время как Oauth 1 не зависит от транспорта.

• в некотором смысле SSL не является безопасным в том смысле, что сервер не проверяет соединение, а общие клиентские библиотеки позволяют легко игнорировать сбои.

  Проблема с SSL/TLS в том, что когда вы не можете проверить сертификат на стороне клиента, соединение все еще работает. Каждый раз, когда игнорирование ошибки приводит к успеху, разработчики собираются сделать это. Сервер не имеет возможности принудительно проверить сертификат, и даже если это возможно, злоумышленник, безусловно, не сможет.

• Вы можете отмахнуться от всей своей безопасности, что гораздо труднее сделать в OAuth 1.0:

  Вторая общая потенциальная проблема - опечатки. Считаете ли вы это правильным дизайном, если пропустить один символ ('в' https), что аннулирует полную безопасность токена? Или, возможно, отправка запроса (через действительное и проверенное соединение SSL/TLS) в неправильный пункт назначения (например, " http://gacebook.com?"). Помните, что возможность использовать OAuth-токены-носители из командной строки была явно продвинутой защитниками токенов-носителей.

Ответ 5

Безопасность протокола 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.

Ответ 6

Подписи OAuth 2.0 не требуются для фактических вызовов API после того, как маркер был сгенерирован. Он имеет только один токен безопасности.

OAuth 1.0 требует, чтобы клиент посылал два токена безопасности для каждого вызова API и использовал их для генерации подписи. Для подтверждения запроса требуется, чтобы конечные точки защищенных ресурсов имели доступ к учетным данным клиента.

Здесь описывается разница между OAuth 1.0 и 2.0 и как обе работают.

Ответ 7

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, вероятно, приведет к небезопасным реализациям.

Ответ 8

Если вы хотите увидеть краткое объяснение и подробный поток (с диаграммами) OAuth, вы можете проверить http://oauthbible.com

Ответ 9

OAuth 2.0 обещает упростить вещи следующими способами:

1. SSL необходим для всех сообщений, необходимых для генерации токена. Это огромное снижение сложности, потому что эти сложные подписи больше не требуются.
2. Подписи не требуются для реальных вызовов API после генерации токена - здесь также настоятельно рекомендуется использовать SSL.
3. После того, как токен был сгенерирован, OAuth 1.0 потребовал, чтобы клиент отправлял два токена безопасности на каждый вызов API, и использовал оба для генерации подписи. OAuth 2.0 имеет только один токен безопасности, и подпись не требуется.
4. Четко указано, какие части протокола реализованы "владельцем ресурса", который является фактическим сервером, реализующим API, и какие части могут быть реализованы отдельным "сервером авторизации". Это упростит для таких продуктов, как Apigee, поддержку OAuth 2.0 для существующих API.

Источник: http://blog.apigee.com/detail/oauth_differences

Ответ 10

Если вам нужно подробное объяснение, вам нужно прочитать обе спецификации:

https://oauth.net/core/1.0a/

https://oauth.net/2/

Если вам нужно четкое объяснение различий потоков, это может помочь вам:

OAuth 1.0 Flow

1. Клиентское приложение регистрируется у провайдера, такого как Twitter.
2. Twitter предоставляет клиенту "секрет потребителя", уникальный для этого приложения.
3. Клиентское приложение подписывает все запросы OAuth в Twitter со своим уникальным "секретом потребителя".
4. Если какой-либо из запросов OAuth искажен, отсутствует информация или неправильно подписан, запрос будет отклонен.

OAuth 2.0 Flow

1. Клиентское приложение регистрируется у провайдера, такого как Twitter.
2. Twitter предоставляет клиенту "секрет клиента", уникальный для этого приложения.
3. Клиентское приложение включает в себя "секрет клиента" с каждым запросом, обычно в виде заголовка http.
4. Если какой-либо из запросов OAuth искажен, отсутствует информация или содержит неверный секрет, запрос будет отклонен.

Источник: https://codiscope.com/oauth-2-0-vs-oauth-1-0/

Ответ 11

С точки зрения безопасности я бы пошел на OAuth 1. См. OAuth 2.0 и путь в ад

цитата из этой ссылки: "Если вы в настоящее время используете 1.0 успешно, игнорируйте 2.0. Он не предлагает реального значения более 1.0 (Im догадывается, что ваши разработчики уже уже определили 1.0 подписей).

Если вы новичок в этом пространстве и считаете себя экспертом по безопасности, используйте 2.0 после тщательного изучения его возможностей. Если вы не эксперт, используйте 1.0 или скопируйте версию 2.0 поставщика, которому вы доверяете, чтобы получить его право (документы API Facebooks - это хорошее место для начала). 2.0 лучше для больших масштабов, но если вы выполняете крупную операцию, у вас, вероятно, есть некоторые эксперты по безопасности на сайте, чтобы понять все это для вас ".