Is it possible to secure WebSocket APIs with OAuth 2.0?
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?
What are the risks if it is in a Browser compared to a web application with a Server?
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.
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.
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.
Answer
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).
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.)
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.
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.
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.
If it is, the WebSocket connection is opened and can continue. If not, the request is rejected and the connection is closed.
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.
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.
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-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:
Regards, Robin Product Manager, Kaazing