Я не думаю, что парадигма действительно отличается от традиционного веб-приложения или API. Те же проблемы существуют, и это не имеет ничего общего с сокетами. Тот факт, что в вашей архитектуре теперь есть socket.io/nodeJS, просто означает, что аутентификация немного сложнее. Когда вы перешли от выполнения сеансов с файловой системой и одним сервером к пулу серверов и, скажем, memcached или базе данных для сеансов, это изменило способ обработки аутентификации, а не необходимость в ней. Так что в некотором смысле кажется, что вы просите разрешения разрешить это:)
Правда, только вы можете сказать, нужно ли это для вашего приложения. Если это, как вы говорите, неважно и общедоступно ... вам, вероятно, потребуется аутентификация для просмотра на странице вашего сайта в традиционном веб-приложении? Вы просто ленивый?
1) Злоупотребление. Могу ли я изменить запрос, чтобы перебрать какой-то идентификатор для сбора полезной информации?
2) Упущенная возможность. Будет ли расти Node backend? В какой-то момент вы будете сожалеть о том, что там нет аутентифицированного пользователя?
3) Отказ в обслуживании. Могу ли я сделать запросы на высокую стоимость и исчерпать ресурсы?
Вероятно, я скучаю по другим. Просто мои два цента. Позже я попытаюсь привести пример по вашему вопросу: Авторизация для паспорта laravel через socket.io для вещательных каналов