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

Question

Проще говоря, кто-нибудь может объяснить разницу между OAuth 2 и OAuth 1?

OAuth 1 устарел сейчас? Должны ли мы реализовать OAuth 2? Я не вижу много реализаций OAuth 2; большинство все еще использует OAuth 1, что заставляет меня сомневаться, что OAuth 2 готов к использованию. Это так?

Answer 1

Эран Хаммер-Лахав отлично справился с объяснением большинства различий в своей статье Представляя OAuth 2.0 .Подводя итог, можно выделить следующие ключевые отличия:

Больше потоков OAuth для лучшей поддержки приложений, не основанных на браузере. Это основная критика OAuth от клиентских приложений, которые не были основаны на браузере.,Например, в OAuth 1.0 приложения для настольных компьютеров или приложения для мобильных телефонов должны были указывать пользователю открывать свой браузер для требуемой службы, проходить проверку подлинности с помощью службы и копировать токен из службы обратно в приложение.Основная критика здесь направлена ​​против пользовательского опыта.В OAuth 2.0 появились новые способы получения приложением авторизации для пользователя.

Для OAuth 2.0 больше не требуется, чтобы клиентские приложения имели криптографию. Это возвращает к старой аутентификации Twitter.API, который не требует применения к хэш-токенам HMAC и запросам строк.С OAuth 2.0 приложение может отправлять запросы, используя только выданный токен через HTTPS.

Подписи OAuth 2.0 намного менее сложны. Больше нет необходимости в специальном анализе, сортировке или кодировании.

Токены доступа OAuth 2.0 «недолговечны». Как правило, токены доступа OAuth 1.0 могут храниться в течение года или более (Twitter никогда не дает им истечь).OAuth 2.0 имеет понятие токенов обновления.Хотя я не совсем уверен, что это такое, я предполагаю, что ваши токены доступа могут быть недолговечными (т.е. основанными на сеансах), в то время как ваши токены обновления могут быть «временем жизни».Вы бы использовали токен обновления для получения нового токена доступа, а не для повторной авторизации вашего приложения пользователем.

Наконец, в OAuth 2.0 предусмотрено четкое разделение ролей между ответственным сервером.для обработки запросов OAuth и сервера, обрабатывающего авторизацию пользователя. Подробнее об этом подробно рассказано в вышеупомянутой статье.

Answer 2

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

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

---

OAuth 2

---

OAuth 1

Answer 3

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

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

Answer 4

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

одно унылое изделие

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

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

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

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

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

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

• вы можете убрать всю вашу безопасность, что гораздо труднее сделать в OAuth 1.0:

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

Answer 5

Безопасность протокола OAuth 1.0 ( RFC 5849 ) основывается на предположении, что секретный ключ, встроенный в клиентское приложение, может оставаться конфиденциальным. Однако предположение наивно.

В OAuth 2.0 ( RFC 6749 ) такое наивное клиентское приложение называется конфиденциальным клиентом. С другой стороны, клиентское приложение в среде, в которой трудно сохранить секретный ключ конфиденциальным, называется public клиентом. См. 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.

---

^{[14 апреля 2016 года] Дополнение, чтобы прояснить мою точку зрения}

Безопасность OAuth 1.0 основана на вычислении подписи. Сигнатура вычисляется с использованием секретного ключа, где секретный ключ является общим ключом для HMAC-SHA1 ( RFC 5849, 3.4.2 ) или личным ключом для RSA-SHA1 ( RFC 5849, 3.4 0,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.

Answer 6

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

Answer 7

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

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

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

Answer 8

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

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

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

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

Answer 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

Answer 10

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

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

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