Authorization code flow с PKCE

Атакующий мониторит исходящие запросы мобильного приложения и перехватывает one-time authorization code из redirect URL. Без PKCE он обменивает код на токены и захватывает аккаунт. PKCE — это замок, делающий украденный код бесполезным.

Как работает PKCE — шаг за шагом

PKCE (Proof Key for Code Exchange, RFC 7636) добавляет криптографический challenge к authorization code flow. OAuth 2.1 мандатит его для каждого клиента, включая confidential server-side приложения.

Перед редиректом:

1. Клиент генерирует code_verifier — случайную URL-safe строку 43–128 символов (криптографически случайную).
2. Клиент вычисляет code_challenge = base64url(SHA-256(code_verifier)).
3. Клиент отправляет code_challenge (но НЕ code_verifier) в authorization server в /authorize запросе.

После согласия пользователя: 4. Authorization server возвращает one-time code в редиректе. Сохраняет code_challenge рядом с кодом.

Обмен на токены: 5. Клиент POST-ит на /token с code И оригинальным code_verifier. 6. Authorization server хеширует code_verifier, сравнивает с сохранённым code_challenge. Совпадение → токены выданы. Несовпадение → запрос отклонён.

Атакующий, перехвативший код на шаге 4, не может его обменять — ему нужен code_verifier, который никогда не передавался по сети.

Правило exact-match redirect URI

OAuth 2.1 требует, чтобы redirect_uri в token request точно совпадал с pre-registered URI — никаких wildcard, префиксов пути, partial match.

Без этого правила: атакующий может триггернуть flow с redirect_uri=https://yourapp.com/comments?next=https://attacker.com. Если у твоего приложения есть open-redirect на /comments, authorization code оказывается на сервере атакующего. Exact-match закрывает это: URI должен совпадать character-for-character с зарегистрированным значением.

Для native apps, где нельзя надёжно зарегистрировать URL (deep links, custom URI schemes), OAuth 2.1 + RFC 8252 требуют http://127.0.0.1:RANDOM_PORT (loopback) или private-use URI scheme, зарегистрированный с OS.

State и nonce: два отдельных anti-attack токена

State — anti-CSRF OAuth: клиент генерирует случайное значение на /authorize, сервер эхо-нит его в редиректе, клиент проверяет совпадение. Без state атакующий может отправить жертве crafted /authorize URL, указывающий на redirect атакующего — при клике браузер жертвы тихо завершает flow под аккаунтом атакующего.

Nonce — anti-replay OIDC: клиент отправляет случайное значение в /authorize; IdP embed-ит его внутрь id_token. Клиент проверяет, что nonce в токене совпадает с отправленным. Без nonce атакующий, захвативший id_token из другого канала, может replay-нуть его в другую сессию.

Оба per-request случайные. Оба валидируются server-side. Ни один не optional в современных flow.