Proof Key for Code Exchange

Proof Key for Code Exchange — это расширение протокола авторизации OAuth 2.0, предназначенное для защиты процесса обмена авторизационного кода на токен доступа от атак с перехватом кода (authorization code interception attack). PKCE (произносится как «пикси») позволяет клиентским приложениям, особенно тем, которые не могут безопасно хранить секретный ключ (public clients), доказать, что запрос на получение токена исходит именно от того приложения, которое инициировало авторизацию.

История и предпосылки создания

До появления PKCE в протоколе OAuth 2.0 (RFC 6749, 2012) для обмена кода на токен требовался client_secret — секретный ключ, известный только клиенту и серверу авторизации. Однако мобильные, десктопные и одностраничные веб-приложения (SPA) не могли безопасно хранить такой секрет: он был доступен при обратной разработке, инспекции кода в браузере или перехвате трафика.

В 2015 году исследователи безопасности из компании Google и Университета Карнеги — Меллон описали атаку, при которой злоумышленник, перехватив авторизационный код (например, через небезопасный канал связи или вредоносное ПО на устройстве), мог обменять его на токен доступа, используя собственный client_secret или вовсе без него (для public clients). Для решения этой проблемы был разработан PKCE, который был стандартизирован как RFC 7636 в сентябре 2015 года.

Принцип работы

PKCE основан на криптографической связке между двумя запросами: начальным запросом авторизации и последующим запросом на обмен кода на токен. Процесс включает три ключевых элемента:

1. code_verifier — случайная строка высокой энтропии (не менее 43 символов из набора [A-Za-z0-9\-._~]), генерируемая клиентским приложением перед началом авторизации. Этот секрет хранится только на стороне клиента.

1. code_challenge — значение, полученное из code_verifier с помощью одного из двух методов:

• S256 (рекомендуемый) — SHA-256 хеш от code_verifier, закодированный в base64url без символов заполнения.
• plain — code_verifier передаётся без преобразования (менее безопасно, используется только при невозможности вычислить хеш).

1. code_challenge_method — указание, какой метод был использован (S256 или plain).

Этапы авторизации с PKCE

1. Генерация code_verifier: клиент создаёт случайную строку и вычисляет code_challenge.
2. Запрос авторизации: клиент перенаправляет пользователя на сервер авторизации, передавая в параметрах запроса code_challenge и code_challenge_method вместе со стандартными параметрами OAuth (response_type=code, client_id, redirect_uri).
3. Авторизация пользователя: пользователь вводит учётные данные и даёт согласие. Сервер авторизации сохраняет code_challenge и code_challenge_method в сессии, связанной с выданным авторизационным кодом.
4. Возврат кода: сервер перенаправляет пользователя обратно на redirect_uri с авторизационным кодом.
5. Обмен кода на токен: клиент отправляет POST-запрос на сервер авторизации, включая:

• code (авторизационный код),
• code_verifier (исходная случайная строка),
• grant_type=authorization_code,
• redirect_uri.

1. Проверка: сервер авторизации вычисляет code_challenge из полученного code_verifier (используя тот же метод, что был указан при запросе) и сравнивает с сохранённым значением. Если они совпадают — сервер выдаёт токен доступа. Если нет — запрос отклоняется.

Преимущества и защита

PKCE эффективно предотвращает атаки с перехватом авторизационного кода по нескольким причинам:

• Связка запросов: злоумышленник, перехвативший код, не может обменять его на токен, так как не знает code_verifier, который генерируется на стороне клиента и никогда не передаётся по сети до момента обмена.
• Одноразовость: code_verifier и code_challenge используются для одного сеанса авторизации. Даже если злоумышленник получит code_verifier позже (например, через вредоносное ПО), он не сможет использовать его с другим кодом.
• Отсутствие необходимости в client_secret: PKCE позволяет безопасно использовать OAuth 2.0 в public clients, где хранение секрета невозможно.

Применение

PKCE является обязательным требованием для многих современных протоколов и платформ:

• OAuth 2.0 для мобильных приложений: Apple, Google и Microsoft рекомендуют PKCE как стандарт для iOS, Android и Windows приложений.
• OpenID Connect (OIDC): PKCE включён в спецификации OIDC как рекомендуемый метод для public clients.
• Одностраничные приложения (SPA): для SPA, работающих в браузере, PKCE стал обязательным в спецификации OAuth 2.0 for Browser-Based Apps (RFC 8252).
• Российские платформы: многие российские сервисы, включая VK ID, Яндекс ID, Сбер ID, используют PKCE в своих реализациях OAuth 2.0 для обеспечения безопасности.

Критика и ограничения

Несмотря на широкое распространение, PKCE не лишён недостатков:

• Сложность реализации: разработчики должны правильно генерировать code_verifier с достаточной энтропией (не менее 43 символов) и корректно вычислять code_challenge. Ошибки в реализации (например, использование метода plain вместо S256) снижают безопасность.
• Защита от других атак: PKCE не защищает от атак типа CSRF (cross-site request forgery) или от кражи токена доступа после его выдачи. Для этих целей требуются дополнительные меры, такие как state-параметр и использование PKI.
• Зависимость от сервера: не все серверы авторизации поддерживают PKCE, особенно старые реализации. В таких случаях клиент может быть вынужден использовать менее безопасные методы.

Стандартизация и развитие

PKCE описан в RFC 7636 (2015) и впоследствии включён в обновлённую спецификацию OAuth 2.0 (RFC 6749) как часть Best Current Practice (BCP 195). В 2022 году IETF опубликовала RFC 9282, который уточняет использование PKCE для мобильных приложений. В России PKCE упоминается в методических рекомендациях по безопасности аутентификации и авторизации, выпущенных Федеральной службой по техническому и экспортному контролю (ФСТЭК России).

Источники

• RFC 7636: Proof Key for Code Exchange by OAuth Public Clients (IETF, 2015).
• RFC 6749: The OAuth 2.0 Authorization Framework (IETF, 2012).
• RFC 8252: OAuth 2.0 for Native Apps (IETF, 2017).
• RFC 9282: OAuth 2.0 for Mobile and Native Applications (IETF, 2022).
• Методические рекомендации ФСТЭК России по безопасности аутентификации и авторизации (2021).