Что такое PKCE: от базовых концепций до глубокого понимания

Эта статья объясняет, как PKCE (Proof Key for Code Exchange) защищает поток авторизации кода OAuth 2.0, предотвращая перехват авторизационных кодов вредоносными приложениями, и знакомит вас с основами и всесторонним пониманием.

Yijun

Developer

7/28/2023

Хватит тратить недели на аутентификацию пользователей

Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.

Начать

Proof Key for Code Exchange (PKCE) — это расширение для Authorization Code flow, изначально разработанное для защиты потока авторизации кода в мобильных приложениях, а теперь рекомендуется для использования и в одностраничных приложениях. Начиная с OAuth 2.1, PKCE обязательно для всех типов клиентов, включая публичные клиенты и конфиденциальные (частные) клиенты.

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

Почему нужен PKCE?

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

Этот поток имеет значительный риск безопасности: авторизационный код может быть перехвачен вредоносными программами. Это особенно актуально на мобильных устройствах, где другие приложения могут зарегистрировать тот же URI перенаправления и перехватить авторизационный код.

Процесс перехвата показан на диаграмме ниже:

Шаг (1): Приложение выполняет запрос авторизации через безопасный API, который не может быть перехвачен. На этом шаге запрашивающий также предоставляет URI перенаправления.

Шаг (2): Затем запрос пересылается на сервер авторизации OAuth 2.0. Поскольку OAuth требует использования TLS, эта связь защищена TLS и не может быть перехвачена.

Шаг (3): Сервер авторизации возвращает авторизационный код.

Шаг (4.a): авторизационный код возвращается запрашивающему через URI перенаправления, предоставленный на шаге (1). На этом этапе, если вредоносное приложение зарегистрировалось как обработчик URI перенаправления, оно может перехватить авторизационный код. С помощью авторизационного кода злоумышленник может запросить и получить токен доступа на шагах (5.a) и (6.a) соответственно.

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

Как работает PKCE?

Как упоминалось выше, если мы хотим защититься от атак, мы должны убедиться, что только приложение, инициировавшее запрос, может запросить и получить токен доступа. Здесь на сцену выходит PKCE.

PKCE решает этот вопрос, вводя концепцию "ключа доказательства".

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

Проверяющий код — это случайно сгенерированная строка, а вызов кода получается из проверяющего кода путём преобразования. Поддерживаются два метода преобразования:

plain: Использует проверяющий код прямо как вызов кода

S256: Применяет SHA-256 хэширование к проверяющему коду с последующим кодированием Base64URL. Поскольку результат хэширования не может быть обратно восстановлен для получения проверяющего кода, и поскольку метод plain может быть уязвим для атак посредника во время передачи, использование S256 настоятельно рекомендуется по соображениям безопасности.

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

Шаг (1-3): Приложение создаёт и фиксирует секрет, называемый "проверяющим кодом" и вырабатывает преобразованную версию "вызов кода", которая отправляется в OAuth 2.0 Authorization Request вместе с методом преобразования "метод вызова кода".

Шаг (3-6): Сервер аутентификации отвечает как обычно, но фиксирует "вызов кода" и "метод вызова кода".

Шаг (7.a): Затем приложение отправляет авторизационный код в конечную точку токена, как обычно, но включает секрет "проверяющий код", сгенерированный на шаге (1).

Шаг (8.a-9.a): Сервер аутентификации преобразует "проверяющий код" в "вызов кода" и сравнивает его с "вызовом кода" с шага (1-3). Доступ отказывается, если они не равны.

В этом случае, хотя вредоносное приложение и перехватило авторизационный код на шаге (6.b), оно не может обменять его на токен доступа, так как не владеет секретом "code_verifier", и поскольку "проверяющий код" отправляется через TLS, он не может быть перехвачен.

Вывод

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

Попробуйте Logto сегодня

Почему нужен PKCE?#

Как работает PKCE?#

Вывод#

Почему нужен PKCE?#

Как работает PKCE?#

Вывод#

Почему нужен PKCE?

Как работает PKCE?

Вывод

Почему нужен PKCE?

Как работает PKCE?

Вывод