Ротация refresh-токенов и scope-based least privilege

Refresh-токен утекает через log entry. Без ротации атакующий тихо обновляет новые access-токены месяцами — пока refresh-токен не истечёт естественно. С ротацией — первый раз, когда либо атакующий, либо легитимный клиент использует токен после своего counterpart, сервер обнаруживает replay, инвалидирует всю цепочку и форсирует re-аутентификацию.

Как работает ротация refresh-токенов

OAuth 2.1 мандатит, что каждое использование refresh-токена выдаёт новый refresh-токен и инвалидирует старый. Сервер отслеживает, какой refresh-токен заменил какой.

Нормальный flow:

1. Клиент держит RT1. Представляет на /token. Сервер выдаёт access_token_2 + RT2. Помечает RT1 как used, linked to RT2. Клиент сохраняет RT2.

Под атакой:

1. Атакующий крадёт RT1 (через log leak, network capture и т.д.).
2. Атакующий использует RT1 первым → получает access_token_A + RT2. RT1 теперь помечен used.
3. Легитимный клиент позже представляет RT1 (не зная о краже) → сервер видит RT1 уже used → replay detected.
4. Сервер отзывает всю цепочку (RT1, RT2, все descendants). Оба — атакующий и легитимный клиент — теряют доступ. Пользователь вынужден re-аутентифицироваться.

Без ротации: украденный RT1 работает до absolute expiry — дни или месяцы. С ротацией: window вреда ограничен rotation interval — обычно минуты-часы до следующего легитимного refresh.

Scope и least privilege

Каждый access-токен несёт claim scope — точные разрешения, выданные на consent-этапе. Приложение запрашивает scope-set на /authorize; пользователь видит consent-экран и одобряет или отклоняет.

Почему гранулярные scope важны:

• read:photos vs read:everything — photo-printing app должен видеть только фото, не email или календарь.
• Blast radius: если приложение скомпрометировано, атакующие могут делать только то, что выданные scope разрешают. read:photos позволяет атакующему скачивать фото. write:photos delete:photos — ещё и уничтожать их.
• User trust: consent-экран с read:photos разумен. С full account access — тревожен, и пользователи правильно делают, что отказывают.

Промышленный паттерн: read-scope выдаются свободно; write-scope требуют явного per-action consent; admin-scope никогда не появляются в third-party flow. RFC 9396 (Rich Authorization Requests) расширяет это, позволяя запросы вроде “перевести до $500 на счёт 12345” вместо просто write:transfers.

Introspection vs JWT validation: реальный tradeoff

Когда resource server получает access-токен, он должен его верифицировать. Два подхода:

Token introspection (/oauth/introspect): real-time вызов к IdP на каждый запрос. Всегда актуален — знает об отзывах немедленно. Стоит один extra round-trip на запрос (~5–50ms latency). Требуется для opaque токенов.

Local JWT validation: токен — signed JWT. Resource server валидирует подпись через JWKS. Быстро — микросекунды. Масштабируется до миллионов RPS. Недостаток: не видит отзывы до истечения токена. Отозванный JWT продолжает работать до оставшегося TTL.

Production паттерн: local JWT validation для hot path + короткий access token TTL (5–15 минут, принимая что отзывы распространяются в этом окне). Для sensitive writes (transfers, deletes) — introspection поверх. Маленький server-side кеш “recently introspected tokens” (TTL 30с) амортизирует cost introspection.