JWT (JSON Web Token): плюсы, минусы и основные риски безопасности

Так, слушай, про эти ваши JWT. Сижу тут, думаю, ну что за мода пошла — все как с ума посходили, везде их суют, прям панацея какая-то. А на деле-то, блядь, как всегда, не всё так радужно, ёпта.

Ну, JWT — это, грубо говоря, такая бумажка, билетик. Состоит из трёх кусков, склеенных точками. Первый — заголовок, там написано, какой алгоритм подписи. Второй — полезняк, там твой ID, роли, срок годности. Третий — подпись, чтобы не подделали. Всё это в JSON заворачивается и кодируется. Вроде бы красиво.

Чем хороши, эти ваши билетики?

• Stateless, ёбта! Серверу не нужно помнить, кто ты такой. Всё про тебя написано прямо в токене. Пришёл — показал билетик — тебя опознали. Серверу не нужно заводить на тебя папочку в памяти или в базе. Архитектура проще, голова не болит.
• Масштабируется, как сумасшедший. Раз серверу нихуя не надо помнить, то хоть тысяча серверов тебя примут. Кинул запрос на любой — он токен проверил и всё. Для микросервисов — просто песня.
• Не подделаешь. Подпись-то проверяется секретным ключом. Попробуй что-то в полезной нагрузке поменять — подпись не сойдётся, и тебя, пидораса шерстяного, нахуй пошлют.
• Междоменный. Кинул его в заголовок Authorization: Bearer <токен> — и всё, лети себе между frontend.com и api.backend.com. CORS только разреши.

А теперь, блядь, ложка дёгтя, размером с лопату. Минусы, на которых все обжигаются.

• Главная жопа — отозвать его нихуя нельзя. Украли у тебя токен? Ну всё, пиздец. Он будет работать, пока не истечёт срок. Это как потерять пропуск на завод — любой найдёт и пройдёт. Что делать? Делать токены короткоживущими, на 5-15 минут. А для обновления — отдельный, долгоживущий refresh-токен, который хранишь как зеницу ока и можешь отозвать в случае чего.
• Толстый он, сука. Не сравнить с какой-нибудь сессионной кукой. Тащить его в каждом запросе — трафик чуть подрастёт.
• Где хранить-то, мудя?
  • В localStorage? Да ты охренел? Любой XSS-скрипт на странице вытащит его и унесёт в закат. НИКОГДА.
  • В куках с HttpOnly и Secure? Вот это уже умнее. Из JS не достанешь, и летит только по HTTPS. Но тут свои танцы с CORS и CSRF начинаются. В общем, думай, блядь, голова дана не только для еды.
• Данные не шифрованы, ёпта! Полезная нагрузка просто в Base64 закодирована. Раскодируй — и читай на здоровье. НИКОГДА НЕ ПИХАЙ ТУДА ПАРОЛИ, НОМЕРА КАРТОЧЕК И ПРОЧУЮ ХУЙНЮ! Это не для секретов. Хочешь секреты — смотри в сторону JWE.

// Вот, смотри, как на Go эту хрень генерить. Библиотека github.com/golang-jwt/jwt
import (
    "time"
    "github.com/golang-jwt/jwt/v5" // версия-то новая, блядь, v5
)

// Секретный ключ. Спрячь его, идиот! В переменные окружения, в спец. хранилище — куда угодно, только не в код.
var jwtKey = []byte("мой_супер_пупер_секрет_который_никто_не_угадает")

func слепитьТокен(userID int) (string, error) {
    // Срок годности ставим. 15 минут — и в утиль.
    expirationTime := time.Now().Add(15 * time.Minute)

    // Полезная нагрузка. Subject — обычно ID юзера.
    claims := &jwt.RegisteredClaims{
        Subject:   fmt.Sprintf("%d", userID), // Переводим int в string, а то обосрёшься
        ExpiresAt: jwt.NewNumericDate(expirationTime),
    }

    // Лепим токен с алгоритмом HS256.
    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)

    // Подписываем своим ключом. Всё, готово, неси на кассу.
    return token.SignedString(jwtKey)
}

Вот и вся магия. Инструмент, в общем, мощный, но если им как молотком гвозди забивать — себе же пальцы отобьёшь. Думай, где и как применяешь, и про безопасность не забывай, а то охуеешь потом от последствий.