Разложить по полочкам

• Идентификация: ты предъявляешь идентификатор (логин, email, client_id). Сама по себе она ничего не доказывает.
• Аутентификация (AuthN) проверяет доказательство: пароль, одноразовый код, подпись JWT, клиентский сертификат mTLS. После неё «мы знаем, кто это».
• Авторизация (AuthZ) - решение о доступе к конкретному ресурсу и действию: роль, право, политика, владение объектом. На выходе «можно/нельзя».
• Аудит записывает, кто что сделал. Про него часто забывают, а на собесе в финтехе спрашивают отдельно.

Почему путаница живучая

Виноват сам HTTP: статус 401 называется Unauthorized, хотя означает «не аутентифицирован». По смыслу 401 говорит «предъяви (другие) учётные данные» и обязан нести заголовок WWW-Authenticate, а 403 значит «мы поняли, кто ты, и тебе нельзя»: перевыпуск токена тут не поможет.

Практическое следствие для кода

Это два разных слоя. Аутентификацию делает общий middleware на всё приложение: разбирает заголовок, проверяет подпись или сессию, кладёт subject в контекст. Авторизация живёт ближе к домену. Middleware закрывает грубые вещи (роль admin на /admin/*), а «этот заказ принадлежит этому пользователю» можно проверить только там, где известен заказ, то есть в сервисном слое.

Сравнение по осям

Главный аргумент, который ждут

Стоит приделать к JWT чёрный список отозванных токенов, и в Redis придётся ходить на каждый запрос. Возвращается ровно та зависимость, от которой JWT и должен был избавить. Поэтому формулировка такая: JWT покупает дешёвую распределённую проверку ценой окна, в котором токен не отозвать; окно равно TTL токена. Всё проектирование сводится к тому, чтобы окно было маленьким (5–15 минут) и закрывалось refresh-токеном, у которого состояние уже есть.

Как выбирать

• Классическому веб-приложению с одним бэкендом и браузерными клиентами хватит сессий: проще, безопаснее, отзыв бесплатный. Это до сих пор дефолт, а не легаси.
• Публичный API, мобильные клиенты, десяток сервисов, которым нужно проверять токен без общего стора - JWT (короткий access + серверный refresh).
• В проде чаще всего побеждает гибрид: JWT-access на 10 минут для межсервисных проверок + серверная запись о сессии/refresh для отзыва и списка устройств.

Структура

// eyJhbGciOi… . eyJzdWIiOi… . 4pcPyMD0…   (три части base64url через точку)
// header:    {"alg":"HS256","typ":"JWT","kid":"2024-06"}
// payload:   {"sub":"123","exp":1700000000,"iat":...,"iss":"api","aud":"web","jti":"..."}
// signature: HMAC-SHA256(base64url(header) + "." + base64url(payload), secret)

Вслух обязательно скажи: base64 не шифрует. Payload читает любой, у кого есть токен, поэтому персональные данные, внутренние идентификаторы и суммы в токен не кладут. Подпись гарантирует целостность и авторство, а не конфиденциальность (для шифрования есть JWE, отдельная спецификация, в вебе она почти не встречается).

HS256 против RS256

Где хранить на клиенте

• localStorage доступен любому JS на странице, так что любой XSS = кража токена. Зато CSRF ему не страшен: браузер сам ничего оттуда не отправляет.
• httpOnly; Secure; SameSite=Lax-куку JS не прочитает, и XSS её не украдёт. Но браузер прикрепляет её сам, поэтому нужна защита от CSRF (SameSite плюс, для критичных операций, токен).
• Мобильное приложение - Keychain/Keystore, не SharedPreferences.
• Продвинутый вариант для SPA: access-токен живёт только в памяти JS (в переменной, не в хранилище), refresh лежит в httpOnly-куке с узким Path=/auth/refresh. После перезагрузки вкладки срабатывает тихий refresh.

Срок жизни

Access живёт 5–15 минут, и это окно, в котором отозванный доступ ещё работает. Refresh живёт от нескольких дней до месяца, с ротацией. Обязательные поля: exp (иначе токен вечный), iat, iss и aud (иначе токен от соседнего сервиса примут как свой), а если нужен поштучный отзыв, ещё и jti. alg проверяют по белому списку своих алгоритмов, а не берут из заголовка токена, иначе открываются классические атаки alg: none и подмена RS256 на HS256 с публичным ключом в роли секрета.

Зачем разделение

Будь токен один, пришлось бы выбирать между удобством (долгий TTL, пользователя не разлогинивает) и безопасностью (короткий TTL, украденный токен быстро протухает). Два токена снимают этот компромисс: короткий access ограничивает ущерб от утечки, долгий refresh держит сессию. К тому же на refresh сервер обязательно идёт в своё хранилище и заодно может проверить, не забанен ли пользователь, не сменился ли пароль, не отозвано ли устройство.

Ротация (rotation)

На каждый обмен выдаётся новый refresh, старый помечается использованным. Токен становится одноразовым, и «украл один раз - пользуюсь вечно» перестаёт работать.

// обмен уже потраченного refresh = сигнал кражи
row, err := repo.GetRefresh(ctx, hash(presented))
switch {
case err != nil:
    return ErrInvalid
case row.UsedAt != nil:                 // токен уже обменивали
    repo.RevokeFamily(ctx, row.FamilyID) // рвём всю цепочку: и вора, и жертву
    audit.Warn("refresh reuse", "user", row.UserID)
    return ErrInvalid
case time.Now().After(row.ExpiresAt):
    return ErrExpired
}
newRT := random256()
repo.MarkUsedAndIssue(ctx, row.ID, hash(newRT), row.FamilyID)

Reuse detection

Идея взята из RFC 6819 и BCP по OAuth: у всех токенов одной сессии общий family_id. Если предъявлен уже использованный refresh, значит, копия токена есть у двоих: у вора и у жертвы. Кто из них пришёл, серверу неизвестно, поэтому убивают всю семью: настоящий пользователь просто перелогинится, а вор потеряет доступ. Так кражу ловят дёшево, без хитрого фингерпринтинга.

Отзыв и хранение

• Refresh хранят хешированным (SHA-256), и утёкший дамп таблицы не даёт рабочих токенов.
• Строка в БД: user_id, family_id, token_hash, expires_at, used_at, revoked_at, user_agent, ip, device_name. Из неё же вырастает экран «активные сессии».
• Для отзыва проставляют revoked_at одной записи, семье или всем записям пользователя. Отсюда три кнопки: «выйти», «выйти на этом устройстве», «выйти везде».
• Смена пароля обязана отзывать все refresh (кроме, по вкусу, текущей сессии).
• Refresh кладут в куку httpOnly; Secure; SameSite=Strict; Path=/auth/refresh: браузер не потащит его в обычные запросы, а XSS не прочитает.

Варианты по возрастанию цены

1. Просто выбросить токен на клиенте + отозвать refresh на сервере. Access живёт свои 5–15 минут. Для 95 % продуктов этого достаточно, и такой ответ вполне годится.
2. Чёрный список по jti: SET revoked:jti 1 EX ttl_остаток. Ключ исчезнет сам, когда истечёт токен, поэтому список остаётся маленьким. Платишь за это GET в Redis на каждый запрос.
3. Версия токенов пользователя (token_version/epoch): в payload кладём номер, в БД держим текущий. «Выйти везде» = инкремент. Проверка сводится к сравнению чисел и кэшируется в памяти инстанса с TTL 30 с. Это на порядок дешевле чёрного списка и покрывает главный сценарий.
4. Не выдавать access вообще и вернуться к сессиям. Иногда это правильный ответ.

// вариант 3: одна цифра решает 90% задач отзыва
type Claims struct {
    jwt.RegisteredClaims
    Ver int `json:"ver"`
}
// при логауте-везде / смене пароля / бане:
//   UPDATE users SET token_version = token_version + 1 WHERE id = $1
func (a *Auth) check(ctx context.Context, c Claims) error {
    cur, err := a.verCache.Get(ctx, c.Subject) // локальный кэш на 30 секунд
    if err != nil { return err }
    if c.Ver != cur { return ErrRevoked }
    return nil
}

Что сказать, чтобы прозвучало зрело

«Логаут с JWT упирается не в технику, а в решение, какое окно рассинхронизации мы готовы терпеть. Ноль секунд стоит запроса в стор на каждый вызов, то есть возврата к состоянию. Пять минут бесплатны». Дальше отдельно проговори сценарии, где нужен именно ноль: увольнение сотрудника, компрометация устройства, бан за фрод, отзыв прав в админке. Для них обычно делают гибрид: короткий TTL для всех + чёрный список только для критичных ролей или только для эндпоинтов с деньгами.

Четыре роли

• Resource Owner - пользователь, владелец данных.
• Client - приложение, которое хочет доступ (твой бэкенд или SPA).
• Authorization Server выдаёт токены (Google, Keycloak, Auth0).
• Resource Server - API, которое проверяет токен и отдаёт данные.

Authorization code flow + PKCE

1. Клиент редиректит браузер на /authorize с response_type=code, client_id, redirect_uri, scope, state и code_challenge.
2. Пользователь логинится на стороне провайдера и подтверждает согласие. Твоё приложение пароля не видит, в этом и весь смысл.
3. Провайдер редиректит обратно на redirect_uri?code=...&state=.... Одноразовый код живёт секунды.
4. Бэкенд меняет код на токены запросом server-to-server на /token, предъявляя client_secret (или code_verifier для публичных клиентов).
5. Получает access_token, refresh_token и, в случае OIDC, id_token.

Почему через код, а не сразу токен? Код летит через адресную строку браузера и оседает в истории, в логах прокси, в Referer. Поэтому в редиректе едет одноразовый код, бесполезный сам по себе, а настоящие токены приходят по защищённому каналу, куда браузер не заглядывает. Устаревший implicit flow отдавал токен прямо во фрагменте URL; сейчас его считают небезопасным, и в OAuth 2.1 он запрещён.

Два параметра, о которых спрашивают

• state - случайное значение: его кладут в сессию и сверяют на возврате. Так флоу защищён от CSRF (иначе атакующий подсунет свой код и привяжет твой аккаунт к своему).
• В PKCE клиент генерирует code_verifier, шлёт его SHA-256 как code_challenge, а при обмене предъявляет оригинал. Без verifier перехваченный код бесполезен. PKCE обязателен для SPA и мобильных (секрета там нет), а по OAuth 2.1 - вообще для всех.

Чем OIDC отличается

access_token в OAuth говорит «предъявитель имеет право на такие-то действия». Он адресован API, и клиенту разбирать его вообще не положено. id_token в OIDC всегда JWT, он адресован клиенту и говорит «этот пользователь только что аутентифицирован там-то»: sub, iss, aud, nonce, auth_time, профиль. Ещё OIDC стандартизует /.well-known/openid-configuration, JWKS-эндпоинт с публичными ключами и /userinfo. Часто ошибаются, принимая access_token за доказательство личности, а он может оказаться непрозрачной строкой, в которой нет вообще ничего.

Basic auth

Это Authorization: Basic base64(user:pass), то есть пароль в открытом виде в каждом запросе: base64 ни от кого не защищает. Без TLS применять нельзя категорически. Логаута нет, истечения нет, браузер кэширует учётку и подставляет её сам. Уместен он там, где надо закрыть /metrics и /debug/pprof или стенд от посторонних, и в простой интеграции со скриптом на cron, где TLS есть и ротация не нужна. На сервере сравнивать обязательно через subtle.ConstantTimeCompare.

API-ключи

// ключ отдаём один раз при создании, в БД только хеш и префикс
key := "sk_live_" + base64url(random(24))          // 192 бита энтропии
row := APIKey{
    Prefix:    key[:14],                            // для поиска и показа в UI
    Hash:      sha256.Sum256([]byte(key)),          // быстрый хеш ок: секрет высокоэнтропийный
    Scopes:    []string{"orders:read"},
    ExpiresAt: time.Now().AddDate(1, 0, 0),
}
// проверка: находим по префиксу, сравниваем хеши constant-time

Почему для ключа хватает SHA-256, а для пароля нет? Пароль придумывает человек, энтропии в нём мало, и его подбирают по словарю. Случайный 192-битный ключ перебрать нельзя, а медленная KDF только жжёт CPU на каждом запросе.

Правила, которые ждут в ответе

• Ключ передают в заголовке (Authorization: Bearer или X-API-Key), никогда в query: URL пишется в access-логи, прокси и Referer.
• У каждого ключа свои скоупы и права, на каждую интеграцию отдельный ключ, чтобы отзыв одного не ломал остальные.
• Срок жизни и ротация: на время переключения можно держать два активных ключа.
• Rate limit по ключу, лог использования, дата последнего применения.
• Для вебхуков наружу лучше не ключ, а HMAC-подпись тела с меткой времени (X-Signature, X-Timestamp): секрет вовсе не передаётся, а метка защищает от повторной отправки.
• Самый серьёзный вариант для межсервисного трафика - mTLS: клиентский сертификат вместо строки, отзыв через CRL, срок жизни короткий.

RBAC

Пользователь → роли → права (permissions), права проверяются в коде. Проверять надо право, а не роль. if user.Role == "admin" закладывает бомбу замедленного действия: появится второй тип админа, и придётся править сотню мест. if user.Can("order:cancel") переживёт и новые роли, и их перекройку. RBAC понятен бизнесу и легко ложится на интерфейс администратора.

ABAC

Решение принимает политика по кортежу атрибутов: кто (роль, отдел, стаж), что (владелец объекта, статус, сумма), в каком контексте (время, IP, был ли MFA). Так выражается то, что RBAC не умеет: «сумму больше миллиона согласует только руководитель», «к персональным данным пускать только из офисной сети». Реализуют это кодом в сервисном слое или отдельным движком политик (OPA/Rego, Casbin, Cedar). Платишь за это более сложной отладкой («почему отказ?») и аудитом решений.

Middleware

func RequirePerm(p string) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            u, ok := auth.From(r.Context())     // положил middleware аутентификации
            if !ok { fail(w, 401); return }
            if !u.Can(p) { fail(w, 403); return }
            next.ServeHTTP(w, r)
        })
    }
}
r.With(RequirePerm("order:cancel")).Post("/orders/{id}/cancel", h.Cancel)

// а это middleware сделать не может, он не знает, чей это заказ:
func (s *Service) Cancel(ctx context.Context, orderID, userID int64) error {
    o, err := s.repo.Get(ctx, orderID)
    if err != nil { return err }
    if u, _ := auth.From(ctx); o.UserID != userID && !u.Can("order:cancel:any") {
        return ErrForbidden           // отдать наружу как 404, если факт существования секретен
    }
    ...
}

Главные грабли

• Авторизация только в middleware даёт IDOR: право «отменять заказы» есть, а что заказ чужой, никто не проверил.
• Fail-open: нет токена → в контексте пустой пользователь → политика «нет запрета» → пускаем. По умолчанию должно быть «запрещено»: безопаснее закрыть роутер целиком и явно пометить публичные маршруты, чем наоборот.
• Права в JWT удобны (ноль запросов), но протухают до конца TTL; критичные права лучше читать из источника истины.
• Полезный тест: пройтись по всем зарегистрированным роутам и убедиться, что у каждого есть политика. Иначе однажды новый эндпоинт приедет голым.

Почему быстрые хеши не годятся

Стойкость к перебору упирается не в математику, а в стоимость одной попытки. У SHA-256 она измеряется наносекундами, так что утёкшая база с SHA-хешами фактически и есть база паролей: 8-символьные пароли перебираются полностью, остальное ловят словарями с правилами мутаций. Медленная KDF поднимает цену попытки до ~250 мс, и перебор перестаёт окупаться. А memory-hard функции (scrypt, argon2) вдобавок требуют десятки мегабайт на попытку, и у GPU с ASIC пропадает преимущество: памяти на ядро у них мало.

Соль и перец

• Соль - уникальная случайная строка на каждый пароль, лежит рядом с хешем открыто. Прятать пароль она не должна. Она ломает rainbow-таблицы, даёт одинаковым паролям разные хеши (иначе по базе видно, у кого пароль 123456) и не даёт атаковать всю базу разом.
• Перец - общий секрет вне БД (Vault, HSM, конфиг). Его подмешивают к паролю или берут ключом HMAC поверх хеша. Если утекла только база, хеши бесполезны. Минус: перец трудно ротировать.
• В bcrypt соль зашита в саму строку хеша, генерировать её руками не надо, а в argon2 соль и параметры хранишь сам.

Что ещё обязательно назвать

• Constant-time сравнение результата (subtle.ConstantTimeCompare, у bcrypt - CompareHashAndPassword).
• User enumeration: для несуществующего логина всё равно прогонять фиктивный хеш и отвечать одинаковым «неверный логин или пароль», иначе аккаунты вычисляются по времени ответа.
• Ротация параметров: cost хранится в самом хеше; если при успешном логине параметры оказались устаревшими, хеш пересчитывают, ведь только в этот момент открытый пароль есть на руках.
• Rate limit и блокировка после серии неудач: без них медленная KDF не спасёт от онлайн-перебора вроде password spraying или credential stuffing.
• Ограничение bcrypt: он учитывает только первые 72 байта пароля. В Go GenerateFromPassword на более длинном вернёт ErrPasswordTooLong, поэтому длинную парольную фразу заранее сворачивают в SHA-256 или берут argon2id.
• Не требуй «спецсимвол и смену раз в 90 дней»: актуальный NIST советует длину, проверку по списку скомпрометированных паролей и никакой принудительной ротации.

Лестница зрелости

1. Хардкод в коде - катастрофа: секрет в git навсегда, у всех форков и в CI-кэшах.
2. Переменные окружения по 12-factor дают минимальный приемлемый уровень. Минусы: видны в /proc/PID/environ, в docker inspect, утекают в краш-репорты; ротация = рестарт.
3. Файл, смонтированный в контейнер, можно обновить без рестарта, на него действуют права доступа; приложение должно уметь перечитывать его по сигналу.
4. Kubernetes Secret: RBAC, монтирование как файл или env. Обязательно проговори: это base64, а не шифрование, и без включённого encryption-at-rest в etcd секрет лежит практически открытым.
5. Vault / KMS дают централизованное хранение, аудит доступа, TTL, автоматическую ротацию, динамические секреты. Взамен получаешь ещё одну зависимость в рантайме и задачу аутентифицировать само приложение.

AppRole в двух предложениях

У сервиса есть role_id (не секрет, лежит в конфиге) и secret_id (короткоживущий, его доставляют отдельно, оркестратором или через response wrapping). Пару меняют на токен с TTL, приложение периодически его продлевает и по нему читает секреты. Артефактов два, чтобы утечка одного не давала доступ. Отдельный козырь Vault - динамические секреты: он сам заводит временного пользователя в PostgreSQL с TTL в час, и красть пароль от базы становится почти бессмысленно.

Ротация как рутина

Ротация должна быть скучной операцией, а не подвигом. Для этого приложение держит два действующих значения одновременно: два ключа подписи с разными kid (выкатили новый на проверку → переключили подпись → сняли старый через окно), старый и новый пароль БД, два API-ключа у интеграции. Тогда секрет меняется без одномоментного рестарта всего.