Ось готовий урок, створений за твоїм майстер-промптом. Це не просто лекція, це — інтерактивна подорож у світ безпеки. Поїхали!

🎓 Тема: Аутентифікація: базові підходи

1. 🔥 Вступ: проблема та мотивація

Уявіть, що ви приходите в банк, підходите до каси і кажете: "Привіт, я Ілон Маск. Дайте мені, будь ласка, мільйон доларів з мого рахунку" 💸.

Касир дивиться на вас. Ви дивитесь на касира. Чи повірить він вам на слово? Звісно, ні. А чому? Тому що ви не довели, що ви — це саме ви.

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

Питання до вас: Як сервер, який "забуває" про користувача одразу після того, як віддав йому сторінку (бо HTTP — це протокол без збереження стану), може пам'ятати, що ви залогінилися 5 хвилин тому?

Без аутентифікації інтернет був би просто набором публічних оголошень на паркані. Ніхто не мав би особистого простору. Сьогодні ми розберемося, як саме ми відповідаємо на питання: "Хто ти?".

2. 🧠 Теоретична база (без сухої академічності)

Давайте розставимо крапки над "і".

Ключові поняття:

Ідентифікація — це коли ви кажете: "Я — користувач admin".
Аутентифікація (Authentication, AuthN) — це коли ви доводите це. Наприклад, показуєте паспорт або вводите пароль.
Авторизація (Authorization, AuthZ) — це перевірка, чи маєте ви право робити те, що хочете (наприклад, видаляти файли). Сьогодні ми говоримо тільки про пункт 2.

Як це працює "під капотом"?

Оскільки HTTP "не має пам'яті", нам потрібно передавати якийсь доказ у кожному запиті. Є два основні підходи, як це робити. Уявіть, що ви йдете на закриту вечірку 🕺.

Підхід А: Сесії (Sessions) — "Списки гостей"

Ви показуєте охоронцю паспорт (логін/пароль).
Охоронець звіряє його, киває і записує ваше ім'я в журнал (Session Storage на сервері).
Він дає вам паперовий браслет з номером (Session ID).
Тепер, коли ви йдете до бару, ви просто показуєте браслет. Бармен дзвонить охоронцю, каже номер, а охоронець перевіряє журнал: "Так, номер 123 — це Іван, йому є 18".
Суть: Дані зберігаються на сервері. У вас — лише посилання (ID).

Підхід Б: Токени (Tokens / JWT) — "Гербова печатка"

Ви показуєте паспорт (логін/пароль).
Охоронець не має журналу. Він бере бланк, пише на ньому "Це Іван, йому є 18", ставить сургучну печатку (цифровий підпис) і віддає вам цей документ (Token).
Ви йдете до бару і показуєте цей документ.
Бармен не дзвонить охоронцю. Він просто дивиться на печатку. Якщо вона ціла і справжня — він вам вірить.
Суть: Дані зберігаються у вас (в токені). Сервер просто перевіряє підпис.

💡 Що запам’ятати залізно: Ніколи не зберігайте паролі користувачів у відкритому вигляді. Ніколи! Ми їх "хешуємо" (перетворюємо на набір символів, який неможливо розшифрувати назад).

3. 🧪 Приклади (від простого до реального)

Приклад 1: "Наївний" підхід (Basic Auth)

Найпростіший, але старий метод. Ми просто передаємо логін і пароль у кожному запиті.

Як це виглядає в HTTP-заголовку:

Authorization: Basic dXNlcjpwYXNzd29yZA==

(Цей дивний рядок — це просто "user:password", закодований у Base64).

Питання до вас: Як ви думаєте, якщо хакер перехопить цей запит у кав'ярні через Wi-Fi, чи зможе він дізнатися ваш пароль? . . . Відповідь: Так, миттєво! Base64 — це не шифрування, це просто спосіб запису. Це як написати пароль догори дриґом. Тому Basic Auth використовують тільки з HTTPS (захищеним з'єднанням).

Приклад 2: Cookie Session (Класика)

Це той самий "паперовий браслет".

Клієнт: Відправляє POST /login (username, password).
Сервер: Перевіряє пароль. Якщо ОК — створює сесію в пам'яті (або в базі даних) і відправляє клієнту Cookie.

Set-Cookie: session_id=abc-123-xyz; HttpOnly; Secure

Клієнт: При наступному запиті браузер автоматично додає цей кук.

GET /my-profile
Cookie: session_id=abc-123-xyz

Чому це круто: HttpOnly означає, що JavaScript (і хакери через XSS) не можуть вкрасти цей кук. Мінус: Серверу треба пам'ять, щоб зберігати всі ці ID.

Приклад 3: JWT (JSON Web Token) — Сучасний стандарт

Це той самий "документ з печаткою". Токен складається з трьох частин, розділених крапкою: AAAAA.BBBBB.CCCCC

Header (Заголовок): Тип шифрування.
Payload (Корисні дані): {"userId": 1, "role": "admin"}.
Signature (Підпис): Секретний код, який гарантує, що дані не змінювали.

Сценарій: Ви — хитрий хакер. Ви взяли свій токен, розшифрували середню частину (Payload) і змінили "role": "user" на "role": "admin". Потім відправили серверу.

Питання: Що зробить сервер? . . . Пояснення: Сервер візьме заголовок і ваші змінені дані, знову проведе математичну операцію з використанням свого секретного ключа і отримає новий підпис. Він порівняє його з тим підписом, що прислали ви. Вони не співпадуть! Сервер скаже: "Фальшивка!" і відхилить запит 🚫.

4. 🛠 Практична частина

Час розім’яти мізки!

Завдання 1: Декодування (Розминка) Знайдіть в інтернеті будь-який "Base64 decoder". Вставте туди рядок: U3VwZXJTZWNyZXQ= Що ви побачили? Це доказ того, що кодування — це не захист.

Завдання 2: "А що, якщо..." Уявіть, що ви використовуєте Sessions (списки гостей). Сервер перезавантажився або вимкнулося світло, а дані сесій зберігалися в оперативній пам'яті (RAM). Що станеться з усіма користувачами, які були залогінені на сайті?

Завдання 3: Знайди вразливість Джуніор-розробник Вася написав код, де після успішного логіну сервер відправляє клієнту такий JSON: { "status": "ok", "user_id": 42, "is_admin": true } І далі клієнт у кожному запиті просто передає цей JSON назад серверу. Як ви можете зламати таку систему за 10 секунд?

Завдання 4: Міні-кейс Ви розробляєте: А) Інтернет-банкінг (висока безпека, сесія має "протухати" швидко). Б) Мобільний додаток для новин (користувач не хоче логінитися щоразу, коли відкриває телефон).

Який підхід (Сесії чи Токени) ви оберете для А і для Б? Чому?

5. 💡 Мислення як у розробника

Як відрізнити новачка від профі в темі аутентифікації?

Новачок намагається написати свою функцію шифрування паролів. Він думає: "Я зсуну кожну літеру на 3 позиції, ніхто не здогадається!".
- Профі знає: криптографія — це математика, яку розробляли генії. Профі бере готові бібліотеки (наприклад, bcrypt або Argon2). Не винаходьте велосипед у безпеці!
Новачок зберігає паролі у базі даних просто так: mypassword123.
- Профі зберігає лише хеш (незворотний відбиток) + сіль (випадковий набір символів, щоб однакові паролі мали різні хеші).
Новачок плутає Аутентифікацію (вхід) та Авторизацію (права доступу).
- Профі спочатку перевіряє "хто ти", а потім окремим шаром перевіряє "чи можна тобі це робити".

6. 🧩 Підсумок

Отже, що ми маємо в сухому залишку:

Аутентифікація — це відповідь на питання "Хто ти?".
HTTP не пам'ятає вас, тому треба передавати докази в кожному запиті.
Сесії = квиток у гардероб (дані на сервері). Гарно для вебу.
Токени (JWT) = паспорт з візою (дані у клієнта, підписані сервером). Гарно для мобільних додатків та мікросервісів.
Ніколи не зберігайте паролі у чистому вигляді!

Ви тепер вмієте: розрізняти базові типи аутентифікації та розумієте, чому просто передати user_id у запиті — це дірка в безпеці.

🔜 У наступній серії: Окей, ми впустили користувача в систему. Але як переконатися, що звичайний менеджер не зможе звільнити директора? Ми поговоримо про Авторизацію та Ролі (RBAC).

Тримайте свої токени в безпеці! До зустрічі! 👨‍💻👩‍💻