我正在实现一个 OAuth 提供程序来保护不同的基于 Web 的 API。最让我头疼的是通过 OAuth 保护 WebSockets。
可以在浏览器中设置的客户端中完全安全地完成此操作吗？
与带有服务器的 Web 应用程序相比，如果它在浏览器中存在哪些风险？
我想使用 2-legged OAuth 来限制与 Websocket 的连接，因此只有注册的客户端才能获取与 API 的 WebSocket 连接而不会被拒绝。由于 WebSocket 连接始终(!)在客户端(从浏览器)建立，是否可以保护 accessToken 不被窃取和滥用？
此时，从 Web 应用程序客户端设备设置基于浏览器的客户端的唯一方法是 URL。
如果基于浏览器的应用程序不安全，我可以接受，但我想确保至少基于 Web 的应用程序有一种安全的方式来访问 websocket。
但那时我问自己是否需要 accessToken，因为我可以只使用 origin-URI 作为唯一的安全机制。
最佳答案
是的，您可以使用 OAuth 保护您的 WebSocket 连接。 Kaazing WebSocket Gateway拥有一个优雅的架构，可以使用多种方法(基于 token 、基于 HTTP 或基于 cookie)进行身份验证和授权。
此外，它是通过网络安全地完成的，您可能会在网络上与不受信任的客户端打交道。 (或者至少，您应该始终假设您正在与不受信任的客户打交道。)
当客户端尝试 WebSocket 连接时，网关会收到请求。如果特定服务(即 URL)已配置为 protected ，则客户端将受到质询。
收到质询后，客户端需要提供一个 token (假设这就是本例中配置的内容)。如果客户端已经拥有 token ——因为他们之前已经登录到其他系统或网页——那就太好了。如果没有，那么必须获得一个。这完全取决于您对安全性的选择。在这种情况下，它会联系 OAuth token 提供商以获取 token 。这可能意味着用户必须提供凭据。
客户端获得 token 后，会将其发送到网关作为对质询的响应。网关支持标准 JAAS 架构，因此您可以插入登录模块来执行必要的身份验证。在这种情况下，它可能会将 token 发送到 token 提供者以确定它是否是有效 token 。
如果是，则 WebSocket 连接已打开并可以继续。如果不是，则拒绝请求并关闭连接。
这有利于保护您的后端应用程序——只有有效的用户才会通过网关。此外，由于 Kaazing WebSocket Gateway 可以驻留在 DMZ 中，因此未经身份验证的用户甚至永远不会进入主防火墙内的受信任网络。他们在外表上很快就会失败。
这个架构非常强大，因为无论您选择什么安全框架，Kaazing 的网关都会插入其中，而不是将其自己的安全机制强加给您。此外，在 OAUth 或 OAuth2 的情况下，它不需要理解或解码 token 。 token 提供者是唯一需要理解它的人。但是，如果您的 token 提供商想要指定 session 的持续时间，则可以将其与 token 一起包含在内，并且网关将遵守它。
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.
通过正确的架构和实现，可以确保基于 Web 和浏览器的应用程序的安全。在 Kaazing，我们始终假设您正在与网络上不受信任的客户端打交道，并相应地构建我们的架构。
以下是文档的几个部分，其中包含高级描述:
问候， 罗宾 Kaazing 产品经理
关于security - 是否可以使用 OAuth 2.0 保护 WebSocket API 的安全？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10332182/