Почему в проекте «Наилучшая текущая практика обеспечения безопасности OAuth2.0» говорится, что все реализации типа авторизации должны использовать PKCE?

Question

В текущем наброске лучших рекомендаций тем безопасности OAuth2.0 в разделе 3.1.1 содержится следующее:

"Клиенты, использующие тип разрешения авторизации, ДОЛЖНЫ использовать PKCE [RFC7636] для того, чтобы (с помощью сервера авторизации) обнаруживать и предотвращать попытки внедрения (повторного воспроизведения) кодов авторизации в ответ авторизации ... Примечание: хотя PKCE до сих пор рекомендовался как механизм защиты собственных приложений, этот советраспространяется на все виды клиентов OAuth, включая веб-приложения. "

• "Клиенты, использующие тип разрешения авторизации, ДОЛЖНЫ использовать PKCE ... для обнаружения и предотвращения попыток внедрения (ответа) кодов авторизации в ответ авторизации."
  • Как именно PKCE помогает "обнаруживать" попытки ответа на коды авторизации? В его RFC нет ничего, что предполагало бы, что он будет обрабатывать обнаружение лучше, чем OAuth2.0 RFC , который ДОЛЖЕН отклонять запросы, если они содержат уже используемый код авторизации.
  • Как именно PKCE помогает «предотвращать» атаки воспроизведения кода авторизации для веб-приложений с помощью серверной части, обрабатывающей запрос кода авторизации и перенаправления? Я работаю в предположении, что запрос кода авторизации и перенаправление происходят с TLS. Какова вероятность (и как это работает), что код аутентификации может быть воспроизведен?

Важно отметить:

"... этот совет относится ко всем видам OAuth-клиентов, ... »фиксирует веб-приложения, в которых есть внутренний компонент, обрабатывающий запрос кода авторизации и обмен токенами доступа. Итак, мы не говорим о веб-приложении, которое ранее могло использовать неявный тип предоставления;мы говорим о веб-приложениях, которые могут использовать тип разрешения авторизации.

Answer 1

Вот основные шаги из RFC 7636.

1. Клиент включает криптографический секрет с запросом кода авторизации к конечной точке аутентификации
2. Сервер аутентификации возвращает код авторизации ссекрет, зашифрованный в коде или сохраненный на сервере аутентификации
3. Клиент отправляет код аутентификации с секретом на конечную точку токена
4. Сервер аутентификации проверяет секрет и отвечает токеном

Таким образом, сервер authz возвращает токен только в том случае, если секрет подтвержден как тот, который был отправлен ранее для кода authz.

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

Если бэкэнд обрабатывает связь с сервером authz и делает это через TLS, ему не нужно беспокоиться об атаках кода authz. Но тип предоставления кода авторизации является потоком на основе перенаправления. Возможно, вам лучше будет использовать тип предоставления учетных данных клиента. Веб-приложение здесь означает то, которое действует как клиент.