Проектирование логики аутентификации и авторизации: cookies, JWT, SSO, OAuth 2.0.

[@deniskirdyanov1389]

Подскажите, пожалуйста, такой вопрос. Требуется реализовать интеграцию с внешним сервисом авторизации через звонок на телефон. Интеграцию предоставляет оператор ОБИТ. Предварительно наш сервер авторизации должен авторизоваться в их сервисе, предоставив имя и пароль. Как правильно хранить пароли в этом случае. Читаю, что пароли необходимо хранить в кешированном представлении на сервере. Но в данном случае это не представляется возможным. Есть ли бест практики помимо шифрования паролей, как замена кешированию? P/S Интеграций может быть много, и, соответственно, много учетных данных, требующих правильного хранения (с точки зрения ИБ).

[@enkryp]

Тут несколько смущает использование логина-пароля для общения между серверами. Возможно, имеет смысл уточнить у ОБИТ, какие иные способы авторизации у них есть - например, через API-токен, или тот же OAuth. В любом случае, у вас будет некий секрет (токен или пароль), с которым нужно поступить как и с другими секретами (например, креденшлами подключения к БД). Их можно и шифровать, а можно просто хранить как часть конфигурации на развертывании. Главное не класть их в исходный код или БД, куда могут получить доступ пользователи. Впрочем, даже зная пароль, злоумышленник сможет лишь заказать звонок за ваш счёт, то есть никакие данные клиентов он украсть не сможет. Хэширование тут не поможет, поскольку, чтобы отправлять пароль, вам нужно его хранить. Когда говорят, что на сервере надо хэшировать пароли, имеется в виду, что пароли при этом вообще не хранятся, хранятся только хэши. Хэши позволяют проверить правильность пароля, не позволяя узнать при этом сам пароль.

[@deniskirdyanov1389]

@@enkryp Большое спасибо за ответ.

[@deniskirdyanov1389]

Добрый день. Подскажите, пожалуйста, почему мобильное приложение перекидывает пользователя на форму авторизации на сервере авторизации? Может ли пользователь ввести учетные данные в форме мобильного приложения и в параметрах сразу передать их на сервер, а в ответ получить пару токенов (так мы исключаем код доступа для приложения)?

[@sys_analyst_club]

Добрый день. Вопрос отправили Виталию, ждём ответ.

[@enkryp]

Если я правильно понял вопрос: вы хотите, чтобы пользователь вводил логин-пароль не на сайте SSO провайдера, а в самом приложении. Если так, то это несколько противоречит самой сути SSO. Его смысл как раз в том, чтобы убрать потребность ввода пароля в приложении. Если вам это не нужно, то возможно вам не нужно SSO. Есть много причин, почему не стоит вводить пароль в приложении: 1. Первое и главное - вопрос безопасности. Логин, пароль и любые креденшлы не должны проходить через приложение. С ними работает только SSO-провайдер. Так пользователь получает гарантию, что стороннее приложение не узнает и не перехватит его пароль. 2. Пользователь может быть уже авторизован у SSO провайдера. В этом случае ввод логина-пароля не требуется, нужно только авторизировать приложение. 3. Пользователь может выбрать другой способ аутентификации у SSO провайдера. Например, подтверждение по SMS. Пароля в этом случае тоже не будет. Единственный сценарий, в котором такое мне кажется оправданным - когда аутентификация происходит внутри вашей инфраструктуры (например, через тот же keycloak). В этом случае вы можете настроить всё так, как хотите, в том числе с прямой пересылкой логина-пароля.

[@deniskirdyanov1389]

@@enkryp Огромное спасибо за ответ! С этим моментом теперь все разъяснилось! Остался последний вопрос - сервер авторизации выдает мобильному приложению код авторизации, который затем приложение обменивает на токены доступа к серверу ресурсов. Почему сервер авторизации сразу не отправляет токены доступа мобильному приложению?

[@enkryp]

Не могу сказать точно про поведение сервера авторизации, тут надо смотреть конкретный сервер и отношения между ним и вашей системой.

[@deniskirdyanov1389]

@@enkryp еще раз спасибо.