PKCE: Как конечная точка перенаправления узнает code_verifier?
У меня есть вопрос по поводу PKCE (RFC 7636). Клиенты OAuth, использующие предоставление кода авторизации, имеют два компонента: (1) часть на устройстве владельца ресурса, которая инициирует запрос авторизации, и (2) конечная точка перенаправления на сервере, который может принимать и отправлять сообщения HTTPS.
Расширение PKCE для OAuth заставляет клиентов делать это:
- Создайте криптографическую случайную строку, которая называется code_verifier.
- Создайте дайджест SHA-256 для code_verifier и закодируйте его с помощью Base64. Отправьте это вместе с запросом на авторизацию.
- Когда клиент получает код авторизации и отправляет его в конечную точку токена для токена доступа, включите исходное значение code_verifier.
Шаг 2 происходит на устройстве владельца ресурса. Как только владелец ресурса одобрил запрос, его браузер перенаправляется на конечную точку перенаправления клиента. Шаг 3 происходит в конечной точке перенаправления.
Итак, вопрос в том, как конечная точка перенаправления узнает значение code_verifier? Он был сгенерирован на устройстве владельца ресурса.
2 ответа
Итак, вопрос в том, как конечная точка перенаправления узнает значение code_verifier? Он был сгенерирован на устройстве владельца ресурса.
Поскольку конечная точка перенаправления эффективно маршрутизирует к конечной точке на том же устройстве, которое вызвало конечную точку авторизации.
Он может быть зарегистрирован как петлевое перенаправление, заявленное перенаправление приложения или пользовательская схема URL, но устройство перенаправит перенаправление в соответствующее приложение, или приложение будет прослушивать соответствующий порт для обратных вызовов.
Клиенты OAuth, использующие предоставление кода авторизации, имеют два компонента: (1) часть на устройстве владельца ресурса, которая инициирует запрос авторизации, и (2) конечная точка перенаправления на сервере, который может принимать и отправлять сообщения HTTPS.
Конфиденциальные клиенты имеют конечную точку перенаправления на сервере, который может принимать и отправлять сообщения HTTPS.
Общедоступные клиенты - нет, а нативные клиенты, использующие PKCE, по- прежнему являются публичными клиентами.
Чтобы использовать предоставленную информацию, PKCE предназначен для того, чтобы URI перенаправления направлялся обратно к запрашивающему приложению, а не к вредоносному приложению посредством атаки с перехватом кода авторизации. В этом случае законное приложение будет знать верификатор, но вредоносное приложение не будет знать верификатор.
PKCE Законный Поток Приложения
Допустимый поток приложений выглядит следующим образом, где запрос токена авторизации перенаправляется обратно в SystemBrowser, а затем обратно в исходное NativeApp.
Код авторизации перехват атаки
Вредоносное приложение может быть введено в ОС. С или без PKCE, собственное приложение может получить код авторизации, но оно не будет знать верификатор и, следовательно, не сможет завершить обмен токенами.
