It’s quite common for cloud services (and webtail vendors) to integrate with a digital identity platform, such as Google+ or Facebook; the reasons for doing so are very well documented. The beaten path for this type of integration is to use three-legged OAuth. But when implementing a real-time solution, there are additional touchpoints to consider for a more cohesive integration.
In traditional two-legged authentication, the resource owner (AKA the user) simply supplies a username and password to the application. The application then stores and forwards those credentials on to the identity provider. In turn, the authentication provider allows access to protected resources.
While two-legged authentication works for rich integrations, like those found on mint.com, three-legged authentication provides a much more secure authentication. For one, it removes the need for your application to manage third-party user credentials. It also preserves the end user’s ability to constrain and revoke access to your app as needed.
With digital streams like PubNub’s pub/sub, the protected resource is the channel. Channels ensure data is transferred from the origin/publisher to channel subscribers. They are dynamic and identified by a simple string (i.e. the channel name).
In non-secure applications, simply initializing PubNub, subscribing, and publishing messages to a collection of channels is trivial. However, if you need to secure your application you will need some way to provision users as they log in. To do this you will need a traffic cop that can identify the request sent from the client application and ensure that client is authorized.
This role is typically done by a fourth component: a Security Authority (SA). It’s usually a collection of HTTP endpoints that are responsible for mapping an identity to a set of permissions. The HubBub server includes a node-based express app which makes it a great Security Authority, as its primary responsibility is to interact with Access Manager. We will address how to implement that later, but first let’s review what three-legged authentication looks like with the addition of Security Authority.
The Access Manager allows you to grant access based on person, device, or channel. For our purposes, we are performing grants at the user level . The main difference here, in comparison to three-legged OAuth, is that the SA is invoked by Github.
Focusing on ‘HubBub,’ and in particular the HubBub server’s security authority, you can access the code for this solution here.
Before we go any further, there are a few steps you will need to take to get your environment up and running:
GitHub allows you to register your application to use GitHub as an Identity Provider. The application name is any name you like. The other two values are much more significant and must match the values you send to github during the authentication process. These two values are:
Log into GitHub and select your profile dropdown in the top right corner of the screen. From there, select OAuth applications in the left panel. Then select “Developer Applications” and fill out the app registration form. The Homepage URL and Authorization URL’s will be the same for HubBub.
As you can see, it is possible to leverage any standards-based OAuth 2.0 Identity platform to secure access to your real-time solution. As we outlined in this tutorial, with the HubBub server acting as a Security Authority and the integration point with GitHub, this could have easily been implemented to use other Identity Platforms like Facebook or Google+. All you need is a standards based OAuth 2.0 identity platform that supports three-legged web server flow.
There are common underlying technologies for a dating app, and in this post, we’ll talk about the major technologies and designs...
Michael Carroll
How to use geohashing, JavaScript, Google Maps API, and BART API to build a real-time public transit schedule app.
Michael Carroll
How to track and stream real-time vehicle location on a live-updating map using EON, JavaScript, and the Mapbox API.
Michael Carroll