Мини OAuth 2.0 + PKCE логин

Подними минимальный authorization-сервер: эндпойнт /authorize, принимающий client_id, redirect_uri, response_type=code, scope и PKCE code_challenge (только S256 — plain отклоняй), и клиент, инициирующий поток. Authorization code — это одноразовый короткоживущий носитель намерения: держи его TTL жёстким (30–60 с, единственное использование), потому что он идёт через браузер и query-строку редиректа — самый открытый участок всего потока. PKCE привязывает будущий обмен токена к браузеру, который его начал: клиент генерирует code_verifier из 43–128 символов высокой энтропии (≥256 бит из CSPRNG), отправляет вперёд только его SHA-256 challenge и раскрывает verifier на шаге токена — так что перехваченный код бесполезен без verifier. Компромисс: PKCE не добавляет хранимого на сервере секрета (в отличие от секрета конфиденциального клиента) — именно поэтому он обязателен для публичных/нативных клиентов, которые секрет хранить не могут.

Построй эндпойнт /token, который меняет code + code_verifier на access-токен и refresh-токен. Проверь verifier (SHA-256(code_verifier) == сохранённый challenge) и атомарно погаси код, чтобы повторно отправленный код проваливался. Подписывай access-токены как JWT асимметричным ключом (RS256/ES256, не HS256 — ресурс-серверы должны проверять публичным ключом и никогда не получать секрет подписи), держи TTL access-токена коротким (5–15 мин), чтобы утёкший токен быстро истекал, а refresh-токены делай долгоживущими непрозрачными хендлами. Опубликуй JWKS-эндпойнт с kid в заголовке каждого токена, чтобы ротировать ключи подписи без простоя: вкати новый ключ, отдавай оба в JWKS в окне перекрытия (≥ максимального TTL токена), затем выведи старый kid. Компромисс: самодостаточные JWT (без обращения на introspection, но живой нельзя отозвать) против непрозрачных токенов (отзываемы, но каждая проверка — сетевой хоп).

Соедини клиент relying-party с твоим сервером от и до и валидируй ID-токен до того, как доверять хоть одному claim. Обработчик callback должен сверить вернувшийся state со значением, сохранённым до редиректа (это CSRF-защита потока — без неё атакующий вошьёт свой код в сессию жертвы), а затем обменять код. Валидируй подпись ID-токена против JWKS, плюс iss, aud, exp и nonce — отсутствие проверки aud означает, что твоё приложение примет токен, выпущенный для другого клиента. Зафиксируй цель редиректа: возвращай браузер только на валидированный зарегистрированный URI, потому что небрежный параметр «return to» — это классический open-redirect, превращающий твой логин в стартовую площадку атакующего.

Сделай так, чтобы авторизация что-то значила. Добавь шаг согласия, где владелец ресурса одобряет конкретные scope, запрошенные клиентом, и обеспечь least privilege: токен с read:profile не должен проходить проверку write:billing. Выдавай токены, несущие только согласованные scope, и добавь два эндпойнта RFC 7662/7009 — /introspect, чтобы ресурс-сервер мог спросить «этот непрозрачный токен ещё активен и какие у него scope?», и /revoke, чтобы пользователь или админ мог мгновенно убить токен. Это ответ на пробел отзыва JWT из milestone токена: короткоживущие access-JWT, которые ты даёшь истечь, плюс отзываемые refresh-токены и непрозрачные токены, которые можно интроспектировать. Компромисс — латентность: introspection добавляет сетевой вызов на запрос — поэтому кэшируй результат активного токена на несколько секунд и прими, что отзыв eventually-consistent в этом окне.

Укрепи долгоживущую часть потока. Реализуй ротацию refresh-токена: каждый вызов refresh аннулирует старый токен и выдаёт новый, так что refresh-токен одноразовый. Выигрыш — детект повторного использования: если уже ротированный (погашенный) refresh-токен предъявлен снова, значит легитимный клиент или вор его реиграет, поэтому ты отзываешь всё семейство токенов и форсируешь повторную аутентификацию. Задай жёсткое абсолютное время жизни refresh-токена (например, 14–30 дней) и idle-окно, чтобы брошенные сессии умирали. На стороне браузера храни сессию в httpOnly, Secure, SameSite cookie (не в localStorage, который читает любой XSS) и узко её ограничь. Компромисс: ротация добавляет конкуренцию записи в хранилище refresh и гонку, когда две вкладки рефрешат разом — разрули гонку коротким grace-окном или single-flight-локом, а не сноси легитимное семейство.

Свяжи всё письменным threat model и телеметрией, чтобы по нему действовать, затем переживи инцидент. Перечисли поверхность атаки потока — перехват authorization-code, open redirect, CSRF через отсутствие state, утечка токена через логи или Referer и кража refresh-токена — и сопоставь каждому защиту, которую ты построил. Сними с auth-пути RED-метрики (rate, errors, duration на /authorize, /token, /introspect) и структурные логи, которые НИКОГДА не пишут сырые токены, code_verifier или секреты клиента — максимум хешированный id токена. Затем отыграй инцидент: утекает refresh-токен (скажем, он попал в серверный лог, ушедший третьей стороне). Обнаружь аномальный реюз по метрикам, отзови затронутое семейство токенов вживую и напиши короткий пост-мортем. Настоящий фикс — не просто «ротировать утёкший токен», а закрыть путь утечки (редакция, никаких токенов в URL) плюс ротация, чтобы будущая утечка самозалечивалась при следующем использовании.