是的,您可以使用 OAuth 保护您的 WebSocket 连接。Kaazing WebSocket 网关具有优雅的架构,可使用多种方法(基于令牌、基于 HTTP 或基于 cookie)进行身份验证和授权。
此外,它以一种在 Web 上安全的方式完成,您可能正在与不受信任的客户端打交道。(或者至少,您应该始终假设您正在与不受信任的客户打交道。)
当客户端尝试 WebSocket 连接时,网关会接收请求。如果特定服务(即 URL)已被配置为受保护,则客户端将受到挑战。
收到挑战后,客户端需要提供一个令牌(假设在这种情况下已配置)。如果客户端已经拥有令牌——因为他们之前已经登录到其他系统或网页——那就太好了。如果没有,那么它必须获得一个。这完全取决于您选择的安全性。在这种情况下,它会联系 OAuth 令牌提供者以获取令牌。这可能意味着用户必须提供凭据。
一旦客户端拥有一个令牌,它就会将其发送到网关作为对质询的响应。网关支持标准 JAAS 架构,因此您可以插入登录模块来执行必要的身份验证。在这种情况下,它可以将令牌发送给令牌提供者以确定它是否是有效令牌。
如果是,则 WebSocket 连接已打开并可以继续。如果不是,则拒绝请求并关闭连接。
这有利于保护您的后端应用程序——只有有效用户才能通过网关。此外,由于 Kaazing WebSocket 网关可以存在于 DMZ 中,未经身份验证的用户甚至永远不会进入主防火墙内的可信网络。他们在外面很快就失败了。
这种架构非常强大,因为无论您选择什么安全框架,Kaazing 的网关都会插入其中,而不是将其自己的安全机制强加给您。此外,在 OAUth 或 OAuth2 的情况下,它不需要理解或解码令牌。令牌提供者是唯一需要了解它的人。但是,如果您的令牌提供者想要指定会话的持续时间,则可以将其与令牌一起包含在内,网关将接受它。
如果基于浏览器的应用程序不安全,我可以忍受,但我想确保至少基于 Web 的应用程序具有访问 websocket 的安全方式。
通过正确的架构和实现,可以使基于 Web 和基于浏览器的应用程序变得安全。在 Kaazing,我们始终假设您在 Web 上与不受信任的客户打交道,并相应地构建我们的架构。
以下是文档中包含高级描述的几个部分:
问候,Robin 产品经理,Kaazing