The land of Shattered dreams

Welcome to the online revolution…

Adventures in OAuth2

| Comments

I’ve not been able to blog for a while as a lot of things have been going on. In November I left Morrisons to take a Solutions Architect role at Laterooms and it has taken me a while to get settled in and to work out what’s going on.

One of the things I am looking at for Laterooms is how we use APIs to power our platform. We’ve developed RESTful APIs that are used by our mobile applications but we can do a whole lot more with our APIs. Long term, I’d like to build our entire platform on APIs using them as the base for our mobile apps, the websites and our integration with affiliates and hotel providers. We’ve got a long way to go, but I guess a journey of a thousand miles begins with a single step.

One of the key considerations we have when designing our API platform is controlling who has access to our data. We want to build a platform capable of allowing authorized consumers unlimited access to Lateroom’s data. Note authorized consumers, some data is public and we want to make it as easy as possible to access it; some data is most definitely not public and access to it has to be limited.

To help us control access to our APIs I have been looking at various API management platform and how they implement OAuth2 to provide authorized access to an API. The three I talk about in this post are from Apigee, Mashery and Mulesoft.


Before we start I supose it is worth talking a bit about OAuth2. To quote wikipedia:

OAuth is an open standard for authorization. OAuth provides a method for clients to access server resources on behalf of a resource owner such as a different client or an end-user. It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials, typically a username and password pair, using user-agent redirections.

The OAuth2 spec is a long and complicated document with many, many options. To compare the three management platforms I built a simple API hosted on Heroku. I also wrote a simple client web app that consumed the API again hosted on Heroku. Finally I wired in each of the API management platforms to protect the API and to ensure only authenticated users could use the client.

I used the “Authorization Code” flow to authenticate and authorise the client users, which means that the client does not need any knowledge of the user’s credentials and all the authentication and authorization is done on the API side.

At a high level, every API request by the client requires an access token to call a protected resource. The steps to get an access token are:

  • the user authenticates themselves using a web application hosted on the API side
  • the client application is passed an authorization code via a callback method. The client exchanges this code for an access token, authenticating itself with a client ID and secret.
  • the client attaches the access token to any API calls

Each of the API management platform achieves this in a slightly different way.


To implement the flow in Mashery I wrote a simple node app that presented a user a screen to enter their username and password and which validated them. The user clicks on a link in the client app and is taken to this validation screen.

If the validation succeeds the web app uses a Mashery API to generate an authorization code and this is passed back to the client via it’s callback url. The client makes a call to a “token” endpoint configured in the Mashery API and which responds with an access token. This token is passed with every subsequent API call and the Mashery platform ensures that it is valid.

This is the implementation I tried last, and it took me very little effort to change the code a developed using Apigee to work with Mashery.


Apigee’s approach is slightly different to Mashery. I had to expose three endpoints in Apigee. The first endpoint redirects to the login application where the user enters their details. If the details are correct, the login app calls the second endpoint which generates an authorization code and passes it to the client app via its callback url. The client then uses the third endpoint to exchange the code for an access token.

It took me a while to remember how OAuth works, but once I had that the example from Apigee was easy to follow and I got things up and running pretty quickly.


Mulesoft is a relatively new player in the API management space, primarily being known for their ESB.The biggest difference between the the solution I built with this and the others was that Mulesoft provided the login application, with no ability to develop your own. It is relatively simple to plug this login app into an existing database, and you do have control over how it looks but it does mean you have to know about Spring and Java (both of which I do). Getting an access token was easy, and wiring in the API was pretty simple. I did like that you can run everything on a local machine whilst developing - but it also required the most technical knowledge to get working.


All three platforms made it simple to implement the required functionality. Mashery and Apigee’s approach are pretty similar (although the platforms are quite different), and Mulesoft’s approach also work’s well.