Какой безопасный способ отправки запроса на / oauth / token в Spring Security?

Question

Каков идеальный / безопасный способ отправки запроса из клиентского приложения на получение токена доступа?

У меня есть REST API (разработанный с использованием Spring Boot), который используется клиентским приложением (разработаниспользуя React.js) этого API.Например, Stackoverflow имеет внутренний API, и его клиент использует этот API.API REST защищен с использованием OAuth2.

Конечной точкой, в которой API возвращает маркер доступа, является

http://192.168.43.70:8085/api/v1/oauth/token?grant_type=password&username=22@gmail.com&password=mypassword

вместе с секретом клиента.Вот запрос из React.js:

axios
    .create({
      baseURL:
        "http://192.168.43.70:8085/api/v1/oauth/token?grant_type=password&username=22@gmail.com&password=mypassword",
      auth: {
        username: "my-client",
        password: "ZS10ZXN0"
      }
    })

Это правильный путь, поскольку мы открываем клиентские секреты ("my-client", "bGl2ZS10ZXN0") для браузера, откуда любой может увидетьучетные данные клиента, используемые для этого запроса?

Answer 1

Учетные данные пароля владельца ресурса. Предоставление не является правильным типом предоставления для вашего приложения, см. RFC 6749 :

4.3.Предоставление учетных данных пароля владельца ресурса

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

Вы можете использовать неявное предоставление, см. RFC 6749 :

4.2.Неявное предоставление

Тип неявного предоставления используется для получения маркеров доступа (он не поддерживает выдачу маркеров обновления) и оптимизирован для общедоступных клиентов, для которых известно, что они работают с определенным URI перенаправления.Эти клиенты обычно реализуются в браузере с использованием языка сценариев, такого как JavaScript.

[...]

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

, но некоторые серверы авторизации не поддерживают его из-за безопасностипроблемы.Spring Security OAuth2 поддерживает его.

Вы также можете использовать код авторизации, хотя он оптимизирован для конфиденциальных клиентов, см. RFC 6749 :

4.1.Предоставление кода авторизации

Тип предоставления кода авторизации используется как для получения токенов доступа, так и для обновления токенов, и оптимизирован для конфиденциальных клиентов.

[...]

Если тип клиента является конфиденциальным или клиенту были выданы учетные данные клиента (или ему были назначены другие требования к аутентификации), клиент ДОЛЖЕН пройти аутентификацию на сервере авторизации, как описано в разделе 3.2.1.

, но некоторая авторизациясерверы не поддерживают его из-за проблем безопасности.Стандартная конфигурация Spring Security OAuth2 требует аутентификации клиента.

Другим способом было бы предоставление кода авторизации с PKCE, см. RFC 7636 :

Ключ подтверждения для обмена кодами публичными клиентами OAuth

Аннотация

Публичные клиенты OAuth 2.0, использующие предоставление кода авторизации, подвержены атаке перехвата кода авторизации.В этой спецификации описывается атака, а также методика противодействия угрозе путем использования Proof Key для обмена кодами (PKCE, произносится как «pixy»).

, но Spring Security не поддерживает егосм. 4943 .

Answer 2

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

Я бы порекомендовал вам взглянуть на поток предоставления authorization_code (без секрета клиента) вместо предоставления паролятечь.Существует пара из ресурсов , которые дадут вам дополнительную информацию о том, почему не следует использовать поток паролей, но кратко из первого:

Single-Страничные приложения (или приложения на основе браузера) запускаются полностью в браузере после загрузки исходного кода Javascript и HTML с веб-страницы.Поскольку весь источник доступен для браузера, они не могут сохранять конфиденциальность клиентского секрета, поэтому этот секрет не используется в этих приложениях.Поток точно такой же, как поток кода авторизации , но на последнем шаге код авторизации обменивается на токен доступа без использования секрета клиента.

Еще лучшетем не менее, если вы можете представить серверный компонент, который согласовывает с вашим клиентом, скажем, JSESSIONID (подразумевающий переход на сессионный бэкэнд), то я полагаю, вы обнаружите, что секреты гораздо проще поддерживать вбэкенд .Для этого вы можете обратиться к поддержке клиента OAuth 2.0 в Spring Security .