是否可以使用 OAuth 2.0 保护 WebSocket API? [英] Is it possible to secure WebSocket APIs with OAuth 2.0?
问题描述
我正在实施一个 OAuth 提供程序来保护不同的基于网络的 API.最头疼的是让我通过 OAuth 来保护 WebSockets.
I am implementing an OAuth Provider to secure different web-based APIs. The most headache is giving me the securing of WebSockets through OAuth.
可以在浏览器中设置的客户端中完全安全地完成吗?
Can it be done completely secure in a client that's set in a Browser?
与带有服务器的 Web 应用程序相比，在浏览器中的风险是什么?
What are the risks if it is in a Browser compared to a web application with a Server?
我想使用 2-legged OAuth 来限制与 websocket 的连接，因此只有注册的客户端才能获取到 API 的 WebSocket 连接而不会被拒绝.由于 WebSocket 连接总是(！)在客户端(从浏览器)建立，是否有可能保护 accessToken 不被窃取和滥用?
那时，从 Web 应用程序客户端 appart 设置基于浏览器的客户端的唯一内容是 URL.
I want to use 2-legged OAuth to restrict the connections to the websocket, so only registered clients can acquire a WebSocket connection to the API without being refused. Since a WebSocket connection is always (!) established on the client-side (from the Browser), is it possible to protect the accessToken from being stolen and misused?
At that point, the only thing that sets a browser-based client from a web-application client appart is the URL.
如果基于浏览器的应用程序不安全，我可以接受，但我想确保至少基于网络的应用程序有一种安全的方式来访问 websocket.
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.
但那时我会问自己是否需要 accessToken，因为我只能使用 origin-URI 作为唯一的安全机制.
But at that point I ask myself if the accessToken is needed at all, because than I could just use the origin-URI as only secure mechanism.
推荐答案
是的，您可以使用 OAuth 保护您的 WebSocket 连接.Kaazing WebSocket Gateway 具有使用各种方法进行身份验证和授权的优雅架构(基于令牌、基于 HTTP 或基于 cookie).
Yes you can secure your WebSocket connections using OAuth. Kaazing WebSocket Gateway has an elegant architecture for authentication and authorization using a variety of methods (token-based, HTTP-based, or cookie-based).
此外，它是以一种在 Web 上安全的方式完成的，您可能会在其中处理不受信任的客户端.(或者至少，您应该始终假设您正在与不受信任的客户打交道.)
Moreover it is done in a way that is secure over the Web where you may be dealing with untrusted clients. (Or at least, you should always assume you are dealing with untrusted clients.)
当客户端尝试 WebSocket 连接时，网关会收到请求.如果已将特定服务(即 URL)配置为受保护，则客户端将受到质询.
When a client attempts a WebSocket connection, the Gateway receives the request. If the particular service (i.e. URL) has been configured to be protected, the client will be challenged.
在收到质询后，客户端需要提供一个令牌(假设这是在这种情况下配置的).如果客户端已经拥有令牌——因为他们之前已经登录到某个其他系统或网页——那就太好了.如果没有，那么它必须获得一个.这完全取决于您选择的安全性.在这种情况下，它会联系 OAuth 令牌提供者以获取令牌.这可能意味着用户必须提供凭据.
Upon receiving the challenge the client needs to then supply a token (assuming that's what has been configured in this case). If the client already has the token -- because they've previously signed on to some other system or web page -- then great. If not then it must be obtain one. This depends entirely on your choice of security. In this case it contacts the OAuth token provider to obtain a token. That may mean the user having to provide credentials.
一旦客户端拥有令牌，它会将其发送到网关作为对质询的响应.网关支持标准的 JAAS 架构，因此您可以插入登录模块以执行必要的身份验证.在这种情况下，它可能会将令牌发送给令牌提供者以确定它是否是有效令牌.
Once the client has a token it sends it to the Gateway as a response to the challenge. The Gateway supports the standard JAAS architecture so you can plug in login modules to perform the necessary authentication. In this case it may send the token to the token provider in order to determine if it's a valid token.
如果是，则WebSocket连接打开，可以继续.如果不是，则拒绝请求并关闭连接.
If it is, the WebSocket connection is opened and can continue. If not, the request is rejected and the connection is closed.
这有利于保护您的后端应用程序——只有有效用户才能通过网关.此外，由于 Kaazing WebSocket 网关可以存在于 DMZ 中，未经身份验证的用户甚至永远不会进入您的主防火墙内的受信任网络.他们在外面很快就失败了.
This has the benefit of protecting your back-end applications -- only valid users will pass through the Gateway. Furthermore, because Kaazing WebSocket Gateway can live in the DMZ, un-authenticated users never even enter the trusted network within your main firewall. They fail fast on the outside.
这种架构很强大，因为无论您选择哪种安全框架，Kaazing 的网关都会插入其中，而不是将自己的安全机制强加给您.此外，在 OAUth 或 OAuth2 的情况下，它不需要理解或解码令牌.令牌提供者是唯一需要理解它的人.但是，如果您的令牌提供者想要指定会话的持续时间，则可以将其与令牌一起包含在内，网关将遵守它.
This architecture is powerful because it doesn't matter what security framework you have chosen, Kaazing's Gateway will plug in to it, rather than imposing its own security mechanism on you. Also, in the case of OAUth or OAuth2, it does not need to understand or decode the token. The token provider is the only one that needs to understand it. But if your token provider wants to specify a duration for the session, that can be included along with the token and the Gateway will honor it.
如果基于浏览器的应用程序不安全，我可以接受，但我想确保至少基于网络的应用程序有一种安全的方式来访问 websocket.
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，我们始终假设您正在与网络上不受信任的客户打交道，并相应地构建我们的架构.
Web-based and browser-based applications can be made safe with the right architecture and implementation. At Kaazing we always operate under the assumption that you are dealing with untrusted clients on the Web and construct our architecture accordingly.
以下是文档的几个部分，它们具有高级描述:
Here are couple sections of the documentation that have a high-level description:
问候，罗宾Kaazing 产品经理
Regards, Robin Product Manager, Kaazing
这篇关于是否可以使用 OAuth 2.0 保护 WebSocket API?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
