Solemn OAuth2

Considering all the recent reading I’ve been doing, I decided to tackle a new challenge and read a complete RFC for a change. A RFC (literally Request For Comments) is a document that proposes a new idea for the world to comment on and if it looks good, an organization such as the Internet Engineering Task Force, better known as the IETF, goes ahead and approves it for large scale use. Reading a RFC can be a lot of fun since some of the biggest ideas of today, such as TCP/IP, HTTP and REST started out as humble RFCs. For the same reason, I decided that my first RFC read would be about the ever-so-confusing OAuth2 protocol, described in RFC 6749.

In today’s mobile and web driven world, OAuth2 has been the mainstay that has allowed the whole world to share and access data securely. If it wasn’t for OAuth, things like Facebook login, Gmail and OneDrive would not have been possible. However, OAuth2 can be tricky to get right, not because it is a difficult protocol, but because a layman would be wrapped up more in the jargon than the actual workings. I hope to review OAuth2 and provide a simple working example for everyone to benefit from.

Let’s get some terminology out of the way. The RFC describes 4 entities. Let’s take a simple example of a Twitter (because of its ubiquity) API client to create analogies:

  • Resource Owner – This is you, the user, who stores your data (or resource) on the Twitter servers in the form of tweets, likes and other micro-blogging related data.
  • Resource Server – This is the server owned by Twitter that makes sure your data is securely and safely stored.
  • Client – This is the web or mobile app that we want to use to get access to the data from anywhere in the world. Let’s assume it is a mobile app for now.
  • Authorization Server – This is an independent server (again run by Twitter) whose job is to verify that you are the owner of the data or have been granted access by the owner to access the data. Let’s call this the Twitter Auth server.

Now that that’s out of the way, the basic flow of OAuth 2 is:

  1. The API Client asks the Twitter Server for authorization (either directly or indirectly via the Twitter Auth server) to access the desired resource.
  2. The Twitter Server gives the Client an authorization grant.
  3. The Client then presents the authorization grant to the Auth server, authenticates itself and gets an Access Token in return.
  4. The Client can now use the Access Token to gain access to the desired resource on the Twitter server and perform the function it was designed for.

There you have it! OAuth2 is that easy. The specific implementation/URLs vary, but the general flow is common.

However, we still haven’t talked about the Authorization Grant, why is it important and what that means for the kind of app you’re developing. So let’s quickly go through that:

  • Authorization Code – Here the client simply asks the resource server to redirect itself to the auth server in order to perform the authentication and authorization. Via a ‘redirect_url ‘ parameter, the auth server can send the resource owner back to the desired URL to continue the flow. This is the most common OAuth2 flow you will see.
  • Implicit – Rather than provide an authorization grant, the auth server directly provides the access token, thus greatly simplifying the flow. This is especially useful for websites using Javascript where Javascript can directly access the resource. Note that authentication is not performed since the access token is already provided.
  • Resource Owner Password Credential – This involves directly sending your username and password to the resource server as the authorization grant, over the wire. This is risky and not recommended unless the resource server is highly secured and trusted by your client, which is almost never the case.
  • Client Credentials – Again uses the client’s credentials to authenticate and authorize but only for resources that the client controls or for resources that have been predetermined, and not necessarily all available resources. This flow is not very common so I wouldn’t worry too much about it.

Well that’s it for the salient stuff of the RFC. Of course you can delve deeper into it if you are comfortable with Computer Security terms, but I hope that after reading this post, you are more comfortable understanding how OAuth2 functions and how you can leverage it to power your app.


HTTP Libraries – Your Best Friends

For a programmer like me, the web is a playground like no other. Not just the information that can be retrieved, but the sheer amount of services and APIs available online make getting structured, useful data a matter of reading a few documentation pages. From social data like Facebook and Twitter to data services like Xbox Music, the web is a repository of rich information that can be manipulated as per your whim.

So while the data is omnipresent on the web, the bigger task is pulling that data from the stores they reside in. This is where the HTTP protocol comes in. With its basic operations like GET, POST, PUT and DELETE, you have a handy mechanism to retrieve, push or manipulate the data on the servers. Now, the HTTP protocol is not as simple a protocol as this blog post makes it seem. Things like HTTP Headers, application types, authentication tokens and other similar things make the task of HTTP based retrieval slightly more complex than it must have been intended to be.

This is where HTTP libraries come in. They handle the mostĀ of the heavy lifting and let you focus on the kind of content you are dealing with on a per API basis while abstracting away the inner complexities of packet and protocol rules. As someone who has been doing a lot of development in C# and Python, the HttpClient library in the .NET framework and Python’s Requests libraries have helped me unleash the raw power of the web countless times. To give you a glimpse of this power, you can take a look at how the HttpClient library handles various forms of HTTP content in this Stackoverflow answer.

The simplicity of Python’s requests library makes rapid prototyping with new web APIs a cinch. Simple methods like requests.get() and (which do exactly as the names suggest) let you examine in real time the data coming in. This knowledge can then be leveraged to build more robust languages either in Python or in enterprise level languages like C#. The HttpClient library brings amazing power in terms of its ability to not only do various kinds of HTTP requests, such as upload images programmatically, but also manipulate headers and metadata effectively, thus helping you quickly get off the ground with your application. Add to that C#’s asynchronous operation support and you’ll be developing .NET software full-time.

Now while I learn Ruby, I have already exposed myself to the Net::Http library of Ruby to take advantage of this newly discovered ability. I personally will definitely make it a point to master the HTTP libraries of whatever language I use along with the defining features of the language. Accordingly, especially if you are a new programmer, I urge you to do the same and reward yourself with this power and flexibility to leverage existing information to build upon, create cool things and make the world a whole better place!