Reading time: 10 minutes

In the previous article, I discussed some common types of user authentication techniques used in web and mobile application development. Nevertheless, this article serves as a sequel to the previous one, and we'd be looking at the OAuth 1.0 open-standard authorization protocol.

What is OAuth?

OAuth is an open-standard authorization protocol or framework that allows third-party applications (and websites) have access to a user's information on a website or application without (the user) sharing their password. OAuth provides client applications a "secure designated access" to web resources over Hypertext Transfer Protocol (HTTP). For instance, let's assume the user has an active Twitter account; a third-party application or website can be granted access to post or upload information on the user's Twitter timeline without having access to the user's password - hence, ensuring a "safe" access and security of the user's password.

History

OAuth (Open Authentication) is said to have begun in November 2006 when the Twitter software engineer Blaine Cook, was developing the OpenID implementation for Twitter. Cook, alongside other Twitter developers met with Ma.gnolia (now Gnolia) developers to discuss using OpenID with Twitter and Magnolia APIs to delegate authentication. However, due to the inavailability of open standards for access delegation (at the time), they decided to form a discussion group.

The OAuth discussion group was formed in April 2007, for the drafting of the proposal for an open protocol. There was wide support concerning this decision from other technologists and founders, and in July 2007, the group drafted an initial specification. After much contributions, the OAuth Core 1.0 final draft was released on 4 December 2007.

In November 2008, during the 73rd meeting of the Internet Engineering Task Force (IETF) held in Minnesota, a discussion was held to decide if the OAuth protocol should be brought into the IETF for standardization. After much deliberation, and a wide support for the motion, a conclusion was reached. In April 2010, the OAuth 1.0 protocol was released as RFC 5849, and in June 2009, OAuth 1.0 Revision A (an improved version) was released due a security flaw in the OAuth 1.0 protocol.

In recent times, the OAuth 2.0 protocol (published in October 2012) has been used in favour of OAuth 1.0 (due to its deprecation) by most popular Service Providers. However, OAuth 2.0 remains incompatible with OAuth 1.0, but boasts of a more secure and simple authorization flow.

OAuth 1.0 Terminology

These are basic components that make up the OAuth 1.0 authorization flow:

• User - A person who has an account of the Service Provider and wants access using the Consumer
• Service Provider - A web application that provides an API that uses OAuth
• Consumer - A website or application that accesses the Protected Resource of the Service Provider via OAuth
• Protected Resource - Information the User wants to have access to
• Request Token - A value used by the Consumer to be authorized by the Service Provider. Usually comes with a Token Secret (a secret used by the Consumer to establish ownership of a given request token). It is exchanged with an Access Token after authorization
• Access Token - A value used by the Consumer to access Protected Resources of the Service Provider

We can further understand how the authorization process works using a simple analogy:

Imagine a scenario where residents of an estate can visit the estate's basketball courtyard using only a Residency Card (issued by the Estate Security Department). Assuming a resident's friend comes visiting and wants to have visit this courtyard, he would definitely face restrictions because he is not a resident, and does not have the Residency Card. In order to have access to the courtyard, he is expected to seek permission from the Estate's Security Department (i.e. confirming his relationship with the resident, and obtaining a form of identification card) - in this case, the Residency Card. This way, he has been authorized to visit the basketball courtyard using the Residency Card.

Although this is a weak analogy, but from the explanation we get to understand that the "resident" is the User, the resident's friend is the Consumer, the Estate's Security Department is the Service Provider, and the Residency Card is the Access Token.

How OAuth Works

The OAuth 1.0 implementation workflow has been highlighted in just four steps. In the example below, a Twitter user Sam wants to be able to post information on his timeline via a third-party application:

1. The third-party application (consumer) requests a token (request token) from Twitter (service provider) to access Sam’s Twitter timeline (protected resource).

2. Upon receival of request token from service provider, the consumer redirects the user Sam back to the service provider for authorization.

3. Once authorization is granted by the user, the user is redirected back to the consumer which requests that the request token be exchanged for an access token.

4. The service provider then grants the consumer an access token which is used to access the protected resource, inasmuch as the access token is valid.

With this article at OpenGenus, you must have a complete idea of OAuth 1.0. Enjoy.