Как организовать хранение чувствительных данных в рамках сессии?

Question

[федор unknown]

Есть несколько цепочка запросов:
1. Фронт передает мне пароль
2. Отправляю пароль и логин в сторонний API и в ответ получаю двухфакторный токен
3. С двухфакторным токеном запрашиваю ОТП код
4. Фронт передает мне ОТП
5. Передаю ОТП код стороннему API и получаю session token
6. С полученным session token запрашиваю данные пользователя

7. Необходимо сохранить в базу данных логин, пароль и session token чтобы пользователь при след открытии не проходил опять двух факторную аудентификацию.

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

Используемые технологии: Spring boot + java 11

Comments

[Модератор]

Не надо ставить как можно больше тэгов. Лучше оставить один, но конкретный, с которым проблема.
См.п.3.1 Регламента.

[Модератор]

На вопрос «как сделать» отвечает документация и поиск в интернет.

Тут отвечают на вопросы «почему я сделал, как в документации, а оно не работает. Поискал в интернет, вот запросы, в ответах не нашел. Что я делаю не так?»

Покажите, как вы пробовали решить проблему, приведите код попытки (пусть неудачной), опишите, как запускали, что ожидали и что получилось.
За готовыми решениями - на фриланс. В текущем виде это не вопрос, а задание. Нарушен п.5.12 Регламента.

[федор unknown]

Модератор, Спасибо, поправил

Answer 1

[AlexVWill]

Фронт передает мне пароль

С самого начала уже сомнительный тезис.
Во первых "мне" это кому? Во вторых в соответствии с правилами безопасности пароль никогда не должен покидать клиентское устройство, отправлять можно только хэш пароля, а шифрование пароля должно быть исключительно на клиентском устройстве. Т.е. сам пароль ни в коем случае никуда отправлять нельзя.
Про остальное можно почитать
https://developers.google.com/identity/sign-in/web...

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

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

Comments

[Василий Банников]

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

С какими такими правилами?
Никто в браузере хэшированием паролей не занимается, тк в этом просто нет смысла.

[AlexVWill]

Василий Банников, при чем тут браузер?

[Василий Банников]

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

Также этот принцип бесполезен, если 3rd party требует передачи пароля и весь твой продукт строится именно на взаимодействии с этим третьим 3rd party.

- это как раз и есть случай, с которым столкнулся автор вопроса.

С точки зрения безопасности следовало бы поискать - может у этого 3rd party есть поддержка OAuth и можно безопасно обменяться токена и, не паля пароли (но в данном случае слитые пароли скорее являются проблемой пользователя, тк это он решил их доверить третьему лицу - автору вопроса)

Но суть самого вопроса Я не понял

[Kano]

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