Какие знаешь JWT Token

А, вот это, блядь, JWT! Ну, хули тут непонятного, ебать мои старые костыли. Это ж просто три кусочка текста, склеенные точками, которые все внезапно считают панацеей от всех бед, а потом удивляются, хули у них токены тырят.

Смотри, как оно устроено, ёпта. Три части, как у хорошего анекдота: завязка, кульминация и пиздец.

Первая — это Header (заголовок). Там написано, какой алгоритм шифрования и что это вообще за хуйня. Типа {"alg": "HS256", "typ": "JWT"}. Потом эту хуйню кодируют в Base64, и всё, первый кусок готов. Никакой тайны, всё открытым текстом, любой может прочитать.

Вторая — это Payload (нагрузка, полезная хуйня). Вот тут уже интереснее. Ты туда можешь запихнуть что угодно: user_id, имя, срок годности (exp). Всякие claims, блядь. Это тоже в Base64, так что не вздумай туда пароли или номер карты совать, ёбаный в рот! Любой школьник декодит и прочитает. Это как написать любовную записку и повесить на всеобщее обозрение.

Третья — это Signature (подпись). А вот это уже серьёзно, блядь. Берут первые две части (хедер и пейлоад), секретный ключ (который должен быть овердохуища сложным, а не "12345"), и всё это скрепляют выбранным алгоритмом. Получается этакая печать. Если кто-то попробует изменить хоть одну букву в первых двух частях — подпись не сойдётся, и токен станет бесполезным куском цифрового говна.

Вот тебе пример, как эта ебаная строка выглядит:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Точки разделяют. Первый кусок — хедер, второй — пейлоад, третий — подпись. Красота, блядь.

А теперь про типы, потому что один токен — это хуйня. Их обычно два:

• Access Token (токен доступа): Короткоживущий засланец. Живёт минуты или часы. С ним ты ходишь по API и просишь: "Дай мне данные пользователя, ёпта". Как только срок вышел — в пизду, недействителен.
• Refresh Token (токен обновления): Долгоживущая палочка-выручалочка. Хранится где-то подальше и безопасно. Когда access token сдох, ты предъявляешь этот refresh token, и тебе выдают новую парочку (access + refresh). Хитро, да? Но если этот рефреш-токен утечёт — пиши пропало, злоумышленник сможет получать новые ключи от твоего королевства до скончания времён.

Безопасность, ага, щас. Тут волнение ебать начинается у всех. Где хранить? Два лагеря, блядь:

1. В HttpOnly куках. Защита от XSS-атак (скрипт не доберётся до токена), но можно нарваться на CSRF. Нужно ставить дополнительные защиты.
2. В localStorage. Легко брать на клиенте для отправки в заголовках, но любой XSS-скрипт вытащит его за секунду. Доверия ебать ноль к безопасности фронтенда.

И главное — всегда проверяй подпись на бэкенде! И срок годности (exp). А то будут подсовывать тебе токены, которые они сами на коленке склепали. Сервер должен каждый раз говорить: "А ну-ка, покажи-ка подпись, дружок".

Вот, например, как на Node.js проверить:

// БЛОК КОДА НЕ ТРОГАЕМ, ОН СВЯЩЕНЕН
const decoded = jwt.verify(token, 'secret-key');

Видишь? jwt.verify. Он и проверит подпись, и выкинет ошибку, если токен просрочен или подделан. Не jwt.decode, который просто разберёт на части, а именно verify, ёпта!

Вот и вся магия. Не серебряная пуля, а просто инструмент. Используй с мозгом, а не потому что это модно. А то будет как с тем Герасимом — сделаешь хуйню, а потом совесть загложет, блядь.