PKCE: защита публичных клиентов

Без PKCE мобильные приложения уязвимы для атак с перехватом кода авторизации. Когда сервер авторизации перенаправляет код авторизации в зарегистрированную приложением пользовательскую схему URI, например myapp://callback, любое вредоносное приложение на том же устройстве, зарегистрировавшее такую же схему URI, может перехватить перенаправление и украсть код.

Атака происходит следующим образом: вредоносное приложение регистрирует ту же пользовательскую схему URI, что и легитимное приложение. Когда сервер авторизации перенаправляет код на myapp://callback, ОС может предложить оба приложения в качестве обработчиков. Если пользователь выберет вредоносное приложение или ОС назначит его обработчиком по умолчанию, злоумышленник получит код авторизации и сможет обменять его на токены, не зная секрета клиента.

PKCE (RFC 7636) добавляет динамически создаваемый секрет к потоку кода авторизации. Перед началом потока клиент создаёт криптографически случайную строку длиной от 43 до 128 символов, называемую верификатором кода. Эта строка уникальна для каждого запроса авторизации и не передаётся до этапа обмена токена.

Клиент вычисляет проверочное значение кода из верификатора: code_challenge = BASE64URL(SHA256(code_verifier)). Использование SHA256 — обязательный метод согласно RFC 7636; метод "plain", при котором верификатор передаётся напрямую, не рекомендуется. Проверочное значение кода — это одностороннее преобразование верификатора, поэтому знание проверочного значения не раскрывает верификатор.

Запрос авторизации включает два дополнительных параметра: "code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256". Сервер авторизации сохраняет проверочное значение кода, связанное с выданным кодом авторизации. На этом этапе серверу не передаётся секрет, который можно было бы перехватить.

Во время обмена токена (POST к конечной точке токенов) клиент передаёт параметр "code_verifier=ORIGINAL_RANDOM_STRING" вместе с кодом авторизации. Сервер авторизации вычисляет BASE64URL(SHA256(code_verifier)) и проверяет, совпадает ли результат с сохранённым code_challenge. Только легитимный клиент, создавший верификатор, может пройти эту проверку.

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

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

Хотя в RFC 7636 изначально PKCE описывался как решение для публичных клиентов (клиентов без секретов), документ BCP по безопасности OAuth и OAuth 2.1 требуют использовать PKCE для всех клиентов, включая конфиденциальные клиенты с секретами. PKCE обеспечивает защиту независимо от аутентификации клиента, поэтому он полезен во всех случаях.

OAuth 2.1 (draft-ietf-oauth-v2-1) объединяет рекомендации по безопасности из BCP по безопасности OAuth 2.0 в одном документе. Он требует использовать PKCE во всех потоках с кодом авторизации, объявляет неявный поток устаревшим и требует ротации токенов обновления. PKCE фактически является обязательной базовой защитой для любой новой реализации OAuth 2.0.

Правильная реализация PKCE требует: использовать криптографически стойкий генератор случайных чисел для верификатора (не менее 32 случайных байтов с последующим кодированием в base64url), безопасно хранить верификатор на стороне клиента (не в URL и не в журналах), использовать метод S256 (не plain) и удалять верификатор после обмена токена. Большинство современных библиотек OAuth обрабатывают PKCE автоматически.

В PKCE как связаны верификатор кода и проверочное значение кода?

PKCE (RFC 7636) предотвращает перехват кода авторизации, связывая каждый код с динамически сгенерированным верификатором кода, известным только легитимному клиенту. Из верификатора вычисляется хеш, который образует проверочное значение кода и передается открыто. Для обмена токена требуется исходный верификатор. PKCE предотвращает как перехват, так и внедрение кодов. OAuth 2.1 требует использовать PKCE во всех потоках с кодом авторизации.