Чим OAuth 2 відрізняється від OAuth 1?

Чи дуже просто, чи може хтось пояснити різницю між OAuth 2 та OAuth 1?

Зараз OAuth 1 застарілий? Чи слід реалізовувати OAuth 2? Я не бачу багатьох реалізацій OAuth 2; Більшість досі використовують OAuth 1, що змушує мене сумніватися, що OAuth 2 готовий до використання. Є це?

Еран Хаммер-Лахав зробив чудову роботу, пояснивши більшість відмінностей у своїй статті Представлення OAuth 2.0 . Підводячи підсумок, ось основні відмінності:

Більше OAuth Flows для кращої підтримки програм, що не базуються на веб-переглядачах. Це основна критика проти OAuth з боку клієнтських додатків, які не базувалися на веб-переглядачах. Наприклад, в OAuth 1.0 настільні додатки або додатки для мобільних телефонів повинні були направити користувача на відкриття свого браузера до потрібної послуги, аутентифікацію з сервісом та копіювання маркера зі служби назад у програму. Основна критика тут проти користувальницької роботи. З OAuth 2.0 тепер є нові способи застосування програми отримати авторизацію для користувача.

OAuth 2.0 більше не вимагає, щоб клієнтські програми мали криптографію. Це чує повернення до старого API Auth Twitter, який не потребував програми до 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 Потік

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/

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 API Facebook - це гарне місце для початку). 2.0 краще для великих масштабів, але якщо ви проводите велику операцію, ви, мабуть, на місці є якісь експерти з безпеки, які розібраються у вас все ".