Вставьте токен и посмотрите, что внутри: header, payload и срок действия. Разбор идёт в браузере, токен никуда не отправляется.
Декодирование не равно проверке подписи. Содержимое JWT не зашифровано, его читает кто угодно. Этот инструмент только раскрывает payload и не подтверждает, что токен подлинный. Подпись проверяют на сервере секретным ключом. Данные никуда не отправляются и остаются в вашем браузере.
JSON Web Token состоит из трёх частей, разделённых точками: header, payload и подпись. Первые две — это обычный JSON, закодированный в base64url. Третья считается по ним с помощью секретного ключа.
В header лежит алгоритм подписи (`alg`) и тип токена (`typ`). В payload — утверждения о пользователе и сроках: кто он, когда токен выпущен и до какого момента действует. Подпись позволяет серверу убедиться, что содержимое не подменяли.
Токен часто воспринимают как что-то зашифрованное. Это не так: base64url — кодировка, а не шифрование, и раскодировать её может кто угодно без всякого ключа. Именно поэтому этот инструмент работает без секрета.
Практический вывод: payload видят все. Туда не кладут пароли, платёжные данные и персональные сведения, которые не должны утечь вместе с токеном. Подпись защищает от подмены содержимого, но не скрывает его.
При отладке авторизации — посмотреть, какие права уехали в токен и не истёк ли он. Ошибка 401 при живом на вид токене чаще всего объясняется именно просроченным `exp` или расхождением часов между серверами.
При интеграции с чужим API — понять, что кладёт в токен партнёр и на какие поля можно опираться. Подробнее про сам процесс подключения мы написали в статье про OAuth 2.0 для интеграций.
При разборе инцидентов — быстро сверить, каким пользователем и когда был выпущен токен из лога, не поднимая для этого отдельный скрипт.
Всё о разборе JWT
Нет. Header и payload закодированы в base64url, а не зашифрованы. Любой, кто получил токен, прочитает его содержимое. Поэтому в payload нельзя класть пароли, номера карт и другие чувствительные данные — подпись защищает от подделки, но не от чтения.
Декодирование просто раскрывает содержимое и доступно кому угодно без ключа. Проверка подписи подтверждает, что токен выпустили вы и что его не меняли, и требует секретного ключа. Проверять подпись нужно на сервере — ни один онлайн-декодер этого сделать не может и не должен.
Нет. Разбор идёт целиком в вашем браузере средствами JavaScript. Ни сам токен, ни его части не уходят на сервер и никуда не записываются.
Это стандартные временные поля в секундах Unix. exp — момент, после которого токен считается недействительным. iat — когда токен выпустили. nbf — момент, раньше которого токен принимать нельзя. Инструмент переводит их в обычную дату и отмечает, если срок уже истёк.
Чаще всего в токене оказывается не три части, разделённые точками, а меньше — например, при копировании потерялся хвост или лишний пробел разорвал строку. Второй частый случай: скопирован не сам токен, а строка вида «Bearer eyJ…» вместе с префиксом.
Отображать данные из payload на фронтенде можно, а принимать по ним решения о доступе — нет. Клиент не проверяет подпись, поэтому payload там можно подменить. Любое решение о правах принимается на сервере после проверки подписи.
Спроектируем обмен с чужим API, разберёмся с токенами и правами доступа и возьмём интеграцию на поддержку.
Где хранить ключи, таймауты, ретраи и идемпотентность — семь ошибок, которые вылезают только в проде
Authorization Code с PKCE по шагам: state, redirect_uri, хранение токенов и обновление refresh
Подключим сторонние сервисы, настроим обмен данными и возьмём интеграции на поддержку