Да, вы можете защитить свои подключения к WebSocket, используя OAuth. Kaazing WebSocket Gateway имеет элегантную архитектуру для аутентификации и авторизации с использованием различных методов (основанных на токенах, основанных на HTTP или на основе файлов cookie).
Кроме того, это делается безопасным способом в Интернете, где вы можете иметь дело с ненадежными клиентами. (Или, по крайней мере, вы всегда должны полагать, что имеете дело с ненадежными клиентами.)
Когда клиент пытается подключиться к WebSocket, шлюз получает запрос. Если конкретная услуга (т. Е. URL) настроена для защиты, клиент будет оспорен.
После получения запроса клиент должен предоставить токен (при условии, что именно это было настроено в этом случае). Если у клиента уже есть токен - потому что они ранее подписались на какую-либо другую систему или веб-страницу - тогда это здорово. Если нет, то он должен получить его. Это полностью зависит от вашего выбора безопасности. В этом случае он связывается с поставщиком токенов OAuth для получения токена. Это может означать, что пользователь должен предоставить учетные данные.
Как только у клиента есть токен, он отправляет его на шлюз в качестве ответа на вызов. Шлюз поддерживает стандартную архитектуру JAAS, поэтому вы можете подключать модули входа для выполнения необходимой проверки подлинности. В этом случае он может отправить токен поставщику токенов, чтобы определить, является ли он действительным токеном.
Если это так, соединение WebSocket открывается и может быть продолжено. Если нет, запрос отклоняется и соединение закрывается.
Это преимущество защиты ваших задних приложений - только действительные пользователи будут проходить через шлюз. Кроме того, поскольку Kaazing WebSocket Gateway может жить в DMZ, пользователи, не прошедшие аутентификацию, даже не входят в доверенную сеть в вашем основном брандмауэре. Они быстро выходят наружу.
Эта архитектура является мощной, поскольку не имеет значения, какая система безопасности вы выбрали, шлюз Kaazing подключится к ней, а не наложит на вас свой собственный механизм безопасности. Кроме того, в случае OAUth или OAuth2 ему не нужно понимать или декодировать токен. Поставщик токенов - единственный, кто должен его понять.Но если ваш провайдер токенов хочет указать продолжительность сеанса, который может быть включен вместе с токеном, и Gateway будет его соблюдать.
Если приложения на базе браузера небезопасны, я мог бы жить с этим, но я хочу убедиться, что, по крайней мере, веб-приложения имеют безопасный доступ к веб-расписанию.
Веб-приложения и браузерные приложения могут быть безопасными с правильной архитектурой и реализацией. В Kaazing мы всегда работаем в предположении, что вы имеете дело с ненадежными клиентами в Интернете и соответствующим образом строите нашу архитектуру.
Вот пару разделов документации, которые имеют высокоуровневое описание:
С уважением, Робин менеджер по продукции, Kaazing
это хорошее решение, если проверка подлинности пользователя требуется, но я не совсем уверен, если это работает, если только клиент необходимо аутентифицировать себя, как в предоставлении учетных данных клиента в проекте oauth-2 http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.4. Там также говорится, что он должен использоваться только для конфиденциальных клиентов. Но даже если у вас есть конфиденциальный клиент, а затем вы отправляете accesstoken в браузер (для установления соединения ws), он открывается. Поэтому, чтобы защитить его от повторного использования, вы позволили бы этому accessToken использоваться только в течение очень короткого времени или ограничивать доступ к нему. – JustGoscha