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

604

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

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

oauth oauth-2.0 authorization Sullivan
источник
Просьба уточнить; stackoverflow.com/questions/9565744/…
учащийся
Если вы хотите увидеть краткое объяснение и подробное описание (с диаграммами) OAuth, вы можете посетить oauthbible.com
Крис Исмаэль
Вы можете найти свой ответ здесь OAuth 2.0 - Обзор
Джон Джо

Ответы:

529

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

villecoder
источник
2
Может ли кто-нибудь уточнить, как URL обратного вызова отличаются между oauth 1 и 2?
Брайан Армстронг
2
OAuth 2.0 устареет только если OAuth утвержден в качестве RFC. В настоящее время это Интернет-проект, но планируется стать Интернет-стандартом (насколько это можно запланировать). Однако это займет годы, так как большая часть каркаса еще не указана. Вероятно, в ближайшие годы мы увидим целую семью интернет-черновиков, каждый из которых посвящен различным аспектам структуры авторизации OAuth 2.0. Чтобы понять, почему это так, посетите сайт tools.ietf.org/html/draft-ietf-oauth-v2 и найдите «за рамками данной спецификации»;)
Håvard Geithus,
48
Автор статьи в прошлом году написал продолжение под названием «OAuth 2.0 и Дорога в ад», с которым можно ознакомиться здесь: web.archive.org/web/20120731155632/http://hueniverse.com/2012/… Существенное различие между ними заключается в безопасности, о чем свидетельствует отсутствие криптографии в 2.0.
kdazzle
4
Безопасность OAuth 1.0 основывается на предположении, что секретный ключ, встроенный в клиентское приложение, может оставаться конфиденциальным, но это предположение наивно. В OAuth 2.0 такое наивное клиентское приложение называется конфиденциальным клиентом . Практически нет различий в уровне безопасности между клиентами OAuth 1.0 и конфиденциальными клиентами OAuth 2.0. «OAuth 2.0 и Дорога в Ад» упускает этот момент.
Такахико Кавасаки
6
@kdazzle, эта ссылка теперь переместилась сюда: hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529
e_i_pi
193

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

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

OAuth 2

введите описание изображения здесь

OAuth 1

введите описание изображения здесь

nyxz
источник
3
где "client_secret" используется в этом потоке ??
Ashwintastic
3
Если вы имеете в виду секрет, который вводит пользователь при перенаправлении на провайдера (например, Facebook, Twitter, Google и т. Д.), То это будет шаг 2 для OAuth 2и шаг 4 для OAuth 1.
nyxz
Почему на обеих диаграммах есть шаг поставщика услуг, который называется «Авторизация пользователя»? Это кажется задом наперед или неправильно. Разве «пользователь» не ищет авторизацию?
Forbin
@ Forbin Потому что этот шаг происходит на стороне поставщика услуг. Вы находитесь на их странице, где видите гранты, которые требуются от вас от службы, и вы должны согласиться предоставить эту информацию службе, для которой вы пытаетесь пройти аутентификацию. На самом деле у StackOverflow есть возможность войти в систему, используя учетную запись Google. Это работает так же. ТАК попросит Google просмотреть вашу электронную почту, и вы должны согласиться с этим.
nyxz
92

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

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

chacham15
источник
11
Итак, в основном OAuth2 работает с HTTPS и поэтому проще, чем OAuth1, который должен быть немного сложнее, поскольку он может работать без HTTPS?
Micro
@MicroR Это одно практическое определение, которое вы получили там! ;)
EralpB
36

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

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

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

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

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

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

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

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

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

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

djechlin
источник
4
аргумент «опечатка» не очень корректен - обычная практика - перенаправление с http на https
Олег Михеев
2
@OlegMikheev Да, но требуется только один http (no-s) запрос, чтобы MITM мог прослушивать ваши заголовки, и ваш токен теперь используется кем-то другим!
Патрик Джеймс МакДугл
3
если под заголовками вы подразумеваете куки, то они должны быть безопасными . Кроме того, я не вижу, как пользовательские опечатки (в URL браузера) могут выставлять токены, они даже не должны быть в заголовках
Олег Михеев
2
В качестве дополнительного аргумента против аргумента «опечатка» поставщик услуг может отклонить любые запросы OAuth 2.0, не поступившие через https, и отозвать токен доступа в этом запросе.
skeller88
32

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

Такахико Кавасаки
источник
7
Отправка секретов вместо подписей, будь то через HTTP, HTTPS и т. Д., Всегда несет неявную угрозу безопасности из-за MITM на уровне протокола. Теперь есть 2 способа найти секреты, а не только 1: получить root- права на устройство или подделать корневые сертификаты (раньше уже не получалось). Когда ваша модель безопасности «да, пусть транспорт ее обрабатывает», это правда, что она не будет менее защищенной, чем протокол. Но модели монолитной безопасности == одна точка входа для многих услуг. Это «достаточно хорошо» для прагматичных инженеров, но никогда не будет «таким безопасным», как альтернативная децентрализованная модель.
Марк Г.
23

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

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

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

Фиона Миллер
источник
22

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

Тони Книбб
источник
7
Обратите внимание, что ответы только на ссылки не приветствуются, ссылки со временем становятся устаревшими. Пожалуйста, рассмотрите возможность добавления отдельного краткого обзора здесь, сохраняя ссылку в качестве ссылки.
Клеопатра
6
Безопасность OAuth 1.0 основывается на предположении, что секретный ключ, встроенный в клиентское приложение, может оставаться конфиденциальным, но в случае приложений для смартфонов это наивно. В OAuth 2.0 такое наивное клиентское приложение называется конфиденциальным клиентом . Практически нет различий в уровне безопасности между клиентами OAuth 1.0 и конфиденциальными клиентами OAuth 2.0. «OAuth 2.0 и Дорога в Ад» упускает этот момент.
Такахико Кавасаки
15

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

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/

JRichardsz
источник
2
Не могли бы вы увидеть знаки жирным шрифтом? Возможно, функционал может иметь ту же концепцию, но, технически говоря, использовать простой заголовок (oauth2), чтобы подписать весь запрос совсем иначе . Обратите внимание и улучшите понимание прочитанного, прежде чем помечать ответы как бесполезные
JRichardsz
1
Пожалуйста, прочитайте свой собственный ответ и попытайтесь понять его. «Подписывает все запросы с секретом» и «отправляет секрет со всеми запросами». Никто в здравом уме не поймет разницу здесь, если он уже не использовал их. Я знаю разницу, но ОП нет. Этот ответ только запутает ОП и, следовательно, отрицательных голосов. Такие расплывчатые ответы заслуживают отрицательного ответа. Пожалуйста, прочитайте другие ответы здесь, которые являются более конкретными и информативными.
saran3h
12 разработчиков получили это. oauth1 и oauth2 имеют много различий. Предыдущие ответы охватывают их, и, как я уже сказал , вы можете прочитать этот oauth.net/core/1.0a или этот oauth.net/2, чтобы сделать свой собственный ответ. Моя цель - показать одно из самых известных технических отличий, когда разработчику необходимо разработать клиент для отдыха.
JRichardsz
7

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

Абхиджит Гайквад
источник
1

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

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

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

harmv
источник