OAuth хранит идентификатор клиента и секрет в базе данных - PullRequest
Новая
       42

OAuth хранит идентификатор клиента и секрет в базе данных

0 голосов
/ 16 декабря 2018

Я читал статью о OAuth 2.0 с jwt токенами.Интересная часть - когда автор описывает client_secret, он говорит:

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

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

У меня вопрос, что автор имел в виду под вышеупомянутой цитатой.Является ли это тем, что клиент (в данном случае приложение веб-интерфейса) выполняет вызов, используя client_id и secret (здесь ничего не меняется), но серверная часть проверяет предоставленные «учетные данные», а не сравнивает их со значениями, хранящимися в простом тексте (в *)1016 * в этом случае), но сделать хеш из полученных значений и сравнить с хешированной версией в db?

EDITED : Example of use case

  1. Пользователь john doe открывает страницу log in.Предоставляет учетные данные: username:john.doe и password:john1.Клики sign in.
  2. Angular-frontend перехватывает запрос и выполняет метод (например, obtainTokenForUser()), чтобы получить действительный для короткого периода токен jwt для пользователя.По этой причине angular-app отправляет OAuth2.0 -совместимый запрос на authorization server.Перед отправкой контанта AWS KMS необходимо получить его client_id и secret, чтобы прикрепить к запросуВ итоге запрос от angular к auth серверу выглядит так: curl front-app-sp3:frnt4pP@<auth_server_ip_addr>:<auth_server_port>/oauth/token -d grant_type=password -d username=john.doe -d password=john1
  3. Authorization server контакты AWS KMS для полученных client_id:front-app-sp3 и client_secret:frnt4pP.Он находит запись, пароли совпадает, проверка правильности.Auth server генерирует действительный токен JWT, например, 5 minutes.Токен подписывается сервером с использованием AS_pr1v4t3 закрытого ключа.Authorization server возвращает токен в приложение angular.
  4. Пользователь вошел в систему. Пользователь запрашивает ресурс в основном приложении (весной), поэтому angular добавляет полученный токен и отправляет запрос в «Main-web».Приложение ".
  5. Resource server в" Основном веб-приложении "проверяет токен.Токен правильный и действительный.Ресурс возвращается.

1 Ответ

0 голосов
/ 16 декабря 2018

Не думаю, что автор имеет в виду это.(S) он говорит о том, что вместо client_id и client_secret в вашем приложении они должны быть сохранены в БД, к которой ваш бэкэнд может получить доступ через другой API.Я бы сказал, что client_id больше относится к application.properties, чем к секретной службе управления. Ваш интерфейс (в данном случае угловое приложение) никогда не должен иметь доступа к идентификатору клиента или его секрету.Ваш сервер, к которому подключено приложение angular (через некоторые службы REST, которые я представляю), также никогда не должен иметь прямого доступа к секретам, он должен проходить через отдельный API управления секретами. Это нормально, что ваш сервер имеет client_id в свойствах приложения, но секрет должен храниться в очень безопасном месте.

Это уже реализованный шаблон.Вместо того, чтобы иметь секретные значения непосредственно в файле app.config / application.properties, вы должны иметь их в виде:

Это позволит вам хранить / обновлять / извлекать и вращать свои секреты.

...