Сесійні cookies чи JWT для вебавтентифікації

Коротка відповідь

Cookie — механізм зберігання й транспорту браузера; JWT — формат токена. Вони сумісні: cookie може містити opaque ID чи JWT. Порівняйте серверну сесію й самодостатній токен, окремо виберіть передавання. Для звичайного web-застосунку серверна сесія у вузькому HttpOnly-cookie часто є практичним початком.

Рішення залежить від валідаторів, швидкості відкликання й загроз. Підписаний токен не є автоматично зашифрованим; decode не є verify. HttpOnly не дає JavaScript читати credential, але заражений код може виконувати дії з входом. Потрібні захист XSS і CSRF.

Практичні кроки реалізації

Визначте життєвий цикл

Визначте абсолютний та idle-строки, rotation після входу чи зміни прав, logout і блокування. Opaque ID можна відкликати записом сервера. Самодостатній токен чинний до expiry без revocation чи version-state. Така перевірка змінює stateless-модель і її експлуатацію.

Виберіть обробку credential

Використовуйте Secure через HTTPS, HttpOnly для нечитаних клієнтом credentials, відповідний SameSite й host. __Host- потребує Secure, Path=/ і відсутності Domain у підтримуваних браузерах. Cross-site-вхід може потребувати іншого SameSite; перевіряйте потік, не ставте None навмання.

Перевіряйте токени на довіреній межі

Для JWT використовуйте підтримуваний verifier з явними algorithms і перевіряйте підпис, issuer, audience, expiry та потрібні claims. Не вибирайте алгоритм лише з токена. Ролі можуть застаріти; плануйте rotation ключів. Приватне не кладіть у лише підписаний payload: claims читаються.

Окремо авторизуйте операції

Чинна сесія визначає користувача, не доступ до всього. Scoped-читання й запис та права операції обов’язкові. Персональні відповіді не мають бути shared-cache. Не кладіть токени в URL, аналітику, винятки й журнали.

Приклад реалізації

Фрагмент Node.js створює випадковий opaque ID й production-cookie. Це не повний login: перевірте вхід, збережіть серверну сесію з expiry й захистіть зміни стану.

import { randomBytes } from "node:crypto";

const sessionId = randomBytes(32).toString("base64url");
const cookie = `__Host-session=${sessionId}; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600`;
// Persist sessionId (or its lookup hash) with user and server expiry before responding.
// Set the cookie as a response Set-Cookie header over HTTPS.

Cookie-строк не замінює серверний. Видалення cookie не відкликає копію: logout має інвалідувати запис для негайного відкликання. Використовуйте перевірену session-бібліотеку, не будуйте криптографію з фрагмента.

Компроміси та альтернативи

Opaque-сесія потребує store, але спрощує відкликання. Підписані токени підтримують незалежних валідаторів, додаючи ключі, claims і revocation. Короткий access і refresh додають складність, не усувають стан. Обирайте її за потребами системи.

Поширені помилки

• Cookie і JWT як однакові категорії.
• Decode без verify.
• Підпис як шифрування.
• HttpOnly як повний захист XSS.
• Очищення cookie з чинною серверною сесією.

Контрольний список перед випуском

• ☐ Формат і транспорт окремі.
• ☐ Строк, rotation, logout і disablement реалізовано.
• ☐ Cookie відповідає потоку.
• ☐ JWT-verifier має trust-policy.
• ☐ CSRF, XSS, ownership і cache перевірено.
• ☐ Credentials відсутні в URL і діагностиці.

Поширені запитання

Чи JWT можна зберігати в HttpOnly-cookie?

Так. Поєднуються формат JWT і транспорт cookie, тому застосовуються обидві групи вимог.

Чи stateless робить logout автоматичним?

Ні. Копія чинного токена переживає локальний logout. Визначте expiry й revocation та звірте валідаторів.

Висновок

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

Первинні джерела

• MDN: Set-Cookie
• MDN: безпечні cookie
• OWASP: керування сесіями
• IETF: специфікація JWT

Пов’язані посібники та приклади

• Тематичний розділ
• Проєктування REST API для продуктових команд
• GraphQL чи REST: вибір за навантаженням
• Проєктування схеми PostgreSQL для вебзастосунків
• Контексти входу продуктів портфоліо