是否可以使用OAuth 2.0保护WebSocket API?

Jus*_*cha 19 security oauth websocket oauth-provider oauth-2.0

我正在实施OAuth提供程序以保护不同的基于Web的API.最头疼的是让我通过OAuth保护WebSockets.

可以在浏览器中设置的客户端中完全安全吗?

与具有服务器的Web应用程序相比,如果它在浏览器中有什么风险?

我想使用2-legged OAuth来限制与websocket的连接,因此只有注册的客户端才能获得与API的WebSocket连接而不被拒绝.由于WebSocket连接始终(!)在客户端(来自浏览器)建立,是否可以保护accessToken不被窃取和滥用?
此时,从Web应用程序客户端appart设置基于浏览器的客户端的唯一方法是URL.

如果基于浏览器的应用程序不安全,我可以忍受,但我想确保至少基于Web的应用程序有一个安全的方式来访问websocket.

但是那时我问自己是否需要accessToken,因为我只能使用origin-URI作为唯一的安全机制.

Rob*_*ann 8

是的,您可以使用OAuth保护您的WebSocket连接.Kaazing WebSocket Gateway具有优雅的架构,可使用各种方法(基于令牌,基于HTTP或基于cookie)进行身份验证和授权.

此外,它以一种在Web上安全的方式完成,您可能正在处理不受信任的客户端.(或者至少,你应该总是假设你正在与不受信任的客户打交道.)

当客户端尝试WebSocket连接时,网关会收到请求.如果特定服务(即URL)已配置为受保护,则客户端将受到质疑.

收到挑战后,客户端需要提供令牌(假设这是在这种情况下配置的).如果客户端已经拥有令牌 - 因为他们之前已经登录过其他系统或网页 - 那就太好了.如果没有,则必须获得一个.这完全取决于您选择的安全性.在这种情况下,它会联系OAuth令牌提供程序以获取令牌.这可能意味着用户必须提供凭证.

一旦客户端有令牌,它就会将其作为对挑战的响应发送给网关.网关支持标准JAAS体系结构,因此您可以插入登录模块以执行必要的身份验证.在这种情况下,它可以将令牌发送到令牌提供者,以便确定它是否是有效令牌.

如果是,则打开WebSocket连接并继续.如果不是,则拒绝该请求并关闭连接.

这样可以保护您的后端应用程序 - 只有有效用户才能通过网关.此外,由于Kaazing WebSocket Gateway可以存在于DMZ中,因此未经过身份验证的用户甚至不会进入主防火墙内的可信网络.他们在外面快速失败.

这种架构非常强大,因为您选择的安全框架无关紧要,Kaazing的Gateway将插入其中,而不是将自己的安全机制强加给您.此外,在OAUth或OAuth2的情况下,它不需要理解或解码令牌.令牌提供程序是唯一需要了解它的人.但是,如果您的令牌提供者想要指定会话的持续时间,那么可以将其与令牌一起包括在内,并且网关将遵守该令牌.

如果基于浏览器的应用程序不安全,我可以忍受,但我想确保至少基于Web的应用程序有一个安全的方式来访问websocket.

通过正确的架构和实现,可以使基于Web和基于浏览器的应用程序变得安全.在Kaazing,我们总是假设您在Web上处理不受信任的客户并相应地构建我们的架构.

以下是具有高级描述的文档的几个部分:

此致,Robin产品经理,Kaazing