Один из менее заметных, но принципиальных выборов в архитектуре Сэйфком: то, как браузер подтверждает серверу, что вы уже вошли в систему. Это не cookie, которая прикрепляется к запросу автоматически, а токен, который приложение явно вкладывает в каждый запрос само. Разница звучит технически, но у неё есть прямое следствие для безопасности: она закрывает целый класс атак ещё на уровне архитектуры.
Классическая веб-сессия устроена так: после входа сервер выдаёт cookie, браузер сохраняет её и с этого момента прикрепляет её ко всем запросам на этот домен автоматически. Вам не нужно ничего для этого делать, это встроенное поведение браузера. Удобство оборачивается риском: раз браузер прикрепляет cookie к любому запросу на домен сам, злоумышленник может заставить ваш браузер отправить запрос от вашего имени, просто разместив нужную форму или картинку на постороннем сайте, который вы открыли в соседней вкладке. Это и есть CSRF (Cross-Site Request Forgery): сервер получает запрос с валидной cookie и не может отличить его от вашего собственного, потому что cookie прикрепилась одинаково в обоих случаях.
При входе сервер создаёт сессию и генерирует случайный токен: 32 случайных байта, ничего не значащих без базы данных на сервере. Токен уходит клиенту один раз, в теле ответа на запрос входа, а не как cookie. Дальше при каждом обращении к API фронтенд-код сам вставляет этот токен в заголовок Authorization: Bearer …. Ключевое отличие от cookie здесь в том, что браузер ничего не делает автоматически. Сторонняя страница физически не может заставить ваш браузер добавить этот заголовок к чужому запросу: она не имеет доступа к токену, который лежит не в cookie, а в памяти приложения. Сам класс CSRF-атак на такую схему просто неприменим, и не потому, что где-то стоит дополнительная проверка, а потому что нет автоматического прикрепления учётных данных, которым можно было бы злоупотребить.
В коде класс, который проверяет этот токен на бэкенде, называется JwtAuth, и это может ввести в заблуждение. Настоящий JWT, то есть JSON Web Token, это самодостаточная подписанная структура, и сервер может провалидировать её математически, не обращаясь к базе, потому что вся нужная информация и подпись уже зашиты в самом токене. То, что использует Сэйфком, устроено проще и с одним важным следствием: это непрозрачный (opaque) токен, случайная строка без внутренней структуры. На сервере хранится не сам токен, а его SHA-256 хеш, привязанный к записи о сессии в базе данных. При каждом запросе бэкенд берёт токен из заголовка, хеширует и ищет совпадение в таблице сессий. Если сессия отозвана или истекла, совпадения не будет, даже если сама строка токена формально «валидна».
Разница между настоящим JWT и opaque-токеном заключается в разнице между «доверять подписи» и «доверять базе данных». У самодостаточного подписанного JWT есть неудобное свойство: пока подпись верна и срок действия не истёк, сервер обязан его принять, и отозвать один конкретный токен раньше срока без централизованного списка отзыва невозможно. У Сэйфком отзыв сессии, это просто удаление или пометка строки в таблице sessions. Выход из аккаунта, принудительный разлогин на всех устройствах, истечение по неактивности: всё это работает мгновенно и безусловно, потому что источник истины один, база данных, а не сам токен.
Для обычной работы с Сэйфком это невидимо: вход выглядит как вход. Но если вы разработчик и когда-нибудь заглянете в сетевые запросы, разница будет заметна: не будет cookie с сессией, будет заголовок Authorization с токеном, который явно передаёт клиентский код. Это осознанный выбор архитектуры, а не побочный эффект, и он одновременно закрывает CSRF на уровне протокола и даёт мгновенный, предсказуемый контроль над отзывом доступа.
Оставьте контакты: перезвоним в течение 15 минут и подберём решение под вашу задачу.
© 2026 Сэйфком. ИП Михайлов А.И. Все права защищены.