Безпека API REST Зберігається маркер проти JWT проти OAuth

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

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

Дозвольте розповісти, як я розумію все це. Якщо я щось неправильно розумію, будь ласка, повідомте мене про це.

Наскільки REST API не має статусу, а також WEB взагалі, нам потрібно надсилати деякі дані про автентифікацію в кожному запиті (cookie, маркер ....). Я знаю три широко використовувані механізми для аутентифікації користувача

1. Токен з HTTPS. Я використовував такий підхід багато разів, він досить хороший з HTTPS. Якщо користувач надає правильний пароль та логін, він отримає маркер у відповідь та використовуватиме його для подальших запитів. Токен генерується сервером і зберігається, наприклад, в окремій таблиці або там же, де зберігається інформація про користувача. Отже, для кожного сервера запитів перевіряється, чи користувач має маркер, і він такий, як у базі даних. Все досить просто.

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

3. OAuth 2. Я не розумію, чому цей підхід слід використовувати, коли зв'язок встановлюється безпосередньо між сервером і клієнтом. Наскільки я розумію, сервер OAuth використовується для видачі маркера з обмеженою сферою, щоб інші програми могли отримувати доступ до інформації користувача без збереження пароля та входу. Це відмінне рішення для соціальних мереж, коли користувач хоче зареєструватися на якійсь сторінці, сервер може вимагати дозволу на отримання інформації про користувача, наприклад, з твіттера або facebook, а також заповнення реєстраційних полів даними користувачів тощо.

Розглянемо мобільний клієнт для інтернет-магазину.

Перше питання, чи слід віддати перевагу JWT над маркером першого типу? Наскільки мені потрібен користувач для входу / виходу на мобільному клієнті, мені потрібно десь зберігати маркер або у випадку JWT, маркер повинен бути недійсним під час виходу. Для визнання недійсним токеном одного із значень використовуються різні підходи для створення недійсного списку токенів (чорний список). Хм. Таблиця / файл матиме набагато більший розмір, ніж якби маркер зберігався в таблиці та асоціювався з користувачем, а просто видалявся під час виходу.

То які переваги JWT-токена?

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

Розглянемо перший випадок. Кожен клієнт отримує випадковий ідентифікатор, який триває протягом сеансу - який може бути декілька днів, якщо ви хочете. Потім ви зберігаєте інформацію, що стосується цього сеансу, десь на стороні сервера. Це може бути у файлі чи базі даних. Припустимо, ви передаєте ідентифікатор за допомогою файлу cookie, але ви можете використовувати URL-адресу або HTTP-заголовок.

Сеанси ідентифікаторів / файлів cookie

Плюси:

• Легко кодувати і клієнта, і сервера.
• Легко знищити сеанс, коли хтось виходить із системи.

Мінуси:

• Сторона сервера періодично потребує видалення закінчених сеансів, коли клієнт не виходив з системи.
• Кожен запит HTTP вимагає пошуку у сховищі даних.
• Потреби в пам’яті зростають, оскільки все більше користувачів мають активні сеанси.
• Якщо є кілька HTTP-серверів на передньому кінці, збережені дані сеансу повинні бути доступними для всіх. Це може бути трохи більше роботи, ніж зберігання на одному сервері. Більші проблеми полягають у тому, що сховище даних стає єдиною точкою відмови, і це може стати вузьким місцем.

Веб-маркери JSON (JWT)

У другому випадку дані зберігаються в JWT, який передається навколо, а не на сервері.

Плюси:

• Проблем із зберіганням сервера немає.
• Клієнтський код легко.

Мінуси:

• Розмір JWT може бути більшим, ніж ідентифікатор сеансу. Це може вплинути на продуктивність мережі, оскільки вона включена в кожен запит HTTP.
• Дані, що зберігаються в JWT, читаються клієнтом. Це може бути проблемою.

• Сторінка сервера потребує коду для генерації, перевірки та зчитування JWT. Це не важко, але є трохи кривої навчання і від цього залежить безпека.

  Кожен, хто отримає копію ключа підпису, може створити JWT. Ви можете не знати, коли це станеться.

  У деяких бібліотеках була (є?) Помилка, яка приймала будь-який JWT, підписаний алгоритмом "none", щоб кожен міг створити JWT, яким сервер буде довіряти.

• Щоб скасувати JWT до його закінчення, вам потрібно скористатися списком відкликань. Це поверне вас до проблем із зберіганням на сервері, яких ви намагалися уникнути.

OAuth

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

Плюси:

• Немає коду, щоб користувачі могли зареєструватися або скинути свій пароль.
• Немає коду, щоб надіслати електронний лист із посиланням на підтвердження, а потім підтвердити адресу.
• Користувачам не потрібно вивчати / записувати інше ім’я користувача та пароль.

Мінуси:

• Ви залежаєте від третьої сторони для того, щоб ваші користувачі могли використовувати вашу послугу. Якщо їхня послуга знижується або вони припиняють її, то вам потрібно розібратися в чомусь іншому. Наприклад: як ви переміщуєте дані облікового запису користувача, якщо їх особистість змінюється з "foo@a.com" на "bar@b.com"?
• Зазвичай вам потрібно написати код для кожного провайдера. наприклад, Google, Facebook, Twitter.
• Ви або ваші користувачі можуть мати проблеми з конфіденційністю. Постачальники знають, хто з їх користувачів використовує вашу послугу.
• Ви довіряєте провайдеру. Можливо, постачальник може видавати жетони, які дійсні для одного користувача, іншому. Це може бути в законних цілях чи ні.

Різне

• Ідентифікатори сеансу, і JWT можуть бути скопійовані та використані кількома користувачами. Ви можете зберігати IP-адресу клієнта в JWT та перевіряти його, але це заважає клієнтам роумінгу від скажімо Wi-Fi до стільникового зв'язку.

Запитайте себе, чому потрібно визнати недійсним оригінальний маркер.

Користувач входить у систему, генерується маркер і вимикається додаток.

Користувач натискає вихід, новий маркер формується і замінює початковий маркер. Ще раз все добре.

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

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

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

В іншому випадку, я думаю, вам знадобиться мати інформацію про стан на сервері. Не маркуйте чорний список, а натомість додайте в білий список підпису поточного маркера.

Ви можете вирішити згадані вами проблеми JWT, зберігаючи значення солі разом із користувачем та використовуючи сіль як частину маркера для користувача. Тоді, коли вам потрібно визнати маркер недійсним, просто поміняйте сіль.

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