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

Я реализую OAuth-провайдер для защиты различных веб-интерфейсов API. Самая большая головная боль дает мне защиту WebSockets через OAuth.

Может ли это быть сделано полностью безопасно на клиенте, который установлен в браузере?

Каковы риски, если он находится в браузере по сравнению с веб-приложением с сервером?

Я хочу использовать двухстороннюю OAuth для ограничения соединений с веб-сокетом, поэтому только зарегистрированные клиенты могут получить соединение WebSocket с API без получения отказа. Поскольку соединение WebSocket всегда (!) Устанавливается на стороне клиента (из браузера), возможно ли защитить accessToken от кражи и неправильного использования?
В этот момент единственная вещь, которая устанавливает клиент на основе браузера из клиентского приложения веб-приложения, - это URL.

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

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

Ответы на вопрос(2)

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

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

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

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

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

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

С Уважением,

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

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

Решение Вопроса

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

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

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

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

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

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

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

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

If browser-based applications are unsafe, I could live with that, but I want to make sure that at least the web-based applications have a secure way to access the websocket.

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

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

What Happens During Authentication How Authentication and Authorization Work with the Gateway

С Уважением, Робин Менеджер по продукции, Каазинг

 JustGoscha27 апр. 2012 г., 12:01
это хорошее решение, если требуется аутентификация пользователя, но я не совсем уверен, работает ли она, если только клиенту нужно аутентифицироваться, как в гранте учетных данных клиента в черновом варианте oauth-2.tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.4 , Там также говорится, что он должен использоваться только для конфиденциальных клиентов. Но даже если у вас есть конфиденциальный клиент, а затем вы отправляете токен доступа в браузер (для установления ws-соединения), он выставляется. Таким образом, чтобы защитить его от повторного использования, вы должны разрешить использование этого accessToken только в течение очень короткого времени или ограничить доступ к нему.

Ваш ответ на вопрос