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:
- The API Client asks the Twitter Server for authorization (either directly or indirectly via the Twitter Auth server) to access the desired resource.
- The Twitter Server gives the Client an authorization grant.
- The Client then presents the authorization grant to the Auth server, authenticates itself and gets an Access Token in return.
- 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.
- 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.