JWT — это пропуск в систему. И именно поэтому его нельзя разбрасывать где попало

Ты заходишь на сайт, вводишь логин и пароль, а сервер отвечает:

«Окей, это действительно ты».

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

Поэтому после входа пользователь часто получает JWT — JSON Web Token.

И здесь начинается классическое:

«Ну токен же просто длинная строка. Что с ней может случиться?»

Многое. Потому что иногда эта строка буквально заменяет твой логин и пароль. 😅

🎟 Представь, что JWT — это браслет на фестивале

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

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

JWT работает примерно так же:

Логин и пароль
↓
Сервер проверяет пользователя
↓
Сервер выдаёт JWT
↓
Клиент сохраняет токен
↓
Отправляет его вместе с запросами

Пользователь один раз подтверждает личность, а затем предъявляет токен при обращении к защищённым разделам приложения.

JWT можно представить как цифровой пропуск, который подтверждает право доступа к системе.

📦 Что находится внутри JWT?

Обычный JWT выглядит примерно так:

xxxxx.yyyyy.zzzzz

Он состоит из трёх частей, разделённых точками:

• Header — информация о типе токена и алгоритме подписи;

• Payload — данные, или claims, связанные с пользователем и токеном;

• Signature — подпись, позволяющая проверить, что содержимое не изменили.

В payload могут находиться такие данные:

{
  "sub": "15",
  "role": "user",
  "iat": 1782450000,
  "exp": 1782450900
}

Здесь:

• sub — идентификатор пользователя;

• role — его роль;

• iat — время выпуска токена;

• exp — время окончания действия.

⚠️ JWT обычно не зашифрован

Один из самых важных моментов: содержимое обычного подписанного JWT можно декодировать.

Base64URL — это не шифрование. Это способ представить данные в текстовом виде.

Поэтому в payload нельзя класть:

• ❌ пароли;

• ❌ данные банковских карт;

• ❌ секретные API-ключи;

• ❌ приватную информацию, которую пользователь не должен видеть;

• ❌ любые данные, публикация которых создаст проблемы.

Подпись защищает токен от незаметного изменения, но не делает его содержимое секретным.

И ещё важное правило: не вставляй настоящий рабочий токен в случайные онлайн-декодеры. Для проверки структуры безопаснее использовать локальные инструменты или тестовый JWT.

🧩 Зачем нужна подпись?

Допустим, пользователь декодировал токен и увидел:

{
  "role": "user"
}

После этого он меняет значение:

{
  "role": "admin"
}

Кажется, план идеален. Пара секунд — и ты администратор всей системы. Можно уже выбирать себе зарплату. 😎

Но есть проблема: после изменения payload старая подпись перестанет соответствовать содержимому токена.

Сервер проверит подпись и ответит:

401 Unauthorized

Чтобы создать корректную подпись, злоумышленнику нужен секрет или закрытый ключ, которым пользуется сервер.

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

🚨 Почему JWT нельзя отправлять кому попало?

Представь, что ты вошёл в рабочую систему, открыл DevTools, скопировал JWT и отправил его в общий чат:

«Ребята, у кого-нибудь этот запрос тоже падает?»

Если система принимает этот токен как подтверждение личности, другой человек может использовать его для отправки запросов от твоего имени.

Ему может не понадобиться:

• твой пароль;

• доступ к электронной почте;

• повторный вход;

• код подтверждения.

Пока токен действует, сервер может воспринимать владельца токена как авторизованного пользователя.

Кто получил рабочий bearer-токен, тот потенциально получил и связанные с ним права доступа.

Слово Bearer здесь очень говорящее: доступ получает тот, кто предъявил токен.

💀 Где разработчики случайно сливают токены?

1. В Telegram, Slack и рабочих чатах

Вот токен, проверьте у себя:
eyJhbGciOiJIUzI1NiIs...

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

2. В публичном репозитории

const token = "eyJhbGciOiJIUzI1NiIs...";

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

Даже если удалить токен следующим коммитом, он может остаться в истории Git.

3. В логах

console.log("JWT:", token);

Логи могут попадать в системы аналитики, мониторинга ошибок, облачные панели и файлы, доступные большему количеству сотрудников, чем планировалось.

4. На скриншотах и записях экрана

Разработчик записывает видео с DevTools, публикует его в чате или на YouTube, а в заголовках запросов спокойно лежит рабочий токен.

Выглядит безобидно. Работает как бесплатная раздача доступа. 🎁

5. В URL

https://example.com/profile?token=eyJhbGci...

URL может сохраниться в истории браузера, логах сервера, аналитике и заголовке Referer. Поэтому передавать токены через адресную строку обычно плохая идея.

🏠 Где хранить JWT?

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

LocalStorage

Хранить токен в localStorage просто, но JavaScript на странице может получить к нему доступ.

Если в приложении есть XSS-уязвимость, вредоносный скрипт сможет прочитать токен и отправить его злоумышленнику.

HttpOnly Cookie

Cookie с флагом HttpOnly нельзя прочитать через обычный JavaScript в браузере. Это снижает риск прямой кражи токена при XSS.

Но cookie автоматически отправляются браузером, поэтому нужно отдельно учитывать CSRF и правильно настраивать:

• HttpOnly;

• Secure;

• SameSite;

• область действия cookie;

• защиту от межсайтовых запросов.

Безопасность — это не выбор одного магического хранилища. Это набор решений, каждое из которых закрывает определённые риски.

⏰ Зачем токену срок действия?

В JWT часто присутствует поле exp, которое указывает, когда токен перестанет быть действительным.

Если access token украли, небольшой срок жизни ограничивает время, в течение которого им можно воспользоваться.

В распространённой схеме используются два токена:

• ⚡ Access Token — живёт недолго и используется для запросов к API;

• 🔄 Refresh Token — позволяет получить новый access token.

Refresh token обычно защищают особенно тщательно, потому что он может продлевать пользовательскую сессию.

При этом конкретные сроки — 5 минут, 15 минут, час или больше — выбираются под требования проекта. Волшебного числа, подходящего всем, не существует.

🚀 Как JWT используется в приложении?

Типичный процесс выглядит так:

POST /login
↓
Сервер проверяет логин и пароль
↓
Выдаёт access token
↓
Клиент отправляет запрос:
Authorization: Bearer <token>
↓
Сервер проверяет подпись, срок и claims
↓
Возвращает защищённые данные

Но серверу недостаточно проверить только подпись.

Также важно проверять:

• срок действия токена;

• разрешённый алгоритм подписи;

• издателя iss;

• получателя aud;

• права пользователя;

• актуальность аккаунта и сессии;

• соответствие токена требованиям конкретного API.

JWT — не волшебный щит. Если настроить проверку неправильно, длинная строка не спасёт систему.

🧯 Что делать, если токен уже утёк?

Первое правило — не надеяться, что «никто не заметил».

1. Отозвать или заблокировать сессию, если система это поддерживает.

2. Заменить связанные секреты, если утёк не только токен, но и ключ подписи.

3. Удалить токен из сообщений, логов и репозиториев, где это возможно.

4. Проверить историю действий пользователя.

5. Выпустить новые токены.

6. Разобраться, как произошла утечка, и закрыть канал повторной публикации.

Если токен попал в Git, простого удаления строки из текущего файла может быть недостаточно. Нужно считать токен скомпрометированным и заменить его.

💙 Разбирайся в backend не только по мемам

JWT становится понятным не тогда, когда ты десятый раз прочитал определение, а когда самостоятельно сделал авторизацию, защитил маршрут, отправил запрос с токеном и получил свой первый легендарный 401 Unauthorized.

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

А в нашем Telegram-сообществе регулярно выходят полезные посты, короткие разборы, подсказки и материалы для повторения программирования в удобном формате. Можно зайти на несколько минут, освежить тему и снова почувствовать себя человеком, который точно помнит разницу между аутентификацией и авторизацией. 😄

🎯 Главное о JWT

• JWT помогает подтверждать личность и права пользователя между запросами.

• Обычный подписанный JWT не скрывает содержимое payload.

• Подпись защищает данные от незаметного изменения.

• Рабочий bearer-токен нельзя публиковать, пересылать или вставлять в случайные сервисы.

• Короткий срок жизни уменьшает последствия кражи access token.

• Хранение токена нужно выбирать с учётом XSS, CSRF и архитектуры приложения.

• JWT безопасен только тогда, когда правильно реализована вся система вокруг него.

Запомни простое правило: если кто-то получил твой рабочий JWT, сервер может принять этого человека за тебя.

Поэтому относись к токену не как к случайной строке из DevTools, а как к цифровому пропуску, который не стоит раздавать всем участникам чата. 🔐