Чем OAuth 2 отличается от OAuth 1?

Проще говоря, кто-то может объяснить разницу между 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 Auth, который не требовал приложения к хеш-токенам 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

OAuth 1

Предыдущие объяснения все слишком подробные и сложные ИМО. Проще говоря, 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:

  Вторая общая потенциальная проблема - опечатки. Считаете ли вы это правильным дизайном, если пропустить один символ ('s' в '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 может привести к небезопасным реализациям.

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

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/

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

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

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

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