Аутентификация на основе сессий и JWT (описание к предыдущему посту)

Большинство веб-приложений выбирают один из двух путей входа: сессии (при которых состояние хранится на сервере) или JWT (при которых состояние передается вместе с клиентом).

1. Аутентификация на основе сессий
При входе пользователя бэкенд создает случайный идентификатор сессии, сохраняет его в кэше или базе данных и устанавливает этот идентификатор в виде HTTP-only куки-файла в браузере. Каждый раз при отправке запроса браузер передает куки, сервер проверяет запись сессии и восстанавливает контекст пользователя. Это позволяет хранить конфиденциальные данные на стороне сервера и мгновенно завершать сеанс путем удаления записи.

Почему стоит выбрать сессии:

✅ Мгновенное аннулирование ("выйти везде") — достаточно удалить строку из Redis или SQL.

✅ Никакие секретные ключи никогда не покидают бэкэнд, снижая риск случайного раскрытия.

✅ Подходит для небольших и средних систем, где общий кэш не является узким местом.

Однако будьте осторожны: горизонтальное масштабирование зачастую требует либо прикрепленных сессий, либо реплицированного кеша, что может привести к увеличению задержки и усложнению операций.

2. Аутентификация на основе JWT
После успешного входа сервер подписывает JSON Web Token, содержащий заголовок (alg, typ), полезную нагрузку (например, поля вроде sub или role) и подпись. Токен кодируется в Base64, но не шифруется, позволяя любому прочитать содержимое полезной нагрузки, однако подделать токен может лишь тот, кто владеет секретным ключом. Сервер не хранит никакого состояния, любой узел сети способен проверить подпись и доверять заявленным данным.

Почему стоит рассмотреть использование JWT:

⚡️ Бессессионность: каждый микросервис или пограничный узел может локально проверять токены, исключая необходимость общего хранилища.

⚡️ Отлично подходит для SPA-приложений и мобильных приложений, непосредственно обращающихся к нескольким бекенд-сервисам.

⚡️ Легковесность: легко помещается в заголовок Authorization или куки.

Обратите внимание, что однажды выданный JWT остается действительным вплоть до истечения срока его действия; отозвать его без дополнительной инфраструктуры невозможно, что делает блокировку аккаунта или экстренный выход сложными задачами.

Таким образом, если вам важнее всего возможность отзывания доступа, придерживайтесь серверных сессий.

Если вам нужно масштабирование приложения без сохранения состояния, то подписанные JWT — это то, что вам нужно, но при проектировании учитывайте тот факт, что вы не сможете отозвать их обратно, как только они появятся в открытом доступе.