Ответ
JWT (JSON Web Token) — это открытый стандарт (RFC 7519) для создания токенов доступа, которые представляют собой компактные, самодостаточные и подписанные JSON-объекты.
Основные особенности:
- Самодостаточность (Self-contained): Полезная нагрузка токена (payload) содержит все необходимые утверждения (claims), такие как идентификатор пользователя (
sub), срок действия (exp) и роли. Серверу не нужно обращаться к базе данных для проверки этих данных, достаточно верифицировать подпись. - Цифровая подпись: Токен подписывается с использованием секретного ключа (алгоритмы HMAC, например, HS256) или пары публичный/приватный ключ (алгоритмы RSA/ECDSA). Подпись гарантирует целостность данных (они не были изменены) и, в случае асимметричных алгоритмов, аутентичность отправителя.
- Stateless (Бессостоятельность): Серверу аутентификации не требуется хранить состояние сессии. Это упрощает архитектуру и повышает масштабируемость.
- Компактность: Токен кодируется в формате Base64Url, что делает его удобным для передачи через URL, параметры запроса или заголовки (чаще всего
Authorization: Bearer <token>).
Структура JWT (Header.Payload.Signature):
// Header (алгоритм и тип токена)
{
"alg": "HS256",
"typ": "JWT"
}
// Payload (данные/утверждения)
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022,
"exp": 1516242622
}
// Signature
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)Практическое применение:
- Аутентификация/Авторизация: После ввода логина/пароля сервер выдает JWT, который клиент отправляет с каждым последующим запросом.
- Обмен данными между сервисами: Безопасная передача информации между микросервисами в рамках единой экосистемы.
Важное предупреждение: Полезная нагрузка JWT (Payload) не зашифрована, а лишь закодирована в Base64. Ее может прочитать любой, у кого есть токен. Не храните в ней конфиденциальные данные (пароли, ключи). Для конфиденциальности используйте шифрование (JWE).
Ответ 18+ 🔞
А, слушай, про эти ваши JWTшки! Ну, стандарт такой, RFC 7519, если по-умному. По сути, это такая бумажка-пропуск, только в цифре, и сделана из JSON'а. Компактная, самодостаточная и подписанная, блядь.
Чем она хороша, эта штука:
- Сама себе начальник (Self-contained): Внутри этой бумажки уже всё написано: кто ты (
sub), когда твой пропуск сдохнет (exp), какие у тебя права. Серверу не нужно, как последнему идиоту, бегать в базу и спрашивать «а кто это тут у нас?». Проверил подпись — и всё, хуй с горы, пускай дальше. - Цифровая подпись, ёпта: Это самое главное! Токен подписывается либо секретным ключом (алгоритмы типа HS256), либо парой ключей — публичным и приватным (RSA, ECDSA). Подпись — это как печать. Если кто-то попробует в середине что-то поменять, типа срок действия продлить, то подпись не сойдётся, и всё, пиздец, доверия ебать ноль. А если ключи асимметричные, то ещё и понятно, кто именно эту хрень выпустил.
- Stateless (Бессостоятельность): Серверу, который выпустил токен, можно потом на него забить хуй. Он не обязан помнить каждый выданный пропуск. Клиент сам его таскает и предъявляет. Архитектура проще, масштабироваться легче — красота!
- Компактность: Всё это добро кодируется в Base64Url, так что его можно и в URL воткнуть, и в заголовок запихнуть. Чаще всего таскают так:
Authorization: Bearer <ваш_токен_тут>. Удобно, блядь.
Из чего эта хрень состоит (Header.Payload.Signature):
Смотри, три части, разделённые точками.
// Header (Тут написано, как токен сделан)
{
"alg": "HS256", // Алгоритм подписи, например, HMAC-SHA256
"typ": "JWT" // Тип — JWT, что же ещё
}
// Payload (А тут уже данные, «утверждения»)
{
"sub": "1234567890", // Subject — кто (ID пользователя)
"name": "John Doe", // Имя, например
"iat": 1516239022, // Issued at — когда выпущен
"exp": 1516242622 // Expiration — когда протухнет
}
// Signature (А это самая важная часть — подпись)
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret // Вот этот самый секретный ключ
)Где эту херовину применяют:
- Вход на сайт/в приложение: Пользователь ввёл логин-пароль, сервер проверил, выдал JWT и говорит: «На, мудила, таскай, это твой пропуск». И дальше с каждым запросом клиент этот токен и подсовывает.
- Общение между сервисами: Микросервисы в одной системе могут безопасно передавать друг другу информацию внутри такого токена.
НО! ВАЖНЕЙШЕЕ ПРЕДУПРЕЖДЕНИЕ, БЛЯДЬ! Полезная нагрузка (Payload) — НЕ ЗАШИФРОВАНА. Она просто закодирована в Base64, что читается легче, чем газета. Любой, у кого есть токен, может его разобрать и прочитать, что внутри. НЕ ПИХАЙТЕ ТУДА ПАРОЛИ, КЛЮЧИ ИЛИ ДРУГУЮ ХУЙНЮ, КОТОРУЮ НЕЛЬЗЯ СВЕТИТЬ! Это как писать свой пароль на лбу маркером. Если нужна секретность — используйте JWE (JSON Web Encryption), там уже с шифрованием. А JWT — в основном для целостности и аутентичности. Запомни это, а то потом будешь охуевать, как твои данные утекли.