Битва титанов: Session ID против JWT

Битва титанов: Session ID против JWT

Евгений Гусинец

В первой части мы разобрали «детский сад» — API Key. Теперь переходим к инструментам, на которых держится 99% современного веба.

Сегодня столкнем лбами два подхода: Session ID (старая школа) и JWT (модный стандарт). Они решают одну задачу — пустить пользователя внутрь, но делают это с принципиально разной логикой и разными багами.

1. Session ID: Сервер помнит всё

Представьте, что вы заселяетесь в отель по системе «всё включено». Чтобы понять механику работы сессий, давайте разберем этот процесс по шагам:

  • Шаг 1: Регистрация. Вы подходите на ресепшен и показываете паспорт (вводите логин и пароль).
  • Шаг 2: Выдача пропуска. Администратор находит вас в базе и надевает вам на руку браслет (сервер создает Session ID и отдает его в cookie).
  • Шаг 3: Доступ к услугам. Теперь, чтобы взять коктейль в баре, вам достаточно показать браслет. Бармен звонит на ресепшен, проверяет, есть ли номер вашего браслета в списке активных гостей, и наливает напиток.

В мире IT браслет — это Cookie, а ресепшен — это база данных (или Redis) на сервере.

Как это ломается (Чек-лист QA):

  • Кража браслета (XSS): Если злоумышленник украдет куку, он станет вами.
  • Проверка: Кука обязана иметь флаг HttpOnly. Это значит, что скрипты на странице (JavaScript) не могут её прочитать. Нет флага = баг.
  • Фальшивый выход: Вы нажали «Выйти», сняли браслет и выбросили в урну. Но удалил ли администратор запись в базе?
  • Проверка: Сделайте Logout, сохраните старый Session ID и попробуйте выполнить запрос через Postman. Если пустило — это критический баг.
  • Бессмертие: Оставьте вкладку открытой на сутки. Сессия должна «протухнуть» (истечь по таймауту).

2. JWT: Документ с печатью

JWT (JSON Web Token) — это не браслет, а нотариальная доверенность. В ней написано: «Этому гражданину можно доверять, он админ, справка действительна до 14:00». Внизу стоит сургучная печать (подпись сервера).

Бармену (микросервису) не нужно звонить на ресепшен. Он просто смотрит на печать: «Печать наша? Не сломана? Проходи».

Главное отличие: Сервер не хранит информацию о выданных JWT (Stateless). Вся инфа — у вас в кармане, внутри токена.
Анатомия JWT (Header.Payload.Signature):

  • Header: «Я токен, зашифрован алгоритмом HS256».
  • Payload: Полезная нагрузка (User ID, роль, срок годности).
  • Signature: Цифровая подпись, гарантирующая, что Payload не меняли.

🚩 Red Flags для QA:

  1. «Голый» король: Payload в JWT не зашифрован, а просто закодирован (Base64). Любой, кто перехватит токен, может пойти на jwt.io и прочитать всё содержимое.
    Проверка:
    Если вы видите в токене пароли, номера паспортов или телефоны — заводите баг. Это утечка данных. Положить пароль в JWT — всё равно что написать пин-код на банковской карте маркером.
  2. Атака с отключением подписи: Хакер берет токен, меняет в Header алгоритм на none, а в Payload пишет role: admin.
    Проверка:
    Отредактируйте токен, уберите подпись и отправьте на сервер. Если сервер это «съел» — у вас дыра в безопасности размером с дом.

Бессмертный токен: Вы заблокировали пользователя, но его JWT всё еще валиден (время exp не истекло).
Нюанс: Это особенность архитектуры. Проверьте, есть ли механизм «черных списков» или просто ждите, пока токен протухнет (обычно 5–15 минут). 3.

3. Шпаргалка: В чем разница?

4. Bearer Token: просто курьер

Часто путают JWT и Bearer. Давайте расставим точки над i. Bearer — это схема авторизации. Буквально переводится как «Предъявитель». Принцип: «Кто предъявил билет, тот и пассажир». Неважно, украли вы билет или купили.

Как это выглядит:

Authorization: Bearer <ваш_токен>


Мини-тест для API:

  1. Отправьте токен без слова Bearer.
  2. Отправьте Bearer с маленькой буквы.
  3. Уберите пробел между словом и токеном.
  4. Ожидание: Во всех случаях сервер должен вернуть 401 Unauthorized. Формат должен быть строгим.

Итак: Session ID — надежно, контролируемо, но нагружает сервер.

JWT — быстро, модно, масштабируемо, но данные видны всем, и отозвать сложно.

В следующей, заключительной части мы разберем «высшую лигу»: OAuth 2.0 и Refresh Tokens. Мы узнаем, зачем нужен «токен для токена» и как автоматизировать всё это в Postman, не обновляя ключи руками каждые 15 минут.

___________________________________________________________________________
Автор: Евгений Гусинец Канал: QA❤️4Life Группа в ТГ: QA mistakes 
___________________________________________________________________________



Report Page