Is it possible to secure WebSocket APIs with OAuth 2.0?

Question

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.

Solution 1

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:

• What Happens During Authentication
• How Authentication and Authorization Work with the Gateway

Regards, Robin Product Manager, Kaazing

Solution 2

A credentials grant is only as secure as the authentication performed before handing out the access token. That's outside the specification they say. So that depends on whatever authentication regime you decide to put in front of giving out tokens in response to credential grants.

Now, let's assume you've set up a nice secure way to get your credentials grant, or get an access token into your browser via a regular OAuth2 request.

Under the OAuth2 specification you are free to MAC-digest portions, encrypt portions or protect the data within that token in any number of ways. The security of the access token in the browser depends on what information it contains - often times people design it to contain minimal information (userid, expiration-time, version, digest) and make it self-verifiable by your server (hence the digest). The contents of the token are virtually arbitrary. Some systems even give out access "codes" as proxies for the token.

Now let's assume you have a protected "secure format" access token, with a time restriction. Lets consider a real-world example: Facebook and their OAuth2 implementation. Be it a full access token or an access code for server-side credential retrieval (each with time restrictions) you can send the token (or code) from the browser to secure access to a WebSocket, using the Kaazing Gateway.

One of the things I've taken away from working with Kaazing's gateway is that OAUth2 really doesn't secure anything - you are free to hand out access tokens of arbitrary form. It's a good idea to make sure your credential-authentication scheme, the access_token format and the access_token lifetime are all good policy decisions - then you get security.

The Kaazing Gateway will let you send arbitrary tokens into the Gateway and validate them with a JAAS login module that you write to verify them. The security of the regime is up to you and policy decisions.

Regards,

Steven Atkinson

Gateway Server Developer, Kaazing

Comments

[JustGoscha]

that's a good solution if a user authentication is needed, but I'm not quite sure if it works if only the Client needs to authenticate itself like in the client credentials grant in the oauth-2 draft tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.4 . There it also says it must be only used for confidential clients. But even if you have a confidential client and then you send the accesstoken to the Browser(to establish ws connection), it is exposed. So to protect it from beeing reused you'd have allow this accessToken to only be used for a very short time or restrict access to one.