OAuth2 ROPC vs Basic Auth для загальнодоступних API REST?

Мене тут цікавить конкретний випадок використання - автентифікація REST-клієнтів щодо загальнодоступних кінцевих точок сервера (наприклад, загальнодоступного API REST).

Тут найпростіше рішення - Basic Auth . Але я часто чую, як OAuth2 рекламується як найкраще рішення щодо автентичності майже за будь-яких обставин.

Річ у тому, що єдиний тип грантів OAuth2, який можливий для клієнта REST, що підтверджує автентичність на сервері REST, - це ідентифікаційні дані власників ресурсів (ROPC) , оскільки для кодових грантів та неявних грантів потрібен інтерфейс користувача / веб-сторінка (розміщена сервером Auth Server) для користувач, щоб увійти та вручну авторизувати клієнтську програму.

Як працює ROPC, надсилаючи ім’я / пароль власника ресурсу та ідентифікатор клієнта як параметри рядка запиту ?!? Це ще менш безпечно (IMHO), ніж Basic Auth, який принаймні base-64 кодує облікові дані та надсилає їх всередину заголовка, який може бути зашифрований TLS!

Тож я запитую: чи в контексті загальнодоступних API REST, OAuth2 ROPC справді кращий, ніж Basic Auth? Що безпечніше, ніж OAuth2 ROPC?

Оновлення

Я просто прочитав цю чудову статтю, в якій пояснюється безпека REST, заснована на OAuth2 для AWS. По суті, це рішення, засноване на приватному ключі, де геши кожного запиту REST генеруються та надсилаються у якості бічних колів поряд із звичайним (незашифрованим) запитом. Тільки клієнт і сервер знають приватний ключ, тому коли сервер отримує запит (знову ж таки, містить звичайний запит + хешований запит), сервер шукає приватний ключ клієнта, застосовує той самий хеш до звичайного запиту, і потім порівнює два хеші.

Це звучить набагато складніше, складніше та безпечніше, ніж ROPC OAuth2! Якщо я пропускаю щось головне тут, OAuth2 ROPC просто надсилає client_id, usernameі passwordяк параметр рядків запитів ... цілком і зовсім незахищено! Це рішення на основі HMAC / хешів здається набагато більш вражаючим та безпечним.

Річ у тому, що навіть автор цієї статті продовжує говорити:

Ви [також] повільно зрозумієте і приймете, що в якийсь момент вам доведеться реалізувати OAuth ...

Ба-ба-біт?!?! Якщо OAuth2 менш безпечний, ніж це розумне рішення на основі HMAC / хешу, чому автор цієї статті вважає, що OAuth потрібно прийняти в якийсь момент. Я так розгубився.

Відповідь на ваше запитання може бути на рівні коду, рівня протоколу чи архітектури. Я спробую узагальнити тут більшість питань рівня протоколу, оскільки це, як правило, критично важливо для аналізу плюсів і мінусів. Майте на увазі, що OAuth2 - це набагато більше, ніж ідентифікаційні дані пароля власника ресурсу, які відповідно до специфікації існують з "застарілих або міграційних причин", вважаються "вищими ризиками, ніж інші типи грантів", а в специфікації прямо зазначено, що клієнти та сервери авторизації "ДОЛЖЕ мінімізувати використання цього типу грантів та використовувати інші типи грантів, коли це можливо".

Є ще багато переваг використання ROPC над базовою аутентифікацією, але, перш ніж ми переходимо до цього, давайте розберемось у базовій різниці протоколу між OAuth2 та базовою автентифікацією. Будь ласка, поводьтеся зі мною, коли я пояснюю це, і пізніше прийду до ROPC.

Протікає автентифікація користувача

У специфікації OAuth2 визначено чотири ролі. З прикладами вони:

1. Власник ресурсу: Користувач, який має доступ до якогось ресурсу, наприклад у вашому випадку, різні користувачі можуть мати різний рівень доступу до API REST;
2. Клієнт: зазвичай програма, яку користувач використовує, і потребує доступу до ресурсу для надання послуг користувачеві;
3. Сервер ресурсів: API REST у вашому випадку; і
4. Сервер авторизації: сервер, якому представлені облікові дані користувача і який буде аутентифікувати користувача.

Коли клієнтська програма запускається, їй надається доступ до ресурсів на основі користувача. Якщо користувач має права адміністратора, ресурси та операції, доступні користувачеві в API REST, можуть бути набагато більше, ніж у користувача без прав адміністратора.

OAuth2 також дозволяє використовувати один сервер авторизації з декількома клієнтами та для кількох ресурсів. Як приклад, сервер ресурсів може прийняти автентифікацію користувача з Facebook (що може діяти як сервер авторизації в такому випадку). Отже, коли користувач запускає додаток (тобто клієнт), він відправляє користувача у Facebook. Користувач вводить свої облікові дані у Facebook, і клієнт отримує назад "маркер", який він може представити серверу ресурсів. Сервер ресурсів розглядає маркер і приймає його після того, як перевірив, що Facebook насправді видав його та дозволив користувачеві отримати доступ до ресурсу. У цьому випадку клієнт ніколи не бачить облікових даних користувачів (тобто своїх облікових даних Facebook).

Скажімо, ви керуєте особами свого користувача (і маєте сервер авторизації) замість Facebook, який надає жетони вашому клієнту. Скажімо, у вас також є партнер, і ви хочете дозволити їхній програмі (тобто клієнту) отримати доступ до вашого REST API. За допомогою базової аутентифікації (або навіть ROPC) користувач надасть облікові дані тому клієнту, який надішле його на сервер авторизації. Сервер авторизації надасть токен, який клієнт може використовувати для доступу до ресурсів. На жаль, це означає, що дані клієнта тепер бачні і для цього клієнта. Однак ви не хочете, щоб заявка партнера (який може бути зовнішньою для вашої організації) навіть знала пароль користувача. Це питання безпеки зараз. Щоб досягти цієї мети,

Таким чином, з OAuth2 ідеально не використовувати ROPC у таких випадках, а використовувати інший, такий як потік коду авторизації. Це захищає будь-яку програму від того, щоб знати облікові дані користувача, які представлені лише серверу авторизації. Таким чином, облікові дані користувачів не протікають. Ці ж питання стосуються базової автентифікації, але в наступному розділі я поясню, як ROPC все ще краще, оскільки облікові дані користувача все ще не потрібно зберігати клієнтом у ROPC для постійного доступу клієнтів.

Зауважте, що коли користувач переходить на сервер авторизації, сервер авторизації також може попросити користувача підтвердити, що він хоче дозволити клієнту отримати доступ до ресурсів від свого імені чи ні. Ось чому його називають сервером авторизації, тому що процес авторизації клієнта на доступ до ресурсів пов'язаний з цим процесом. Якщо користувач не уповноважує клієнта, він не отримає доступ до ресурсів. Так само, якщо сам користувач не має доступу до ресурсів, сервер авторизації все ще може заборонити доступ і не видавати маркер.

У базовій аутентифікації навіть сервер авторизації та сервер ресурсів об'єднані в одне ціле. Таким чином, сервер ресурсів хоче авторизувати користувача, тому запитує облікові дані клієнта. Клієнт надає ті облікові дані, які сервер ресурсів використовує для аутентифікації користувача. Це означає, що кілька серверів ресурсів по суті вимагатимуть облікові дані від користувача.

Видача токенів

Клієнти отримують жетони з сервера авторизації, зберігають їх та використовують їх для доступу до ресурсів (детальніше про самі жетони нижче). Клієнти ніколи не знають пароль користувача (у потоках, відмінних від ROPC) і не потребують його зберігання. У ROPC, незважаючи на те, що клієнти знають пароль користувача, їм все одно не потрібно зберігати його, оскільки вони використовують маркери для доступу до ресурсів. На противагу цьому, у випадку базової автентифікації, якщо клієнт не хоче мати користувача для надання облікових даних у кожному сеансі, тоді клієнт повинен зберігати пароль користувача, щоб він міг подати його наступного разу. Це є головним недоліком використання базової аутентифікації, якщо клієнт не є лише веб-додатком. У цьому випадку кукі-файли можуть вирішити деякі з цих проблем. З рідними програмами це зазвичай не варіант.

Є ще один аспект OAuth2, який полягає в тому, як видаються маркери та вони працюють. Коли користувач надає облікові дані серверу авторизації (навіть у ROPC), сервер авторизації може надати один або більше з двох типів лексем: 1) маркер доступу та 2) оновити маркер.

Токени доступу надсилаються на сервер ресурсів, який надасть доступ до ресурсів після перевірки, і зазвичай вони мають короткий термін служби, наприклад, 1 год. Токени оновлення відправляються клієнтом на сервер авторизації, щоб отримати ще один маркер доступу, коли термін його дії закінчується, і зазвичай мають великий термін експлуатації (наприклад, кілька днів, місяців або навіть років).

Коли клієнт надає маркер доступу до сервера ресурсів, він переглядає маркер і після перевірки перевіряє всередині маркера, щоб визначити, чи дозволяти доступ чи ні. Поки маркер доступу дійсний, клієнт може продовжувати його використовувати. Скажімо, користувач закриває програму та запускає її наступного дня, а маркер доступу закінчується. Тепер клієнт здійснить дзвінок на сервер авторизації та подасть маркер оновлення, припустивши, що термін його дії не закінчився. Сервер авторизації, оскільки він вже видав маркер, перевіряє його і може визначити, що користувачеві не потрібно надавати облікові дані ще раз, і таким чином надає клієнту ще один маркер доступу. Тепер клієнт знову має доступ до ресурсного сервера. Ось як зазвичай клієнтські програми для Facebook та Twitter запитують облікові дані один раз, а потім не вимагають від користувача знову надавати облікові дані. Ці програми ніколи не повинні знати облікові дані користувачів, але вони можуть отримувати доступ до ресурсів кожного разу, коли користувач запускає програму.

Тепер користувач може зайти на сервер авторизації (наприклад, у своєму профілі користувача Facebook), змінити пароль, не впливаючи на жодні клієнтські програми. Всі вони продовжуватимуть працювати належним чином. Якщо користувач втрачає пристрій, на якому у нього вже була програма з маркерами оновлення, він може сказати серверу авторизації (наприклад, Facebook), щоб "вийти з системи" тих програм, які сервер авторизації (тобто Facebook) виконає, не шануючи жодного існуючого оновіть маркери та змушуйте користувача знову надавати облікові дані, коли він намагається отримати доступ до ресурсів через ці програми.

JWT - це просто формат маркера, який зазвичай використовується з OAuth2 та OpenID Connect. Методи підписання маркера та перевірки його також стандартизовані з бібліотеками, доступними для тих, замість кожного сервера ресурсів, що реалізує ще одне рішення. Таким чином, перевага полягає в повторному використанні коду, який був перевірений і продовжує підтримуватися.

Наслідки для безпеки

Базова аутентифікація буде слабшою, коли будь-який із перерахованих вище сценаріїв зображений на зображенні. Існує також обширна модель загроз для OAuth2, доступна для розробників, які можуть використовувати в ній пропозиції, щоб уникнути поширених уразливостей у своїх реалізаціях. Якщо ви перейдете через модель загрози, ви побачите, що в ній також охоплено багато вразливих місць щодо впровадження (наприклад, відкритий переспрямовувач та CSRF). У цій відповіді я не пройшов порівняння тих, хто проти базової аутентифікації.

Остання основна перевага OAuth2 полягає в тому, що протокол є стандартизованим і багато серверів авторизації, клієнти та сервери ресурсів його шанують. Розробникам доступні численні бібліотеки, які підтримуються таким чином, як проблеми з безпекою виявляються в реалізаціях, бібліотеки оновлюються, забезпечуючи взаємодію.

Висновок

Якщо ви пишете нову заявку IMO, ідеальним випадком буде уникнути як базової автентифікації, так і ROPC через проблеми, які їм притаманні. Однак у кожної програми є різні потреби, терміни, знання розробника тощо, тому рішення у кожному конкретному випадку. Але навіть якщо у вас не було більше необхідності, ніж основна автентифікація, вибравши її, ви можете зафіксувати себе в архітектурі, яку може бути непросто розширити (наприклад, якщо у вас є кілька серверів у майбутньому, ви не обов'язково хочете мати користувач надає облікові дані для кожного з них, а просто надає сервер авторизації один раз, який може роздавати жетони тощо)

Зауважте, що я не звертався до Вашого коментаря щодо того, як дані облікових даних надсилаються через провід, оскільки їх можна захистити за допомогою TLS або аналогічного протоколу, або підтвердження володіння тощо. Як хтось уже запропонував, кодування базової 64 - це 0 безпека, будь ласка, не обманюється тим. Вищезгадані відмінності зазвичай знаходяться на архітектурному рівні, і тому саме там я зосередився, тому що архітектуру найважче змінити після її впровадження.

Azure Active Directory B2C Basic , послуга, над якою я працюю і нещодавно була випущена для загального попереднього перегляду, дозволяє сторонній програмі використовувати AAD як сервер авторизації з інтероперабельністю із соціальними ВПО (такими як Facebook, Google тощо). Він також дозволяє користувачам створювати власні облікові записи замість використання соціальних переселенців, і пізніше їх можна використовувати для цілей аутентифікації. Є ще кілька подібних служб (наприклад, ще одна, про яку я знаю, - це auth0), які можуть бути використані розробниками для повного передачі аутентифікації та керування користувачами для своїх додатків та ресурсів. Ті ж характеристики протоколів, про які я згадував вище, розробники використовують для роз'єднання сервера авторизації (AAD), ресурсу (наприклад, їх API REST), клієнта (наприклад, їх мобільних додатків) та користувачів. Сподіваюся, це пояснення дещо допомагає.

Я вважаю, що ви неправильно поінформовані про шифрування навколо GET-змінних в URL-адресі

Єдині люди, які можуть переглядати змінні GET у запиті - це оригінальний комп'ютер та сервер отримання ( посилання ).

Тільки пошук DNS на основі домену, на який надсилається запит HTTPS, не шифрується. Все інше, порти, змінні GET, ідентифікатор ресурсу, шифруються.

Єдине застереження до цього полягає в тому, що сервер, що приймає, може вийти з повного шляху запиту, але ви керуєте цим, щоб ви могли захистити ці дані, як не вважаєте за потрібне.

Базова аутентифікація не є хорошим способом захистити свій REST API. Я пояснив причини, чому в цій відповіді .

Створюючи API REST, ви реалізуєте сервер ресурсів в умовах OAuth2. Все, що вам потрібно зробити, це підтвердити, що маркер, переданий разом із запитом у заголовку HTTP авторизації, є дійсним та отриманий від надійного емітента. Перегляньте це посилання, щоб дізнатися, як виконати перевірку, якщо немає бібліотеки.

Те, як ваш клієнт отримує маркер на сервері авторизації, залежить від типу клієнта . Пам'ятайте, що вам потрібно вказати тип клієнта, який ви будете використовувати при реєстрації клієнта на сервері авторизації.

У випадку, коли веб-додаток розмовляє з вашим сервером, воно може використовувати надання авторизаційного коду . Якщо це ненадійний клієнт, наприклад мобільний додаток або додаток JavaScript, він повинен використовувати неявний грант .

Для серверних послуг , які не можете взаємодіяти з власником ресурсу, ви можете використовувати облікові дані клієнта надати . Для інструментів командного рядка ви можете використовувати або облікові дані клієнта, або надання власника ресурсу пароля .

Все залежить від того, якого клієнта ви використовуєте.

Нарешті, перевірка маркера JWT відбувається на сервері ресурсів без необхідності спілкуватися з сервером авторизації. Це призводить до кращої масштабованої архітектури, а потім до рішень, які потребують пошуку приватних даних для кожного клієнта.

Це або безпечно, або незахищено. Ні більше, ні менше. Наявність base64 не робить Basic Auth (чи що-небудь) більш захищеним.

Немає нічого поганого в надсиланні нічого незашифрованого, якщо він використовує зашифровану трубу, як Https.

OAuth має більше функцій, використовуйте його, якщо вам це потрібно. Для всього іншого, наприклад, для банківської справи, використання базового реагування на виклики є чудовим та безпечним.

Я думаю, що вам потрібно спочатку розібратися в термінології. Ви порівнюєте - Авторизація та Цифровий підпис

OAuth є відкритим стандартом для авторизації , де, як те, що робить Amazon (відповідно до статті та деталей, наданих у вашому запитанні), створює дійсний цифровий підпис, який дає одержувачу (тут Amazon) підстави вважати, що повідомлення створене відомим відправник, що відправник не може відмовити в надсиланні повідомлення ( автентифікація та невідхилення)

Який механізм авторизації використовувати, він більш-менш залежить від вашого випадку використання.

Нижче наведено, що можна знайти на StackOverflow тут :

Основна автентифікація, яка вимагає дуже простого хешування для обчислення одного необхідного заголовка - OAuth, без сумніву, є більш дорогою аутентифікацією. Важливо усвідомити, що два механізми аутентифікації служать абсолютно різним цілям. Basic Auth - це автентифікація клієнта в основній програмі. OAuth - це дозвіл третьої сторони отримати доступ до даних клієнта з первинної програми. Обидва мають своє місце, і вибір одного за іншим повинен визначатися конкретним випадком використання цього варіанта.

І ось ще одна цікава стаття, яка порівнює дві.

Базова аутентифікація на SSL насправді є досить відповідальною з точки зору спрощеної безпеки. Коли ми змагаємося з іменами користувачів та паролями, Basic auth є поширеним рішенням, оскільки це так просто реалізувати. Передача облікових даних шифрується через SSL, а використання заголовка "Авторизація" є всюдисущим у клієнтах та системах HTTP.