Introduction to OAuth Basic

OAuth allows you to share your private resources (photos, videos, contact list, bank accounts) stored on one site with another site without having to hand out your username and password. Giving your user name or password to a social media site is like giving them the rights to access your account.

Common Terms

These are some of the common terms that we should know when dealing with OAuth:

Service Provider – the Service Provider controls all aspects of the OAuth implementation. The Service Provider is the term used to describe the website or web-service where the restricted resources are located. It can be a photo sharing site where users keep albums, an online bank service, a microblogging site, or any other service where ‘user’s private stuff’ is kept. OAuth does not mandate that the Service Provider will also be the identity provider which means the Service Provider can use its own usernames and passwords to authenticate users, or use other systems such as OpenID.
User – the user is why OAuth exists and without users, there is no need for OAuth. The users have ‘stuff’ they don’t want to make public on the Service Provider, but they do want to share it with another site. In OAuth, the protocol stops without manual interaction with the user at least once to receive permission to grant access.
Consumer – this is a fancy name for an application trying to access the User’s resources. This can be a website, a desktop program, a mobile device, a set-top box, or anything else connected to the web. The Consumer is the one getting permission to access resources and the Consumer is where the useful part of OAuth happens. OAuth defines ‘Consumer Developer’ as the entity writing code to interact with the Service Provider. ‘Consumer Key’ and ‘Consumer Secret’ will be explained later.
Protected Resources: the ‘stuff’ OAuth protects and allow access to. This can be data (photos, documents, contacts), activities (posting blog item, transferring funds) or any URL with a need for access restrictions.
Tokens – are used instead of User credentials to access resources. A Token is generally a random string of letters and numbers (but not limited to) that is unique, hard to guess, and paired with a Secret to protect the Token from being abused. OAuth defines two different types of Tokens: Request and Access. This are explained later in greater details.

How Does OAuth Works ?

Let’s take a closer look on how OAuth works.

Consumer Registration

Consumer need to register themselves to the service provider. The service provider will create a ‘Consumer Key’ and a ‘Consumer Secret’ that consumer can use to request for access to the service provider.

User granting access to the consumer

Let just say for example, that you are on a consumer site, and you would like the consumer to retrieve your data from your service provider. The consumer will create an OAuth and redirects you to your service provider site. You need to login to your service provider site ands grant read (or perhaps write) access to your protected resources.
Your service provider will give an ‘Access Token’ to the consumer. Consumer uses this ‘Access Token’ to access your protected resources.

Who’s Behind OAuth ?

OAuth was started by Blaine Cook. He is the former lead developer in Twitter. He worked together with Chris Messina,David Recordon, Larry Halff to develop OAuth.

OAuth API

There are quite a number of API for OAuth. My personal favourite is signpost by Matthias Kappler. It is a light weight API that we can use together with Apache HTTP Client to create OAuth.