Безопасность
Валидация ID-токена и управление JWKS-кешем
Суть Восемь обязательных проверок каждого OIDC клиента, почему устаревший JWKS-кеш вызывает auth-аутаж, и паттерн on-cache-miss refresh.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на middle-высоте — в небеIdP ротирует signing key. JWKS-кеш твоего приложения имеет TTL 6 часов. Следующие 4 часа каждый новый пользователь получает 401 — его id_token подписан новым ключом, которого нет в кеше. Валидация подписи fail-ит на токене, который полностью валиден.
Восемь обязательных проверок id_token
Когда твоё приложение получает id_token от OIDC authorization server, оно обязано верифицировать все восемь следующих пунктов перед тем, как доверять identity пользователя. Пропуск любого — документированная CVE категория.
1. Распарсить JWT. Split header.payload.signature. Base64url-декодировать каждую часть.
2. Прочитать kid из JWT header. Поле kid (Key ID) называет, каким публичным ключом подписан этот токен. Без него нельзя найти правильный ключ.
3. Получить публичный ключ из JWKS. Вызвать /.well-known/jwks.json IdP (кешировано, TTL 5–15 мин). Найти ключ с совпадающим kid. При cache miss — немедленно обновить перед тем, как провалиться.
4. Верифицировать подпись. Использовать алгоритм, объявленный в header (должен быть RS256 или ES256 — никогда HS256 с асимметричным ключом, никогда alg: none). Fail подписи → отклонить. Закрепить алгоритм server-side; никогда не доверять alg claim самого токена.
5. Валидировать iss. Должен точно совпадать с ожидаемым URL issuer из конфига. Атакующий может выпустить токен от своего IdP с валидной подписью.
6. Валидировать aud. Должен содержать твой client_id. Без этой проверки токен, выпущенный для другого приложения, принимается твоим.
7. Валидировать exp и iat. exp должен быть в будущем; iat — в прошлом. Допустимо ~5 минут clock skew (300 секунд — типичная tolerance). Обе проверки используют часы сервера, не клиента.
8. Валидировать nonce. Должен совпадать с nonce, отправленным клиентом в /authorize. Без этой проверки захваченный id_token можно replay-нуть в другую сессию.
Последовательность валидации id_token
1
Парсинг JWTSplit header.payload.signature
2
kid lookupЧитаем key ID из header → находим ключ в JWKS
3
ПодписьВерифицируем публичным ключом; отклонить alg=none или неверный тип
4
issДолжен совпасть с ожидаемым issuer (exact string)
5
audДолжен содержать ВАШ client_id
6
exp / iatexp в будущем, iat в прошлом — допустимо 300с clock skew
7
nonceДолжен совпасть с nonce из /authorize
Устаревший JWKS-кеш: production failure mode
JWKS endpoint IdP содержит его текущие signing public keys. Твоё приложение кеширует этот список (fetching на каждый запрос был бы слишком медленным). При ротации ключей IdP публикует новый ключ — но твой кеш ещё содержит старый.
Что ломается: новые токены подписаны новым ключом. Твой валидатор читает kid из header токена, ищет в кеше — не найдено. Валидация подписи fail-ит. Пользователи не могут войти, хотя их токены полностью валидны.
Fix — on-cache-miss refresh: Когда kid не найден в кеше, немедленно сделать fresh fetch JWKS с /.well-known/jwks.json и повторить lookup. RFC 7517 явно разрешает это. Провалить только если kid всё ещё отсутствует после refresh.
Долгосрочная митигация: Короткий cache TTL (5–15 минут) плюс on-miss refresh как backstop. Mature IdP (Auth0, Okta) публикуют новые ключи за 24–48 часов до активации. Если твой не делает этого — короткий TTL + on-miss refresh — единственная надёжная защита.
Викторина
Completed
Приложение верифицирует подпись id_token и iss корректно, но скипает проверку aud. Какая атака становится возможной?
Heads-up PKCE downgrade — про обмен кода, не связан с aud.
Heads-up Algorithm confusion — про манипуляцию alg header, не про aud.
Heads-up Nonce replay требует пропуска nonce проверки, не aud.
Викторина
Completed
Почему нельзя доверять claim 'alg' в JWT header?
Heads-up Header base64url-кодирован и читаем. Проблема в том, чтобы доверять ему.
Heads-up Claim alg присутствует; проблема в том, чтобы позволять токену диктовать алгоритм.
Heads-up GDPR не регулирует JWT header trust.
Расставь шаги по порядку
Completed
Поставь шаги валидации id_token в правильном порядке:
- 1 Парсинг JWT — split header.payload.signature
- 2 Читаем kid (key ID) из JWT header
- 3 Получаем matching public key с JWKS endpoint issuer-а (кешировано, refresh при miss)
- 4 Верифицируем подпись публичным ключом и pinned ожидаемым алгоритмом
- 5 Валидируем iss claim совпадает с ожидаемым issuer
- 6 Валидируем aud claim содержит client_id приложения
- 7 Валидируем exp в будущем и iat в прошлом (допустимо ~300с clock skew)
- 8 Валидируем nonce claim совпадает с nonce из /authorize
- 01Что такое on-cache-miss JWKS refresh паттерн и почему он требуется?
- 02Почему aud claim должен содержать ТВОЙ client_id, а не просто любой client_id?
- 03Приложение скипает exp/iat для производительности. Каков blast radius украденного id_token?
Итог
Валидация OIDC id_token имеет восемь обязательных шагов. Верификация подписи требует правильного публичного ключа из JWKS, выбранного по kid, с server-side pinned алгоритмом — никогда не читать из токена. Checks iss и aud предотвращают cross-issuer и cross-audience атаки. Checks exp/iat применяют freshness. Check nonce предотвращает replay. Устаревание JWKS-кеша при ротации ключей — самый частый production fail: on-cache-miss refresh плюс короткий TTL (5–15 минут) — стандартная митигация.
Связанные уроки
опирается на
углубляется в
встречается в178
- Почему GraphQL получает N+1junior
- Механика DataLoader: батчинг на границе тикаmiddle
- Контракты batch-функции: порядок, формы, ошибкиmiddle
- Federation и lookahead: батчинг за пределами DataLoadermiddle
- Защита сложности запросов: depth, cost, persisted queriesmiddle
- Senior GraphQL API: scheduling-контракт, изоляция арендаторов, наблюдаемостьsenior
- Зачем идемпотентность: безопасные retryjunior
- Серверный state machine: четыре состояния idempotency keymiddle
- Outbox и inbox: effectively-once через dual-write границуmiddle
- Конкурентность и архитектура кеша для идемпотентности на масштабеsenior
- Наблюдаемость, production-инциденты и дизайн для глобального масштабаsenior
- Event loop: один поток, три очередиjunior
- Задачи, микрозадачи и scheduler.yield()middle
- Голодание микрозадач, длинные задачи и LoAFsenior
- Event loop Node.js: фазы, nextTick и задержка циклаsenior
- React, Vue и наблюдаемость INP в продакшенеsenior
- Render pipeline: шесть стадий от байтов до пикселейjunior
- Цена стадий и модель процесса рендерераmiddle
- Инвалидация, dirty-биты и containmiddle
- Слои композитора: продвижение, перекрытие и память GPUmiddle
- Флейм-стрип DevTools и жизненный цикл кадраmiddle
- Layout thrash: форсированная синхронная компоновкаsenior
- BeginMainFrame, анимации на потоке compositor и память GPUsenior
- Observability в проде: LoAF, INP и полная поверхность атакиsenior
- Что такое V8 и почему производительность различается в 100 разjunior
- Четырёхуровневый JIT-конвейер V8 и профилированная тиеризацияmiddle
- Hidden classes, деревья переходов и расположение в памятиmiddle
- Inline caches, состояния IC и деоптимизацияmiddle
- Orinoco GC: параллельный scavenger, конкурентная разметка и барьеры записиmiddle
- Спекулятивный движок TurboFan и ловушка deopt-loopsenior
- V8 в production: Isolates, сжатие указателей и реальные аварииsenior
- Жизненный цикл service worker и стратегии кешированияmiddle
- Граничные случаи service worker: version skew, долговременность и ловушка навигацииsenior
- Что делает реконсилер: render vs commitjunior
- Объект fiber и дерево с двойной буферизациейmiddle
- Чистота фазы render и подшаги фазы commitmiddle
- Реконсиляция: эвристики диффа и ловушка ключейmiddle
- Приоритетные lanes, time-slicing и useTransitionmiddle
- Bailout, мемоизация и tearingsenior
- React Profiler, компилятор и продакшн-наблюдаемостьsenior
- Стратегии рендеринга: SSG, SSR, ISR, streaming и гидратацияjunior
- SSG, SSR, ISR, streaming и RSC — как работает каждая стратегияmiddle
- Цена гидратации: selective, progressive, острова, resumabilitymiddle
- Hydration mismatch: причины, обнаружение и правило детерминизмаsenior
- RSC, стратегия на маршрут и production-наблюдаемостьsenior
- Core Web Vitals: что измеряют LCP, INP и CLSjunior
- CLS: почему происходят сдвиги лейаута и как их остановитьmiddle
- Трейдоффы метрик, RUM-атрибуция и цикл CI+полеsenior
- Общая картина: от URL до LCP до INP как эстафетаjunior
- Восемь слоёв трассировки: от service worker до второй навигацииmiddle
- Пять канонических поломок: где производство стабильно ломаетсяsenior
- Метод трёх треков: чтение трасс и построение системы мониторингаsenior
- Что такое cache stampede и почему он делает всё хужеjunior
- Лок и single-flight: ограничение параллельных rebuildmiddle
- XFetch: вероятностное раннее истечение без координацииmiddle
- Stale-while-revalidate и CDN request coalescingmiddle
- Детектирование stampede и дизайн TTL для продакшенаmiddle
- Метастабильный сбой, fencing-токены и production-постмортемыsenior
- Что такое отношение: таблицы, строки, ключи и ограниченияjunior
- Ограничения, ключи и типы данных Postgresmiddle
- Нормальные формы, денормализация и почему схемы «прилипают»middle
- JSONB, массивы и когда side table побеждаетmiddle
- Heap-хранилище, TOAST и выравнивание колонокsenior
- Целостность схемы: deferral, версионирование и сбои в продакшнеsenior
- Реляционная модель vs документные, wide-column, граф и key-valuesenior
- Index-only scan, Visibility Map и INCLUDEsenior
- Типичные сбои в продакшне и аудит индексовsenior
- pg_statistic, ANALYZE и производственная наблюдаемостьmiddle
- Производственные режимы отказа и стабильность плановsenior
- MVCC: как Postgres раздаёт согласованные снимкиjunior
- Заголовок tuple и механика снимковmiddle
- HOT-обновления и уровни изоляцииmiddle
- VACUUM, bloat и autovacuummiddle
- CLOG, XID wraparound и MultiXactsenior
- SSI и production-тюнинг autovacuumsenior
- Реальные провалы MVCC, deployment-паттерны и распределённые снимкиsenior
- Connection pool: зачем амортизировать стоимость backend Postgresjunior
- Режимы PgBouncer: session, transaction и statementmiddle
- Размер пула: формула (ядра × 2) + шпинделей и двухуровневый стекmiddle
- Исчерпание пула и idle-in-transaction: сценарий отказа в 3 ночиmiddle
- Миграция на transaction mode: план развёртывания и prepared statements в PgBouncer 1.21middle
- Процессная модель Postgres и почему увеличение max_connections снижает производительностьsenior
- Ландшафт пулеров 2026, serverless connection storms и полная таксономия отказовsenior
- Что такое миграция схемы и почему она заменяет ad-hoc DDLjunior
- ADD COLUMN: мгновенно в PG 11+ против перезаписи в старом Postgresjunior
- Режим отказа очереди блокировок: почему мгновенный DDL может заморозить базуmiddle
- Безопасные DDL-паттерны: NOT VALID, CONCURRENTLY и исправления небезопасных операцийmiddle
- Expand-contract: нулевой простой для ломающих изменений схемыmiddle
- Advisory-блокировки, инструменты миграций и координация деплояsenior
- Таксономия сбоев миграций и дисциплина продакшнаsenior
- Зачем нужно шардирование: потолок одного Postgresjunior
- Выбор ключа шарда: стратегии hash, range, list и directorymiddle
- Партиционирование против шардирования: одно слово, два разных понятияmiddle
- Ко-локация и Citus: инвариант, делающий шардирование пригодным к использованиюmiddle
- Режим отказа hot shard: обнаружение, изоляция и долгосрочная политикаmiddle
- Schema-based шардирование и альтернативы мультиарендностиsenior
- Онлайн-решардинг, 2PC и операционная стоимость шардированияsenior
- Семь актов: от CREATE TABLE до Citusjunior
- Акты 1–3 в глубину: схема, индексы и статистика планировщикаmiddle
- Акты 4–6 в глубину: MVCC bloat, connection pooling и безопасные миграцииmiddle
- Акт 7 в глубину: шардинг, co-location и семиуровневый каскад трейдоффовmiddle
- Наблюдаемость, антипаттерны и производственный триажsenior
- Роли Raft, term и почему majority-кворум предотвращает split brainjunior
- Как Raft реплицирует log entry и решает, что его безопасно коммититьmiddle
- Выборы лидера в Raft: таймауты, правила голосования и четыре свойства безопасностиmiddle
- Raft в реальном мире: partition, медленный диск и клиентская маршрутизацияmiddle
- Расширения Raft: pre-vote, learner, snapshot и линеаризуемые чтенияsenior
- Raft в production: membership change, Multi-Raft и observabilitysenior
- Где происходит data fetching — и почему это решает LCPjunior
- Fetch waterfall''''ы — диагностика и лечение через Promise.allmiddle
- React Server Components и Suspense streamingmiddle
- Клиентский кэш: TanStack Query, SWR и stale-while-revalidatemiddle
- LCP, prefetch и race conditions в интерактивном fetchingmiddle
- Senior internals: RSC payload, слои кэша и production паденияsenior
- Трёхстороннее рукопожатие TCPjunior
- Номера последовательности и состояние соединенияmiddle
- DNS: что делает и зачем существуетjunior
- Обход резолвера: перенаправления, типы записей и gluemiddle
- TTL, кеширование и распространение DNSmiddle
- Рукопожатие за 1 RTT: key share и ECDHEmiddle
- Возобновление сессии и 0-RTTmiddle
- WebSocket: HTTP-апгрейд до постоянного соединенияjunior
- Формат WebSocket-фрейма: opcodes, маскирование, фрагментацияmiddle
- Backpressure в WebSocket: когда клиенты не успеваютmiddle
- Реконнект: jittered backoff, thundering herd, восстановление сообщенийsenior
- WebSocket в масштабе: HTTP/2 мультиплексирование, permessage-deflate, C10Msenior
- WebSocket в production: прокси, безопасность и распределённая архитектураsenior
- Что делают обратные проксиjunior
- Health checks, connection draining и slow startmiddle
- Session affinity, consistent hashing и правильное решениеmiddle
- Retry-бури, circuit breakers и load sheddingsenior
- Устойчивая архитектура LB: anycast, zone-aware маршрутизация и observabilitysenior
- Почему QUIC, а не TCP+TLSjunior
- Connection ID и миграция сетиmiddle
- Возобновление 0-RTT и шифрование пакетовsenior
- DDoS: что это и почему работаетjunior
- Атаки усиления и истощение состоянияmiddle
- Ограничение скорости: алгоритмы и архитектураmiddle
- WAF, межсетевые экраны, mTLS и HSTSmiddle
- Отравление DNS-кэша и BGP-перехватsenior
- Эшелонированная защита и экономика атакsenior
- DNS, TCP, TLS по очереди: куда уходят миллисекундыmiddle
- Перехват прокси и шлюзы безопасности: rate limiter, WAF, mTLSmiddle
- Альтернативные пути: QUIC 0-RTT, WebSocket upgrade, миграция соединенияmiddle
- Наблюдаемость: распределённые трейсы, USE/RED и семплированиеsenior
- Устойчивость: каскадные повторы, circuit breakers и error budgetsenior
- Что такое три сигнала: метрики, логи, трейсыjunior
- Зачем нужны структурные логи: дневник против таблицыjunior
- Схема продакшн-лога: поля, которые несёт каждая строкаmiddle
- PII-редакция и log injectionsenior
- OTel Logs Data Model и audit-логи как подсистемаsenior
- SLI, SLO и error budget: надёжность в числахjunior
- Error budget policy, latency SLO и составные journeysmiddle
- Продакшн-отказы SLO, самонаблюдаемость, безопасность и общая картинаsenior
- Петля инцидента: от пейджера до постмортема до предотвращенияmiddle
- Cache lines и false sharing: когда параллелизм замедляет кодmiddle
- SIMD и data layout: AoS vs SoA и разница в 4–8xmiddle
- Cache-oblivious алгоритмы, PGO и production failuressenior
- GC в production: наблюдаемость, безопасность, edge cases и управление флотомsenior
- Batching: амортизируй фиксированную цену каждой операцииjunior
- Окно батчинга: размер и время ожиданияmiddle
- Batching в Kafka и Postgresmiddle
- io_uring и наблюдаемость пакетированияmiddle
- От Nagle до io_uring: эволюция пакетированияmiddle
- Backpressure, изоляция сбоев и безопасность батчей в продакшенеsenior
- CI enforcement и RUM: делаем бюджеты рабочимиmiddle
- V8 JIT-пайплайн, HTTP-приоритеты и безопасность bundlesenior
- Цикл performance: дисциплина, а не проектjunior
- Классификация и исправление: сопоставление family bottleneck с методамиmiddle
- Observability-стек и CI gates: ловить регрессии до выпускаmiddle
- От инцидента к enforcement: SLO burn до верифицированного исправления за 35 минутmiddle
- Культура, экономика и масштаб performancesenior
- At-most-once, at-least-once, exactly-once: три контракта доставкиjunior
- Три ножки сбоя — где реально происходят дубликаты и потериmiddle
- Consumer-side dedup: самый дешёвый путь к exactly-once processingmiddle
- Kafka exactly-once semantics: idempotent producer и транзакцииmiddle
- SQS visibility timeout, DLQ и outbox patternmiddle
- Exactly-once в production: impossibility-доказательство, гибридные паттерны и реальные инцидентыsenior