Чем OAuth 2 отличается от OAuth 1?
Проще говоря, кто-то может объяснить разницу между OAuth 2 и OAuth 1?
OAuth 1 устарел сейчас? Должна ли быть реализация OAuth 2? Я не вижу много реализаций OAuth 2; большинство все еще использует OAuth 1, что заставляет меня сомневаться в том, что OAuth 2 готов к использованию. Это?
10 ответов
Эран Хаммер-Лахав отлично справился с объяснением большинства различий в своей статье " Введение в 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 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.
[Апрель 14, 2016] Дополнение, чтобы прояснить мою точку зрения
Безопасность 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:
Обратите внимание, что это от ведущего автора Oauth 2.
Ключевые моменты:
Oauth 2 не обеспечивает безопасности поверх SSL, в то время как Oauth 1 не зависит от транспорта.
в некотором смысле SSL не является безопасным в том смысле, что сервер не проверяет соединение, а общие клиентские библиотеки позволяют легко игнорировать сбои.
Проблема с SSL/TLS состоит в том, что когда вы не можете проверить сертификат на стороне клиента, соединение все еще работает. Каждый раз, когда игнорирование ошибки приводит к успеху, разработчики собираются сделать это. На сервере нет способа принудительного подтверждения сертификата, и даже если это возможно, злоумышленник, безусловно, этого не сделает.
Вы можете отмахнуться от всей своей безопасности, что гораздо труднее сделать в OAuth 1.0:
Вторая распространенная потенциальная проблема - опечатки. Считаете ли вы это правильным дизайном, если пропустить один символ ('s' в 'https'), что аннулирует полную безопасность токена? Или, возможно, отправка запроса (через действительное и проверенное соединение SSL/TLS) в неправильный пункт назначения (например, " http://gacebook.com/"?). Помните, что возможность использовать OAuth-токены-носители из командной строки явно была продвинутой защитниками токенов-носителей.
Подписи 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 1.0 Flow
- Клиентское приложение регистрируется у провайдера, такого как Twitter.
- Twitter предоставляет клиенту "секрет потребителя", уникальный для этого приложения.
- Клиентское приложение подписывает все запросы OAuth в Twitter со своим уникальным "секретом пользователя".
- Если какой-либо из запросов OAuth искажен, отсутствует информация или неправильно подписан, запрос будет отклонен.
OAuth 2.0 Flow
- Клиентское приложение регистрируется у провайдера, такого как Twitter.
- Twitter предоставляет клиенту "секрет клиента", уникальный для этого приложения.
- Клиентское приложение включает в себя "секрет клиента" с каждым запросом.
- Если какой-либо из запросов OAuth искажен, отсутствует информация или содержит неверный секрет, запрос будет отклонен.
OAuth 2.0 обещает упростить вещи следующими способами:
- SSL необходим для всех соединений, необходимых для генерации токена. Это огромное снижение сложности, потому что эти сложные подписи больше не требуются.
- Подписи не требуются для реальных вызовов API после генерации токена - здесь также настоятельно рекомендуется использовать SSL.
- После того как токен был сгенерирован, OAuth 1.0 потребовал, чтобы клиент отправлял два токена безопасности на каждый вызов API, и использовал оба для генерации подписи. OAuth 2.0 имеет только один токен безопасности, и подпись не требуется.
- Четко указано, какие части протокола реализованы "владельцем ресурса", который является фактическим сервером, реализующим API, и какие части могут быть реализованы отдельным "сервером авторизации". Это упростит для таких продуктов, как Apigee, поддержку OAuth 2.0 для существующих API.
С точки зрения безопасности я бы выбрал OAuth 1. См. OAuth 2.0 и путь в ад
цитата из этой ссылки: "Если вы в настоящее время успешно используете 1.0, игнорируйте 2.0. Он не предлагает реальной стоимости более 1.0 (я думаю, ваши разработчики-клиенты уже разобрались в сигнатурах 1.0).
Если вы новичок в этой области и считаете себя экспертом по безопасности, используйте 2.0 после тщательного изучения его возможностей. Если вы не являетесь экспертом, либо используйте 1.0, либо скопируйте реализацию 2.0 поставщика, которому вы доверяете, чтобы сделать это правильно (документы API Facebook - хорошее место для начала). 2.0 лучше для крупномасштабных, но если вы выполняете крупную операцию, у вас, вероятно, есть несколько экспертов по безопасности, чтобы выяснить все это за вас ".