А) Методи аутентифікації: Детальні пояснення

Аутентифікація - це процес підтвердження особи або програми, яка намагається отримати доступ до ресурсу (наприклад, API). Це як перевірка документів перед тим, як пустити когось у будівлю. Існує кілька поширених методів аутентифікації в API:

🔑 → API Keys (Ключі API)

Що це?

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

Як це працює?

1. Отримання ключа: Розробник програми реєструє свою програму на платформі, що надає API, і отримує унікальний API Key.
2. Передача ключа: Кожен запит до API від програми включає цей ключ. Зазвичай ключ передається в одному з:
   • Заголовку HTTP: Наприклад, у заголовку X-API-Key: YOUR_API_KEY.
   • Параметрі запиту (Query Parameter): Наприклад, у URL на кшталт https://api.example.com/data?api_key=YOUR_API_KEY.
3. Перевірка ключа: Сервер API отримує ключ і перевіряє, чи він є дійсним та чи має програма право на доступ до запитуваного ресурсу.
4. Доступ надано/відмовлено: Якщо ключ дійсний, сервер обробляє запит і повертає дані. Інакше - повертає помилку (зазвичай 401 Unauthorized).

Переваги:

• Простота: Легко реалізувати як на стороні клієнта, так і на стороні сервера.
• Швидкість: Перевірка ключа зазвичай відбувається швидко.

Недоліки:

• Безпека: Ключі API є статичними та можуть бути вкрадені, якщо їх не захищати належним чином (наприклад, не зберігати в коді відкрито).
• Обмежені можливості: Зазвичай не надають детальної інформації про користувача, лише про програму.
• Складність відкликання: Відкликати скомпрометований ключ може бути складно (потрібно генерувати новий та оновлювати всі програми, що його використовують).

Використання:

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

---

🛡️ → OAuth 2 (Open Authorization 2.0)

Що це?

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

Основні учасники:

• Resource Owner (Власник ресурсу): Користувач, чиї дані потрібно отримати (наприклад, ви).
• Client (Клієнт): Стороння програма, яка хоче отримати доступ до ресурсів користувача (наприклад, програма для редагування фотографій).
• Authorization Server (Сервер авторизації): Сервер, який видає токени доступу після успішної аутентифікації користувача та отримання його згоди.
• Resource Server (Сервер ресурсів): Сервер, який зберігає ресурси користувача і перевіряє токени доступу перед наданням доступу.

Основні потоки (Grant Types):

OAuth 2 визначає кілька способів отримання токенів доступу ("grant types"), залежно від типу клієнта та сценарію використання. Найпоширеніші:

• Authorization Code Grant: Використовується для веб-додатків. Включає перенаправлення користувача на сервер авторизації для надання згоди, а потім обмін коду авторизації на токен доступу.
• Implicit Grant: (Зазвичай не рекомендується через безпекові міркування) Використовується для односторінкових додатків (SPA). Токен доступу повертається безпосередньо через URL-фрагмент після надання згоди.
• Password Grant: Клієнт безпосередньо передає облікові дані користувача на сервер авторизації. Використовується рідко і лише для довірених клієнтів.
• Client Credentials Grant: Використовується для авторизації між серверами, коли клієнт діє від свого імені, а не від імені користувача.

Як це працює (спрощено для Authorization Code Grant):

1. Клієнт перенаправляє користувача на сервер авторизації.
2. Користувач вводить свої облікові дані та надає згоду клієнту на доступ до своїх ресурсів.
3. Сервер авторизації перенаправляє користувача назад до клієнта з кодом авторизації.
4. Клієнт відправляє код авторизації на сервер авторизації та отримує токен доступу (та, можливо, токен оновлення).
5. Клієнт використовує токен доступу для запитів до сервера ресурсів.
6. Сервер ресурсів перевіряє токен доступу та надає доступ до ресурсів користувача.

Переваги:

• Безпека: Користувачі не розкривають свої облікові дані стороннім програмам.
• Обмежений доступ: Користувач може надати клієнту лише певні права доступу (наприклад, лише читання профілю, а не редагування).
• Відкликання доступу: Користувач може в будь-який момент відкликати доступ, наданий клієнту.

Недоліки:

• Складність: Реалізація може бути складнішою порівняно з API Keys.
• Більше запитів: Потрібно кілька кроків для отримання токена доступу.

Використання:

Стандарт для авторизації в багатьох сучасних веб-додатках та API (наприклад, "Увійти через Google", "Підключити до Facebook").

---

🗝️ → JWT (JSON Web Tokens)

Що це?

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

Структура JWT:

JWT складається з трьох частин, розділених крапками (.):

1. Header (Заголовок): Містить інформацію про тип токена (зазвичай "JWT") та алгоритм підпису (наприклад, HMAC SHA256 або RSA).
2. Payload (Корисне навантаження): Містить "твердження" (claims) - інформацію про користувача та інші дані. Існують зареєстровані твердження (наприклад, iss - issuer, sub - subject, exp - expiration time), публічні твердження (які можуть бути визначені сторонами) та приватні твердження (специфічні для програми).
3. Signature (Підпис): Створюється шляхом шифрування закодованих заголовка та корисного навантаження з використанням секретного ключа (для HMAC) або приватного ключа (для RSA) та алгоритму, вказаного в заголовку. Підпис використовується для перевірки цілісності токена та підтвердження того, що він не був підроблений.

Як це працює (спрощено):

1. Коли користувач успішно аутентифікується на сервері, сервер генерує JWT, що містить інформацію про користувача (наприклад, його ID) та підписує його.
2. Сервер повертає JWT клієнту (зазвичай у заголовку Authorization: Bearer YOUR_JWT).
3. Клієнт зберігає JWT (наприклад, у localStorage або cookie) та включає його в кожен наступний запит до захищених ресурсів API (зазвичай у заголовку Authorization: Bearer YOUR_JWT).
4. Сервер API отримує JWT, перевіряє його підпис за допомогою секретного (або публічного) ключа та перевіряє твердження (наприклад, чи не закінчився термін дії токена).
5. Якщо підпис дійсний і твердження валідні, сервер вважає користувача автентифікованим та надає доступ до ресурсу.

Переваги:

• Самодостатність: Вся необхідна інформація про користувача міститься в самому токені.
• Безпека: Підпис гарантує цілісність та автентичність токена.
• Масштабованість: Серверу не потрібно зберігати сесійну інформацію (stateless), що полегшує масштабування.
• Простота використання: Легко передавати через HTTP-заголовки.

Недоліки:

• Розмір: Може бути більшим за прості сесійні ідентифікатори.
• Відкликання: Відкликати JWT може бути складніше, оскільки вони самодостатні. Зазвичай використовують короткий термін дії або додаткові механізми відкликання.

Використання:

Широко використовується для аутентифікації та авторизації в сучасних веб-додатках, мобільних додатках та мікросервісних архітектурах.

---

👤 → Basic Auth (Базова аутентифікація)

Що це?

Basic Auth (базова аутентифікація) - це простий метод аутентифікації, в якому клієнт передає свої облікові дані (ім'я користувача та пароль) у кожному запиті до API через заголовок Authorization. Пароль кодується в форматі Base64.

Як це працює:

1. Клієнт отримує ім'я користувача та пароль.
2. Клієнт об'єднує ім'я користувача та пароль у форматі username:password.
3. Клієнт кодує цей рядок у Base64.
4. Клієнт додає заголовок Authorization до HTTP-запиту зі значенням Basic BASE64_ENCODED_CREDENTIALS.
5. Сервер API отримує запит, декодує значення заголовка Authorization з Base64, отримує ім'я користувача та пароль і перевіряє їх.
6. Якщо облікові дані дійсні, сервер обробляє запит. Інакше - повертає помилку 401 Unauthorized.

Приклад заголовка: