Автентифікація REST API: 9 перевірених методів

https://josipmisko.com/posts/rest-api-authentication

By Josip Miskovic•Feb 4, 2023

Автентифікація є одним із ключових компонентів найкращих практик REST API.

Ніхто не хоче, щоб їхні API були зламані.

Але як знайти баланс між безпекою, простотою та досвідом розробника?

У цій статті дізнайтеся, який метод є найкращим для вашої автентифікації REST API.

Є 9 основних підходів до автентифікації в REST APIs:

1. Basic Authentication

Базова автентифікація HTTP — це простий метод автентифікації за допомогою стандартного заголовка HTTP. Це передбачає надсилання ім’я користувача та пароля, закодованих за допомогою Base64, у заголовку «Authorization».

Облікові дані базової автентифікації слід надсилати лише через зашифроване з’єднання. Якщо використовувати в незашифрованих мережах, кожен може легко декодувати рядок base64. Отже, використання каналів Secure Sockets Layer (SSL) і Transport Layer Security (TLS) є обов’язковим під час використання базової автентифікації.

IETF чітко визначив Basic Auth в RFC 7617.

2. Bearer Token

Маркер носія (Bearer token) — це стандартний спосіб передачі маркерів в API для автентифікації, визначений RFC 6750. Він широко застосовується для автентифікації на основі маркерів і використовується шляхом включення маркера в заголовок авторизації без додаткового кодування. Якщо у вас є маркер носія, вам не потрібні додаткові докази автентифікації.

Bearer tokens - це лише спосіб надсилання маркерів?

Так, маркери-носії — це скоріше метод транспортування, ніж метод автентифікації. Як ви отримуєте маркер – це окрема історія. Вони стали популярними завдяки OAuth, але з тих пір їх використовують для різних випадків використання. Наприклад, маркери приватного доступу (PAT). Ось приклад з API Atlassian:

Atlassian використовує метод Bearer Token, приклад формату Bearer Token PAT:

Authorization: Bearer QDAmQ9TStkDCpVK5A9kFowtYn2k

3. API Keys

Підхід автентифікації API Key використовує комбінацію ключ-значення. Ключі API можна надіслати як частину запиту:

• payload,
• заголовки HTTP, або
• рядок запиту.

API Cloudflare використовує спеціальний заголовок HTTP для прийняття ключа API. За потреби сервер може викликати облікові дані та маркери. Наприклад, якщо рівень дозволу користувача змінюється або якщо клієнт зламав ключ. Ключі API чутливі до тих самих ризиків, що й базова автентифікація, оскільки вони не мають терміну дії. Якщо хтось їх вкраде, єдине, що ви можете зробити, це відкликати їх.

4. Cookies

Сеансові файли cookie є загальною реалізацією автентифікації на основі маркерів.

1. Кінцева точка входу повертає заголовок “Set-Cookie” у відповідь, яка вказує клієнту API зберегти маркер сеансу.
2. Подальші запити включають маркер як заголовок “Cookie”.
3. Сервер отримує файл cookie клієнта та шукає маркер cookie для ідентифікації користувача.

Великою перевагою файлів cookie є атрибут безпеки «Secure». Файли cookie пов’язані з доменом і можуть бути позначені як «Secure», щоб запобігти випадковому надсиланню через з’єднання без HTTPS.

Чи є файли cookie RESTful?

Використання файлів cookie в RESTful API може порушувати принцип відсутності стану, але якщо вони використовуються виключно для автентифікації API, вони допустимі.

Openware REST API supports cookie authnetication

5. OAuth 2.0

OAuth 2.0 вважається золотим стандартом, коли йдеться про автентифікацію REST API, особливо в корпоративних сценаріях із складними веб-програмами та мобільними додатками.

PayPal example of OAuth 2.0

Переваги терміну дії

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

Більше ніж автентифікація

OAuth — це не лише автентифікація, а й авторизація. OAuth підтримує концепцію областей, метод обмеження доступу програми до облікового запису користувача та пов’язаних облікових даних. OAuth 2.0 може підтримувати динамічні колекції користувачів, рівнів дозволів, параметрів області та типів даних.

JWT

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

OAuth History

OAuth був вперше розроблений у 2006 році Блейном Куком, Крісом Месіною та Ларрі Халффом. Вони шукали спосіб дозволити користувачам OpenID авторизуватися для доступу до їхнього сервісу. У результаті їхніх зусиль зі стандартизації процесу вони сформували дискусійну групу в 2007 році. Остаточний проект OAuth Core 1.0 був опублікований у грудні того ж року. Незабаром після цього Девітт Клінтон з Google приєднався до цих зусиль, і вони відшліфували RFC у квітні 2010 року. Відтоді всі сторонні програми Twitter повинні використовувати OAuth. Протокол оновлювався протягом багатьох років, а OAuth 2.0 було опубліковано як RFC стандартів у жовтні 2012 року.

6. OpenID Connect

OpenID Connect — це рівень ідентифікації, створений на основі протоколу OAuth 2.0. Він забезпечує стандарт автентифікації та дозволяє користувачам автентифікуватися у веб-програмі за допомогою наявного облікового запису з іншого сайту, наприклад Google, Facebook або GitHub. Якщо ваш REST API вимагає безпечної передачі даних користувача між кількома сторонніми веб-додатками, OpenID Connect — це найпростіший спосіб зробити це.

7. Взаємний TLS (mTLS)

Взаємна автентифікація TLS — це двосторонній процес автентифікації між клієнтом і сервером. І клієнт, і сервер повинні надати сертифікати X.509, щоб підтвердити свою ідентичність.

Приклад від Microsoft використання mTLS для захисту мікросервісів.

Взаємний TLS зазвичай використовується для Інтернету речей (IoT) і додатків «бізнес-бізнес». Взаємна автентифікація вимагає, щоб і клієнт, і сервер автентифікувалися один перед одним за допомогою рукостискання SSL/TLS з обміном сертифікатами та перевіркою. Авторизація обробляється окремо від процесу автентифікації.

8. Обмеження доступу на базі IP-адреси

Обмеження доступу на базі IP-адреси – це метод автентифікації REST API. Він обмежує доступ до API на основі IP-адреси клієнта, який робить запит. Ви підтримуєте список дозволених IP-адрес, і API приймає запити лише з цих IP-адрес. Якщо запит зроблено з IP-адреси, якої немає в списку дозволених, API може повернути відповідь 401 Unauthorized або будь-який інший відповідний код помилки HTTP. Обмеження IP-доступу – це простий і ефективний спосіб захисту API, які не мають надто багато споживачів. Наприклад, B2B API або внутрішні системи. Майте на увазі, що обмеження IP-доступу може бути складним, якщо клієнт, який робить запит, знаходиться за проксі-сервером або балансувальником навантаження.

9. HTTP Digest

HTTP-дайджест — це схема автентифікації, яка підтримується HTTP, яка надсилає підсолений хеш пароля замість необробленого значення. Великим недоліком цього методу є алгоритм хешування. HTTP Digest використовує MD5, який зараз вважається небезпечним. Зробіть собі послугу та уникайте використання автентифікації HTTP Digest у нових програмах. Автентифікація доступу HTTP Digest була представлена в 1997 році як частина RFC2069.

FAQ: REST API Authentication

Що таке автентифікація на основі маркерів?

Аутентифікація на основі маркерів – це метод, який складається з кількох кроків:

1. клієнт робить запит до кінцевої точки входу з обліковими даними користувача
2. клієнт отримує маркер з обмеженим часом
3. потім клієнт надсилає цей маркер як частину запитів іншим кінцевим точкам API
4. кожна кінцева точка API перевіряє маркер, звіряючи його з базою даних маркерів

Що таке JWT?

JWT – це тип маркера безпеки, який забезпечує спосіб безпечного зберігання та передачі інформації. Він складаються з двох частин:

1. об’єкт JSON, який містить заяви про користувача,
2. заголовок, який описує формат маркера.

JWT мають цифровий підпис і шифрування, що робить їх захищеними від втручання. Маркер створюється шляхом серіалізації полів сеансу в об’єкт JSON, а потім кодування об’єкта в рядок, який діє як ідентифікатор маркера. Коли маркер повертається до API, маркер декодується та аналізується для відновлення атрибутів сеансу.

Що таке шифрування HMAC?

HMAC (hash-based message authentication code, хеш-код автентифікації повідомлень) — це безпечна система для захисту маркерів. Він заснований на криптографічній хеш-функції та містить секретний ключ, відомий лише серверу API. При використанні для автентифікації маркерів HMAC створює короткий тег автентифікації, який додається до маркера. Якщо хоча б один біт маркера буде змінено, тег зміниться, не даючи зловмиснику підробити нові маркери. Крім того, HMAC-SHA256 може негайно відхиляти запити, якщо тег автентифікації недійсний або відсутній, без будь-яких пошуків у базі даних, запобігаючи будь-яким атакам із синхронізацією.

Чи потрібна відповідь 401 для неавтентифікованих запитів до API із базовою автентифікацією?

Стандартна автентифікація повинна відповідати 401 на неавтентифіковані запити, як визначено в RFC2617. Однак це може спричинити витік інформації. Наприклад, API GitHub використовує версію базової автентифікації, яка дещо відрізняється від стандарту, визначеного в RFC2617. Відповідно до стандарту, неавтентифіковані запити повинні отримувати відповідь 401 Unauthorized, але це може виявити наявність даних користувача. Щоб уникнути цього, GitHub API замість цього повертає відповідь 404 Not Found.

GitHub Basic Authentication Documentation

Published on: Feb 4, 2023