Real-World Single Sign-On With JWT, WebSockets, and Zato

Overview

In a recent project, an interesting situation occurred that let JSON Web Tokens (JWT) and WebSockets, two newly added features of Zato middleware server, be nicely employed together in practice with great results.

The starting point was the architecture as below.

Pretty common stuff; users authenticate with a front-end web application serving pages to browsers and at the same time communicating with Zato middleware that provides a unified interface to further backend systems.

WebSockets

The scenario started to look intriguing when at one point a business requirement meant that in technical terms it was decided that WebSocket connections be employed so that browsers could be swiftly notified of events taking place in backend systems.

WebSockets are straightforward and come with all modern browsers, and recently, Zato grew means to mount services on WebSocket channels (this was in addition to REST, SOAP, ZeroMQ, AMQP, WebSphere MQ, Scheduler, and all of the other already-existing channels.

The Gotcha

However, when it came to implementation, it turned out that the frontend web application is incapable of acting as a client of Zato services exposed via WebSockets.

That is, it could offer WebSockets to browsers, but would not be able itself to establish long-running WebSocket connections to Zato. It had been simply designed to work in a strict request-reply fashion and WebSockets were out of its reach.

This meant that it was not possible for Zato to notify the frontend application of new events without the frontend constantly polling for them which beat the purpose of employing WebSockets in the first place.

Thus, seeing as browsers themselves support WebSockets very well, it was agreed that there was no choice but have each user browser connect to Zato directly. WebSocket channels in Zato would ensure that browsers receive notification as they happen in backend systems.

Browser Authentication

Deciding that browsers connect directly to Zato posed a new challenge, however. Previously, users were authenticated with the front-end that had its own application-level credentials in Zato; now, browsers connecting directly to Zato would also have to authenticate.

Naturally, it was ruled out that suddenly users would be burdened with a new username and password to enter anywhere. At the same time, it was not desirable to embed the credentials in HTML served to browsers because that would have to be done in clear text.

Instead, JWT was used by the frontend application to securely establish a session in Zato and transfer its ownership to a browser.

How JWT Works in Zato

At their core, JWT (JSON Web Tokens) are essentially key-value mappings that declare that certain information is true. In the context of Zato authentication, when selected services Zato server are secured with JWT, the following happens:

• Applications need to obtain a token for the security definition assigned to the service. They do it either by sending usernames and passwords to an endpoint that returns a new token or by calling a special API service that lets an application generate a token on behalf of another application
• No matter how it was generated, the token will contain information for whom it was generated and until when it is valid.
• Such a token is next encrypted on the server side using Fernet keys (AES-128).
• After obtaining the token, the end application needs to provide it to Zato on each call.
• When a request comes in, the process is reversed. A JWT is decrypted on the server side, its validity confirmed, a service is called, and its response is returned to the calling application.
• Since tokens would have expired ultimately otherwise, their validity is extended each time a call is made to Zato with a JWT, which indicates to servers that the token is still in use.

In other words, JWT declares that a username and password combination was valid at a certain time and that this particular token was generated for that user and that it will be valid until it expires or is further prolonged.

This is very convenient and easy to understand. Another really great property of JWT is that they are extremely simple to use in JavaScript code running in browsers or elsewhere; they are just an opaque string that needs to be provided to Zato servers in a single header which is a trivial task.

Combining It All

Having all the pieces in one place meant the solution was simple. It was the frontend application that would call a custom endpoint in Zato to create a JWT for use in browsers. Since the token is safely encrypted, it can be passed around anywhere and Zato can return it to the front-end without any worries.

Once the frontend returns the token to a browser, the browser can then go ahead and open a direct WebSocket connection secured with the newly generated token. Zato receives the token, decrypts it and confirms that it is valid and was in fact generated on the server side as expected.

The net result is that browsers now have secure direct WebSocket connections to Zato, yet no user credentials are relayed anywhere in clear text.

At the same time, users started to receive notifications from backend systems and everyone was excited even though initially the situation looked bleak when it turned out that the front-end couldn't itself become a WebSockets client.