API Ключі проти аутентифікації HTTP проти OAuth в API RESTful


101

Я працюю над створенням RESTful API для одного із додатків, які підтримую. Зараз ми хочемо створити в ньому різні речі, які потребують більш контрольованого доступу та безпеки. Досліджуючи, як іти щодо забезпечення API, я знайшов кілька різних думок щодо того, яку форму використовувати. Я бачив, як деякі ресурси говорять про те, що HTTP-Auth - це шлях, в той час як інші віддають перевагу ключам API, а навіть інші (включаючи питання, які я знайшов тут на SO) присягаються OAuth.

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

Моє питання, таким чином, - якщо припустити, що все зроблено через HTTPS, які є практичні відмінності між цими трьома? Коли слід вважатись за інших?


з чим ти закінчився?
Ірвін

@Irwin - я задав це запитання досить давно і з тих пір перейшов від проекту, який вимагає цього, але я в кінцевому рахунку використовував комбінацію ключів API та згенерований пароль (якого користувачі ніколи не бачать), які надсилаються за допомогою аутентифікації HTTP.
Shauna

Відповіді:


67

Це залежить від ваших потреб. Вам потрібно:

  • Посвідчення особи - хто претендує на запит API?
  • Автентифікація - чи справді вони такі, про кого кажуть?
  • Дозвіл - чи їм дозволяється робити те, що вони намагаються зробити?

чи всі три?

Якщо вам просто потрібно ідентифікувати абонента, щоб відстежувати обсяг або кількість викликів API, скористайтеся простим ключем API. Майте на увазі, що якщо користувач, якому ви видали ключ API, ділиться ним з кимось іншим, він також зможе викликати ваш API.

Але якщо вам також потрібна авторизація, тобто вам потрібно надати доступ лише до певних ресурсів на основі абонента API, тоді використовуйте oAuth.

Ось хороший опис: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/


під "певними ресурсами" ви маєте на увазі "певні дзвінки api" чи "певні записи в базу даних", або обидва?
Магне

Переважно записи DB (або все, що розкриває захищений стан або змінює стан). Але це також може бути щось на кшталт преміум-функції (наприклад, запуск алгоритму на хмарі), який насправді нічого не змінює на db, але використовує системні ресурси та повинен бути доступний лише авторизованим особам.
Сид

@Sid Я працюю над додатком, який використовує OAuth для реєстрації користувачів, які реєструються у Facebook або LinkedIn. Крім того, ми відкриваємо наш API для інших служб для управління даними. У такому випадку ви б рекомендували OAuth для автентифікації користувача та ключ api або комбінацію імені користувача та пароля (як у статті, до якої ви посилаєтесь) для служб, що отримують доступ до API? Ключ OAuth та api використовуються для різних цілей, правда?
Том Доу

@TomDoe Привіт Том - Так, це має сенс. Ви, мабуть, хочете зараз використовувати OAuth2. Якщо ваш сервер знаходиться в Python (Django або Flask), подивіться на github.com/omab/python-social-auth
Sid

Я не розумію, як ключ API не може забезпечити ці три речі. Ідентифікація та автентифікація базуються на "чи знаєте ви конкретний секрет?" (якщо ви не введете 2FA, це окрема тема). Якщо я надаю користувачеві дуже довгий ключ API, це стверджує і доводить, що я Користувач 5, принаймні так само, як і ім’я користувача / пароль. І немає причини, чому не можна було призначити різні дозволи різним ключам API. Правильно? Що я тут пропускаю?
Натан Лонг

3

Ключі API або навіть токени відносяться до категорії прямих механізмів аутентифікації та авторизації, оскільки вони надають доступ до відкритих ресурсів API REST. Такі прямі механізми можуть бути використані у випадках делегування.

Для отримання доступу до ресурсу або набору ресурсів, що піддаються кінцевим точкам REST, необхідно перевірити права доступу запитувача відповідно до його ідентичності. Першим кроком робочого процесу є перевірка ідентичності за допомогою аутентифікації запиту; послідовним кроком є ​​перевірка ідентичності щодо набору визначених правил для дозволу рівня доступу (тобто читання, запис чи читання / запис). Після виконання зазначених етапів типовим подальшим занепокоєнням є дозволена швидкість запиту , що означає, скільки запитів в секунду запитувачеві дозволено виконувати до заданих ресурсів.

OAuth (Open Authorization) - це стандартний протокол делегованого доступу , який часто використовуються великими інтернет-компаніями для надання доступу без надання пароля. Як зрозуміло, OAuth є протоколом, який відповідає вищезгаданим проблемам: Аутентифікація та Авторизація, забезпечуючи безпечний делегований доступ до ресурсів сервера від імені власника ресурсу. Він заснований на механізмі токенів доступу, який дозволяє сторонній стороні отримати доступ до ресурсу, яким керує сервер від імені власника ресурсу. Наприклад, ServiceX хоче отримати доступ від акаунта Джона Сміта від імені Джона, після того, як Джон уповноважив делегацію; Тоді ServiceX видасть часовий маркер, щоб отримати доступ до даних облікового запису Google, імовірно, лише у режимі читання.

Поняття API Key дуже схоже на описаний вище OAuth Token. Основна відмінність полягає у відсутності делегування: Користувач безпосередньо запитує ключ до постачальника послуг для послідовних програмних взаємодій. Справа ключа API також залежить від часу: ключ як маркер OAuth підлягає оренді часу або терміну дії. Як додатковий аспект, як Ключ, так і Токен можуть бути обмежені тарифами за договором на обслуговування, тобто може бути надано лише задану кількість запитів в секунду.

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

  • Пряма автентифікація та авторизація : протоколи на основі ключів як варіант традиційних версій на основі облікових даних.
  • Делегована автентифікація та авторизація : як протоколи на основі OAuth, які, в свою чергу, використовують маркери, знову ж таки як варіант на основі облікових даних версій (загальна мета - не розкривати пароль жодній третій стороні).

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.