Мы разрабатываем веб-приложение, которое будет получать некоторые данные через веб-сокет. Мы обслуживаем его из CloudFront по SSL, серверная часть находится на AWS. Мы аутентифицируем пользователей с помощью Cognito для входа в приложение, и мы также хотели бы использовать токен Cognito для настройки аутентификации для веб-сокета. Кроме того, мы хотим, чтобы токен был частью первой попытки подключения, чтобы мы не открывали соединение ни с кем, а затем ждали какого-нибудь сообщения magi c, содержащего auth, которое, вероятно, может привести к DDoS-атакам.
Первой мыслью было добавить токен в заголовок авторизации, но стандарт websocket не поддерживает добавление заголовков.
Во-вторых, мы подумали о добавлении повара X-авторизации ie с token, таким образом, повар ie будет отправлен как часть запроса на открытие сокета. Это не удалось (вероятно), потому что в процессе разработки домен cook ie установлен на "localhost" и не будет отправлен на URL-адрес веб-узла aa.bb.com.
Наш следующий шаг - добавить токен к URL-адресу в качестве параметра запроса, и, похоже, он работает.
Теперь у меня вопрос, достаточно ли это безопасно, или мы должны рассмотреть что-то вроде двухэтапного подхода, сначала получить токен входа из другой конечной точки, а затем использовать его в качестве параметра запроса при открытии веб-сокет?