Introduction to OAuth

OAuth 2 is rapidly becoming a preferred authorization protocol, and is used by major service providers such as Google, Facebook and Github.

Valet Key for the Web

Many luxury cars come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will only allow the car to be driven a short distance while blocking access to the trunk and the onboard cell phone.

Regardless of the restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else.

As the web grows, more and more sites rely on distributed services and cloud computing:

• a photo lab printing your Flickr photos,
• a social network using your Google address book to look for friends, or
• a third-party application utilizing APIs from multiple services.

The problem is, in order for these applications to access user data on other sites, they ask for usernames and passwords. Not only does this require exposing user passwords to someone else – often the same passwords used for online banking and other sites – it also provides these application unlimited access to do as they wish. They can do anything, including changing the passwords and lock users out.

OAuth provides a method for users (you) to grant third-party (parking attendant) access to their resources (your luxury car) without sharing their passwords (the key of your car). It also provides a way to grant limited access (in scope, duration, etc. the equivalent of not having access to the trunk or the onboard cell phone).

For example,

• a web user (resource owner) can grant a
• printing service (client)
• access to her private photos (partial resource)
• stored at a photo sharing service (server),
• without sharing her username and password with the printing service.

Instead, she authenticates directly with the photo sharing service which issues the printing service delegation-specific credentials.

In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.

Instead of using the resource owner's credentials to access protected resources, the client obtains an access token - a string denoting a specific scope, lifetime, and other access attributes.

Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner.

The client uses the access token to access the protected resources hosted by the resource server.

1. The OAuth 2.0 Authorization Framework proposed standard document

Roles in OAuth

OAuth defines four roles:

1. resource owner

   An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

2. resource server

   The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

3. client

   An application making protected resource requests on behalf of the resource owner and with its authorization.

   The term " client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

4. authorization server

   The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

The authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.

Véase

• Nacho Coloma: Our love-hate relationship with OAuth