Можно ли защитить API WebSocket с помощью OAuth 2.0?

Ответ 1

Да, вы можете защитить свои подключения к WebSocket, используя OAuth. Kaazing WebSocket Gateway имеет элегантную архитектуру для аутентификации и авторизации с использованием различных методов (основанных на токенах, на основе HTTP или на основе файлов cookie).

Кроме того, это делается безопасным способом в Интернете, где вы можете иметь дело с ненадежными клиентами. (Или, по крайней мере, вы всегда должны полагать, что имеете дело с ненадежными клиентами.)

Когда клиент пытается подключиться к WebSocket, шлюз получает запрос. Если конкретная услуга (т.е. URL) настроена для защиты, клиент будет оспорен.

После получения вызова клиенту необходимо предоставить токен (при условии, что в этом случае было настроено). Если у клиента уже есть токен - потому что они ранее подписались на какую-либо другую систему или веб-страницу - тогда это здорово. Если нет, то он должен получить его. Это полностью зависит от вашего выбора безопасности. В этом случае он связывается с поставщиком токенов OAuth для получения токена. Это может означать, что пользователь должен предоставить учетные данные.

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

Если это так, соединение WebSocket открывается и может продолжаться. Если нет, запрос отклоняется и соединение закрывается.

Это полезно для защиты ваших back-end приложений - только действительные пользователи будут проходить через шлюз. Кроме того, поскольку Kaazing WebSocket Gateway может жить в DMZ, пользователи, не прошедшие аутентификацию, даже не входят в доверенную сеть в вашем основном брандмауэре. Они не работают быстро снаружи.

Эта архитектура является мощной, потому что неважно, какая система безопасности вы выбрали, Kaazing Gateway подключится к ней, а не наложит на вас собственный механизм безопасности. Кроме того, в случае OAUth или OAuth2 ему не нужно понимать или декодировать токен. Поставщик токенов - единственный, кто должен его понять. Но если ваш поставщик токенов хочет указать продолжительность сеанса, который может быть включен вместе с токеном, и шлюз будет его соблюдать.

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

Веб-приложения и браузерные приложения могут быть безопасными с правильной архитектурой и реализацией. В Kaazing мы всегда работаем в предположении, что вы имеете дело с ненадежными клиентами в Интернете и соответствующим образом строите нашу архитектуру.

Вот несколько разделов документации, которые содержат описание высокого уровня:

• Что происходит во время проверки подлинности
• Как аутентификация и авторизация работают со шлюзом

С уважением, Робин Менеджер по продуктам, Kaazing

Ответ 2

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

Теперь предположим, что вы настроили безопасный способ получить ваши учетные данные или получить токен доступа в свой браузер через обычный запрос OAuth2.

В соответствии со спецификацией OAuth2 вы можете свободно делиться частями MAC-шифрования, шифровать части или защищать данные в этом токене любым количеством способов. Безопасность маркера доступа в браузере зависит от того, какую информацию он содержит - часто, когда люди проектируют его, он содержит минимальную информацию (идентификатор пользователя, время истечения срока действия, версию, дайджест) и делает его самоконтролируемым вашим сервером (следовательно, дайджест), Содержимое токена практически произвольно. Некоторые системы даже выдают "коды" доступа в качестве прокси для токена.

Теперь предположим, что у вас есть защищенный токен доступа "защищенного формата" с ограничением по времени. Давайте рассмотрим пример реального мира: Facebook и их реализацию OAuth2. Будь то маркер полного доступа или код доступа для получения учетных данных на стороне сервера (каждый с ограничениями по времени), вы можете отправить токен (или код) из браузера для обеспечения доступа к WebSocket с помощью шлюза Kaazing.

Одна из вещей, которые я убрал от работы с шлюзом Kaazing, - это то, что OAUth2 действительно ничего не защищает - вы можете раздавать токены доступа произвольной формы. Это хорошая идея, чтобы убедиться, что ваша схема проверки подлинности, формат access_token и время доступа access_token являются хорошими политическими решениями - тогда вы получаете безопасность.

Kaazing Gateway позволит вам отправлять произвольные токены в шлюз и проверять их с помощью модуля входа JAAS, который вы пишете для их проверки. Безопасность режима зависит от вас и политических решений.

Привет,

Стивен Аткинсон

Разработчик шлюзового сервера, Kaazing