Защита OAuth 2.0 в SPA и мобильных приложениях через PKCE

В первые годы существования стандарта OAuth 2.0 (RFC 6749) основным способом получения access token был серверный Authorization Code Flow с использованием client_id и client_secret. Однако с бурным ростом фронтенд-фреймворков (React, Vue, Nuxt) и мобильных приложений возникла критическая уязвимость: секрет приложения (client_secret), встроенный в клиентский код, легко компрометировался.

Проблема безопасности в публичных клиентах (Public Clients)

Публичные клиенты (SPA в браузере, мобильные и десктопные приложения) физически не способны защитить секретный ключ. Любой пользователь может открыть Chrome DevTools или декомпилировать приложение и извлечь client_secret.

Кроме того, при перенаправлении пользователя обратно на redirect_uri злоумышленник (через вредоносное расширение браузера или кастомный схематичный URI на мобильном устройстве) мог перехватить code и обменять его на токен, используя украденный client_secret.

Скандальное рождение OAuth 2.0 (2012)

OAuth 2.0 появился не тихо. Эран Хаммер (Eran Hammer), ведущий автор и редактор спецификации, в июле 2012 года покинул рабочую группу — за несколько месяцев до публикации RFC 6749 — и опубликовал пост под названием «OAuth 2.0 and the Road to Hell» («OAuth 2.0 и дорога в ад»). Его претензия: спецификация стала «сложнее, менее совместимой, менее полезной, более незавершённой и, главное, менее безопасной», чем OAuth 1.0, отказавшись от обязательных подписей в пользу bearer-токенов и оставив слишком много деталей на усмотрение каждого вендора. RFC 6749 всё равно вышел в октябре того же года — уже без его имени. PKCE во многом существует, чтобы залатать именно ту дыру, о которой предупреждала эта критика.

Как работает PKCE (RFC 7636)

В сентябре 2015 года Nat Sakimura, John Bradley и Naveen Agarwal опубликовали RFC 7636, и изначально он писался вовсе не для SPA — мотивирующий сценарий был про нативные мобильные приложения. Два приложения могли зарегистрироваться на одну и ту же кастомную URI-схему (myapp://callback), и вредоносное приложение могло перехватить код авторизации, предназначенный для легитимного. PKCE (произносится «пикси») закрыл эту дыру, а позже выяснилось, что та же техника отлично подходит и браузерным публичным клиентам — как только индустрия осознала, что client_secret в JavaScript ничем не безопаснее, чем в мобильном бинарнике.

Proof Key for Code Exchange исключает необходимость хранить client_secret на клиенте и работает по следующему алгоритму:

  Client Browser (SPA)                    Auth Server (IDP)
        |                                       |
        |---- (A) Authorization Request ------->|
        |     + code_challenge (S256)           |
        |                                       |
        |<--- (B) Authorization Code -----------|
        |                                       |
        |---- (C) Token Request --------------->|
        |     + code_verifier                   |
        |                                       |
        |<--- (D) Access Token -----------------|
        |                                       |

1. Генерация пары на клиенте:
   • Браузер генерирует криптографически стойкую случайную строку code_verifier (от 43 до 128 символов).
   • Вычисляется code_challenge: Base64URL(SHA256(code_verifier)).
2. Запрос авторизации:
   • Клиент отправляет пользователя на сервер авторизации, передавая client_id, redirect_uri, code_challenge и code_challenge_method=S256.
3. Обмен кода на токен:
   • После успешного входа сервер авторизации возвращает code.
   • Клиент делает POST-запрос на /token, передавая исходный необработанный code_verifier.
   • Сервер авторизации сам вычисляет SHA256(code_verifier) и сравнивает с сохраненным code_challenge. Если хэши совпали — выдается access_token.

Возможности нашего OAuth PKCE Generator

Инструмент OAuth 2.0 PKCE Generator & Auth Flow Sandbox позволяет отлаживать весь цикл авторизации:

• Генерация PKCE пар (S256): мгновенное вычисление code_verifier и code_challenge через стойкий Web Crypto API (window.crypto.subtle).
• Сборщик Auth URL: пресеты для Google OAuth 2.0, GitHub, Microsoft Entra ID (Azure AD) и Auth0.
• Генератор cURL запроса обмена: готовая команда для терминала для выполнения POST /token.
• Парсер Callback URL: разбор параметров code, state и error из адресной строки после перенаправления.

Быстрый старт: откройте тул → сгенерируйте новую PKCE-пару → перейдите на вкладку Auth URL Builder → выберите пресет провайдера → скопируйте URL и откройте его в новой вкладке → после входа вставьте callback-URL в парсер → используйте полученный code вместе с вашим code_verifier во вкладке Token Exchange cURL.

Похожие инструменты

Генератор OAuth PKCEГенерация пар code_verifier и S256 code_challenge по спецификации RFC 7636 с использованием Web Crypto, сборщик URL авторизации OAuth 2.0 и парсер callback ответов.JWT InspectorДекодируйте JWT в читаемый header и payload, проверяйте срок действия и время выпуска и проверяйте подписи HS256, RS256 или ES256 локально.Генератор хешейСчитайте MD5, SHA-1, SHA-256/384/512, SHA-3 и CRC32 из текста или файлов вживую по мере ввода, с HMAC и сравнением хешей.Криптографический наборОпределяйте неизвестный шифр по алфавиту, индексу совпадений, частотам букв и повторам Касиски; кодируйте сообщение сразу всеми обратимыми шифрами с проверкой обратного преобразования; шифруйте через AES-256-GCM и решайте Цезаря, Виженера, Плейфера, ADFGX, Бифид или «забор» в верстаке — всё в браузере.Webhook Signature VerifierПроверка подписей webhook для семи провайдеров: точная подписываемая строка, окно защиты от replay и экспорт кода верификации для Node, Python, PHP и Go.