Проблемы безопасности с RESTful-аутентификацией и управлением сессиями
Я пытаюсь реализовать аутентификацию и управление сессиями для микросервиса. Для того, чтобы выполнить процесс RESTful, я понимаю, что мне нужно будет использовать некоторую аутентификацию на основе токенов, чтобы избежать отслеживания данных сеанса клиента на сервере. Следующая цитата из этого ответа на бирже стека информационной безопасности хорошо подводит итог моего понимания реализации:
При аутентификации на основе токенов ни один сеанс не сохраняется на стороне сервера (без сохранения состояния). Начальные шаги одинаковы. Учетные данные обмениваются с токеном, который затем присоединяется к каждому последующему запросу (его также можно сохранить в файле cookie). Однако с целью уменьшения использования памяти, легкого масштабирования и полной гибкости выдается строка со всей необходимой информацией (токеном), которая проверяется после каждого запроса, сделанного клиентом на сервер.
Из этого я понимаю, что обслуживание сеансов без сохранения состояния выгодно для масштабируемости и гибкости, как объяснено. Но мне кажется, что это оставляет приложение подверженным некоторым серьезным проблемам:
- Если хакер каким-то образом перехватывает вызов HTTP REST обмена учетными данными, он может выполнить атаки воспроизведения на сервере и получить всю необходимую информацию.
- Фактически, поскольку токен сеанса хранится на стороне клиента, может ли хакер просто получить необходимую информацию из LocalStorage/SessionStorage путем отладки приложения? Или путем мониторинга входящих и исходящих HTTP-вызовов с помощью инструментов разработчика? Если они получат требуемую информацию о токене (даже зашифрованную информацию о токене), они могут просто начать подделывать вызовы REST на сервер из другого окна и получать все необходимые данные!
- Наконец, даже если вы дадите клиенту токен сеанса, разве серверу все равно не придется аутентифицировать этот токен? По сути, сервер должен будет поддерживать маркеры сеансов в сопоставлениях пользователей... но разве это не противоречит цели архитектуры без REST на основе состояния?
Может быть, я вижу эти проблемы, потому что в моем понимании есть пробел. Если это так, я бы хотел немного прояснить основные понятия. Если нет, я хотел бы знать, есть ли какие-либо методы для решения этих конкретных проблем.