4 найпоширеніші методи автентифікації REST API

Оригінал статті за посиланням від Guy Levin

26 July 2019 on RestCase, REST API Security, REST API, OAS, API Driven Development

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

Автентифікація чи Авторизація

Перш ніж я заглиблюся в це, давайте означимо, що таке автентифікація насправді, і що важливіше, чим вона не є. Незважаючи на те, що автентифікація керує сучасним Інтернетом, цю тему часто пов’язують із тісно пов’язаним терміном: авторизація.

Дві функції часто пов’язані разом в одному рішенні, але найпростіший спосіб розділити авторизацію та автентифікацію — запитати: що вони насправді стверджують або доводять про мене?

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

Авторизація – це зовсім інше поняття, і, кажучи простою мовою, авторизація – це коли суб’єкт підтверджує право на доступ. Іншими словами, авторизація підтверджує, що ви маєте право подати запит. Зверніть увагу на наступне: у вас є робоча картка-ключ, яка дозволяє відкривати лише деякі двері в робочій зоні, але не всі.

Підсумовуючи: Автентифікація: відноситься до підтвердження дійсності особи Авторизація: стосується дозволу певної дії

API може автентифікувати вас, але не дозволити вам зробити певний запит.

Тепер, коли ми знаємо, що таке автентифікація, давайте подивимося, які методи автентифікації найчастіше використовуються в REST API.

4 найбільш використовувані методи автентифікації

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

1. Схеми автентифікації HTTP (базова та носій)

Протокол HTTP також визначає схеми авторизації безпеки HTTP, наприклад:

• Базовий
• Пред’явник
• Дайджест
• OAuth та інші…

Під час обговорення REST API ми розглянемо два найбільш популярні сьогодні.

Basic Authentication

Базову автентифікацію HTTP рідко рекомендують через її властиву вразливість безпеки.

Це самий прямий і найпростіший метод. За допомогою цього методу відправник розміщує ім’я користувача:пароль у заголовку запиту. Ім’я користувача та пароль кодуються за допомогою Base64, який є технікою кодування, яка перетворює ім’я користувача та пароль у набір із 64 символів для забезпечення безпечної передачі.

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

Ось приклад базової авторизації в заголовку запиту:

Authorization: Basic bG9sOnNlY3VyZQ==

Bearer Authentication

Автентифікація носія (Bearer authentication, також називається автентифікацією маркера) — це схема автентифікації HTTP, яка включає маркери безпеки (security tokens), які називаються маркерами носія (bearer tokens).

Назву «Bearer authentication» можна розуміти як «надати доступ до носія цього маркера». Маркер носія, що дозволяє отримати доступ до певного ресурсу або URL-адреси, і, швидше за все, є зашифрованим рядком, який зазвичай генерується сервером у відповідь на запит входу.

Клієнт повинен надіслати цей маркер у заголовку авторизації (Authorization) під час надсилання запитів до захищених ресурсів: Authorization: Bearer <token>

Схема автентифікації носія спочатку була створена як частина OAuth 2.0 у RFC-6750, але іноді також використовується окремо. Подібно до базової автентифікації, автентифікацію носія слід використовувати лише через HTTPS (SSL).

2. API Keys

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

Багато ключів API надсилаються в рядку запиту як частина URL-адреси, що полегшує виявлення для тих, хто не повинен мати до нього доступу. Будь ласка, не додавайте ключі API або конфіденційну інформацію в параметри рядка запиту! Кращий варіант – розмістити ключ API в заголовку авторизації. Фактично, це запропонований стандарт: Authorization: Apikey 1234567890abcdef

Проте на практиці ключі API з’являються в самих різних місцях:

• Authorization Header - Заголовок авторизації
• Basic Auth - Основна авторизація
• Body Data - Дані тіла
• Custom Header - Спеціальний заголовок
• Query String - Рядок запиту

Безумовно, є кілька вагомих причин для використання ключів API. Перш за все, ключі API прості. Використання єдиного ідентифікатора є простим, а для деяких випадків використання найкращим рішенням. Наприклад, якщо API обмежений у функціональності, де єдиною можливою командою є «читати», ключ API може бути адекватним рішенням. Без необхідності редагувати, змінювати або видаляти безпека є меншою проблемою.

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

Якщо ви маєте справу з автентифікацією в REST API, спробуйте виконати тестування безпеки, щоб перевірити поширені вразливості.

3. OAuth (2.0)

Попередні версії цієї специфікації, OAuth 1.0 і 1.0a, були набагато складнішими, ніж OAuth 2.0. Найбільша зміна в останній версії полягає в тому, що більше не потрібно підписувати кожен виклик хешем із ключем. Найпоширеніші реалізації OAuth замість цього використовують один або обидва ці маркери:

• маркер доступу (access token): надсилається як ключ API, він дозволяє додатку отримувати доступ до даних користувача; за бажанням, маркери доступу можуть закнічувати час дії.
• маркер оновлення (refresh token): необов’язково частина потоку OAuth, маркери оновлення отримують новий маркер доступу, якщо термін їх дії минув. OAuth2 поєднує автентифікацію та авторизацію, щоб забезпечити більш складний контроль обсягу та дійсності.

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

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

OAuth 2.0 Popular Flows

Потоки (flows , також звані типами надання - grant types) — це сценарії, які виконує клієнт API, щоб отримати маркер доступу від сервера авторизації. OAuth 2.0 надає кілька популярних потоків, які підходять для різних типів клієнтів API:

• Код авторизації (Authorization code) – найпоширеніший спосіб, який переважно використовується для серверних і мобільних веб-додатків. Цей процес схожий на те, як користувачі реєструються у веб-програмі за допомогою свого облікового запису Facebook або Google.
• Невний (Implicit) – цей потік вимагає від клієнта безпосередньо отримати маркер доступу. Це корисно у випадках, коли облікові дані користувача неможливо зберегти в коді клієнта, оскільки до них може легко отримати доступ третя сторона. Він підходить для веб-додатків, настільних комп’ютерів і мобільних додатків, які не містять серверних компонентів.
• Пароль власника ресурсу – вимагає входу за допомогою імені користувача та пароля. Оскільки в такому випадку облікові дані будуть частиною запиту, цей потік підходить лише для довірених клієнтів (наприклад, офіційних програм, випущених постачальником API).
• Облікові дані клієнта – призначений для міжсерверної автентифікації, цей потік описує підхід, коли клієнтська програма діє від свого імені, а не від імені окремого користувача. У більшості сценаріїв цей потік надає засоби, які дозволяють користувачам вказувати свої облікові дані в клієнтській програмі, щоб вона могла отримати доступ до ресурсів під контролем клієнта.

4. OpenID Connect

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

З технічної точки зору OpenID Connect визначає RESTful HTTP API, використовуючи JSON як формат даних.

OpenID Connect дозволяє низці клієнтів, включаючи веб-, мобільні та JavaScript-клієнти, запитувати та отримувати інформацію про автентифіковані сеанси та кінцевих користувачів. Набір специфікацій є розширюваним і підтримує такі додаткові функції, як шифрування ідентифікаційних даних, виявлення постачальників OpenID і керування сеансами.

OpenID Connect визначає процес входу, який дозволяє клієнтській програмі автентифікувати користувача та отримувати інформацію (або «заяви») про цього користувача, наприклад ім’я користувача, електронну адресу тощо. Ідентифікаційна інформація користувача закодована в безпечному веб-маркері JSON (JWT - JSON Web Token), який називається ID-токен.

JWT

Веб-маркери JSON — це відкритий галузевий стандартний метод RFC 7519 для безпечного представлення претензій між двома сторонами. JWT дозволяє декодувати, перевіряти та генерувати JWT. Незважаючи на те, що JWT є стандартом, він був розроблений компанією Auth0, керованою ідентифікацією та автентифікацією на основі API.

OpenID Connect визначає механізм виявлення під назвою OpenID Connect Discovery, де сервер OpenID публікує свої метадані за загальновідомою URL-адресою, зазвичай https://server.com/openid-configuration.

Ця URL-адреса повертає перелік JSON кінцевих точок OpenID/OAuth, підтримуваних областей і претензій, відкритих ключів, які використовуються для підпису маркерів, та інших деталей. Клієнти можуть використовувати цю інформацію для створення запиту до сервера OpenID. Назви та значення полів визначено в специфікації OpenID Connect Discovery.

OpenAPI Security Schemes

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

У специфікації OpenAPI є кілька стандартних протоколів автентифікації, з яких ви можете вибрати, кожен зі своїми сильними та слабкими сторонами.

Basic API Authentication

• Простий у застосуванні, підтримується майже всіма веб-серверами

• Передбачає надсилання імені користувача та паролів у кодуванні base-64
• Не слід використовувати без SSL
• Можна легко поєднувати з іншими методами безпеки

Примітка*: базова автентифікація дуже вразлива до викрадення та атак типу “людина посередині”, якщо не використовується шифрування. Через це обмеження цей метод автентифікації рекомендується використовувати лише в парі з SSL.*

OAuth1.0 (Digest Scheme)

• Популярний, перевірений, безпечний, керований підписами, чітко визначений протокол
• Використовує криптографічний підпис, який є сумішшю секретного маркера, nonce та іншої інформації на основі запиту
• Можна використовувати з SSL або без нього

OAuth2 (Bearer Token Scheme)

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

OpenID Connect Discovery

• На основі протоколу OAuth 2.0
• Використовує процес входу, який дозволяє автентифікацію користувача та доступ до інформації за допомогою клієнтської програми
• Інформація про користувача закодована за допомогою безпечного веб-токена JSON (JWT)

Платформа розробки RestCase дозволяє візуально визначати ці схеми безпеки, дозволяючи створювати та визначати весь API без будь-яких знань програмування.

Будь ласка, не соромтеся приєднатися до нашої бета-версії, just sign-up and start building APIs - It’s free!

Резюме

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

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