Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Current Events
Join our developers event to win one of the valuable prizes!
posted 2 years ago
viewed 25297 times
Share this article

Dancing with OAuth: Understanding how Authorization Works

Lately, most Internet services are developed like Software as a Service (SaaS). This means that users can communicate with a variety of services and use their resources. One of the reasons for Facebook and Twitter being so widespread is that one can use the functionality and data of the other, thus boosting the usage of both services.

However, in order to use the functions of Facebook or Twitter through external services, one does not necessarily need to log in to neither of them. Just a simple authentication process, like OAuth, allows users to leverage the data from popular social networking services. This helps to build an ecosystem that is good for all the users as well as many Internet service providers.

In this article I will explain what OAuth is, how it came to life, which entities rely on it, and how one can use it in their own applications. I will also explain the difference between OAuth and no less popular Open ID.

Birth and Usage of OAuth

OAuth is an open standard protocol for authentication that allows a user to use Internet service functions, such as those provided by Facebook or Twitter, within other applications (desktop, web, mobile, etc.).

According to its official site:

OAuth is an authorization framework that enables a third-party application to obtain a limited access to an HTTP service.

Before OAuth was created, there were other authentication methods that helped to protect the ID and password of users from other applications while enabling API Access Delegation. Google, Yahoo!, AOL and Amazon have each created and used their own authentication methods.

OAuth 1.0 was released in 2007 and OAuth 1.0 revision A, a revised version for better security, was released in 2008.

OAuth was started when developers from Twitter and Gnolia, which was the social bookmarking service provider, met in 2006 and discussed how to authenticate Internet services. They knew there was no standard for API Access Delegation at that time. They founded an OAuth committee on the Internet in April 2007 and prepared and shared a draft of OAuth proposal. After that day, some people supported this activity. During the 73rd meeting of Internet Engineering Task Force (IETF) held in Minnesota in 2008, a discussion was held to determine whether the OAuth should be managed as an IETF standard. In 2010, the OAuth 1.0 protocol standard was released as RFC5849.

As of now, there is OAuth 2.0 created by the IETF OAuth working group, though it is still in the draft stage. OAuth 2.0 is incompatible with OAuth 1.0, however, its authentication process is very simple. Because of the simple process, a variety of Internet services opted to use one of the latest drafts of OAuth 2.0. The following table summarizes the versions of OAuth used by popular Internet service companies.

Table 1. Versions of OAuth Used by Internet Service Companies1.

Internet Service Companies OAuth Version
Facebook 2.0 draft 12
Foursquare 2.0
Google 2.0
Microsoft (Hotmail, Messenger, Xbox) 2.0
LinkedIn 2.0
Daum (Tistory) 2.0
NHN (Open API) 1.0a
Daum (Yozm, Open API) 1.0a
MySpace 1.0a
Dropbox 1.0
Twitter 1.0a
Vimeo 1.0a
Yahoo! 1.0a

OAuth and Login

OAuth and login must be separately understood. I will given a real life example to explain the difference between them.

Assume we have a company where employees gain access to its building using their employee ID card. Now assume that an external guest needs to visit the company. If login stands for an employee accessing the building, OAuth stands for a guest receiving a visitor card and accessing the building. See the following example.

  • An external Guest A says to the reception desk that he wants to meet Employee B for business purposes.
  • The reception desk notifies Employee B that Guest A has come to visit him.
  • Employee B comes to the reception desk and identifies Guest A.
  • Employee B records the business purpose and identity of Guest A at the reception desk.
  • The reception desk issues a visitor card to Guest A.
  • Employee B and Guest A go to the specified room to discuss their business.

I gave this example to help you understand the procedure of issuing OAuth and the authorization. The visitor card allows visitors to access pre-determined places only which means that a person with a "visitor card" cannot access all the places that a person with an "employee ID card" can access. In that way, a user who has directly logged into the service can do more than a user who has been authorized by OAuth.

In OAuth, "Auth" means "Authorization" as well as "Authentication". Therefore, when authentication by OAuth is performed, the service provider (reception desk) asks whether a user (employee) wants to authorize the request of the third-party application (guest). The following figure shows how Twitter asks if you would like to grant access to a third-party application.

tiwtter_oauth.png

Figure 1. OAuth Access Right Request to Twitter.

OpenID vs. OAuth

OpenID is a standard protocol for authentication which also uses HTTP just like OAuth. However, the purpose of OpenID is different from that of OAuth.

The main purpose of OpenID is authentication, while for OAuth it is authorization. Therefore, using OpenID is fundamentally identical to log-in. For OpenID, the OpenID Provider processes the user authentication process. Many parties who rely on Open ID delegate the authentication to the OpenID Provider.

In addition to authorization, OAuth also has its authentication process. For example, when Facebook OAuth is used, Facebook Service Provider authenticates the Facebook user. However, the essential purpose of OAuth is to identify whether the user has the right to call the API to write on the user's wall or the API to get the friends list.

You can use OAuth for user authentication; however, note that its fundamental purpose is to authorize users. This is different from what OpenID aims to achieve.

OAuth Dance, OAuth 1.0 Authentication Process

OAuth Dance is an authentication process that identifies users using OAuth. It is named to illustrate the process of two people sending and receiving information correctly as if they were dancing.

Understanding OAuth requires getting to know OAuth terminology in advance. The following table summarizes the key OAuth terminology.

Table 2. Key OAuth 1.0 Terminology.

Terminology Description
User A user who has an account of the Service Provider and tries to use the Consumer. (An employee in our example.)
Service Provider Service that provides Open API that uses OAuth. (The reception desk in our example.)
Consumer An application or web service that wants to use functions of the Service Provider through OAuth authentication. (A guest)
Request Token A value that a Consumer uses to be authorized by the Service Provider After completing authorization, it is exchanged for an Access Token. (The identity of the guest.)
Access Token A value that contains a key for the Consumer to access the resource of the Service Provider. (A visitor card.)

The following figure shows the OAuth authentication process.

oauth_10a_authentication_process.png

Figure 3. OAuth 1.0a Authentication Process.

The following table shows the OAuth authentication process by comparing to the company visit process described before.

Table 3. Company Visit Process and OAuth Authentication Process.

Company Visit Process OAuth Authentication Process
1. Guest A (an external guest) says to the reception desk that he wants to meet Employee B (an employee) for a business purpose. Requesting for and issuing Request Token
2. The reception desk notifies Employee B that Guest A has come to visit him. Calling user authentication page
3. Employee B comes to the reception desk and identifies Guest A. User login completed
4. Employee B records the business purpose and identity of Guest A at the reception desk. Requesting for user authority and accepting the request
5. The reception desk issues a visitor card for Guest A. Issuing Access Token
6. Employee B and Guest A go to the specified room for the business. Requesting service information by using Access Token

From this table you can understand the Access Token as a visitor card. With the visitor card, a visitor can access the permitted space. Likewise, a Consumer with an Access Token can call the available Open API of the Service Provider.

Request Token

In OAuth, the process in which a Consumer sends a request by issuing a Request Token, then the Service Provider issues Request Token corresponds to the procedure saying "I am Guest A. Can I meet Employee B?".

See the following code used to request the Request Token. This is an example of requesting the Request Token from NAVER OAuth API.

GET /naver.oauth?mode=req_req_token&oauth_callback=http://example.com/OAuthRequestToken.do&oauth_consumer_key=WEhGuJZWUasHg&oauth_nonce=zSs4RFI7lakpADpSsv&oauth_signature=wz9+ZO5OLUnTors7HlyaKat1Mo0=&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1330442419&oauth_version=1.0 HTTP/1.1
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: nid.naver.com

For easy reading, the above text has been arranged based on the parameter as shown below.

GET http://nid.naver.com/naver.oauth?mode=req_req_token&
oauth_callback=http://example.com/OAuthRequestToken.do&
oauth_consumer_key=WEhGuJZWUasHg&
oauth_nonce=zSs4RFI7lakpADpSsv&
oauth_signature=wz9+ZO5OLUnTors7HlyaKat1Mo0=&
oauth_signature_method=HMAC-SHA1&
oauth_timestamp=1330442419&
oauth_version=1.0 HTTP/1.1

The following table shows the parameters used to request the Request Token.

Table 4. Parameters Used to Request the Issuing of Request Token.

Parameter Description
oauth_callback Web address of a Consumer that will be redirected after the Service Provider completes authentication. If the Consumer is not a web application and has no address to redirect, the lower-case Out Of Band ("oob") is used as the value.
oauth_consumer_key A key value used by the Service Provider to distinguish the Consumer.
oauth_nonce A certain string created temporarily by the Consumer. The oauth_timestamp value should be unique for a repeat request. This is to prevent malicious repetition of requests.
oauth_signature A signature value that encrypts and encodes the OAuth authentication information. The OAuth authentication information is a concatenated string value of other parameters except oauth_signature itself and the HTTP request method. The encryption method is defined in oauth_signature_method.
oauth_signature_method A method to encrypt oauth_signature. HMAC-SHA1 and HMAC-MD5 are available.
oauth_timestamp A timestamp when the request was generated. It is the accumulated time in seconds counted from 00:00:00 on January 1, 1970.
oauth_version OAuth version. 1.0a is described as 1.0.

Generating oauth_signature

In OAuth 1.0, the most difficult stage is to generate oauth_signature. The Consumer and the Service Provider must definitely use the identical signing algorithm to generate oauth_signature. oauth_sinature is generated through the following four stages.

  1. Collect all request parameters
    All parameters related to OAuth which start with oauth_ except for oauth_signature should be collected. If parameters are used in the POST body, they also should be collected.
  2. Normalize the parameters
    Sort all parameters in alphabetical order and apply URL encoding (rfc3986) to each key and value. List the results of URL encoding as <key>=<value> format and insert "&" between each pair. Apply URL encoding to the entire result again.
  3. Create a Signature Base String
    Combine the HTTP method name (GET or POST), the HTTP URL address called by the Consumer (except for parameters), and the normalized parameter by using "&". The combination becomes "[GET|POST] + & + [URL string except for parameters] + & + [Normalized Parameter]". In this example, "http://nid.naver.com/naver.oauth" is used as a URL, and URL encoding is applied to the URL to get the value.
  4. Generating a Key
    Encrypt the string generated at stage 3 using the Consumer Secret Key. This Consumer Secret Key is obtained when the Consumer has registered in Service Provider. Using the encryption method such as HMAC-SHA1, generate the final oauth_signature.

Calling User Authentication Page

The stage of calling the user authentication page in OAuth corresponds to "The reception desk notifies Employee B that Guest A has come to visit him and requests identification". When a Request Token is requested, the Service Provider sends oauth_token and oauth_token_secret to be used as a Request Token to the Consumer. When requesting Access Token, oauth_token_secret is used. Access Token is received as a response to the request for the Request Token. If the Consumer is a web application, oauth_token_secret should be saved in the HTTP session, cookies or the DBMS.

Then display the user authentication page specified by the Service Provider to the User by using oauth_token. For NAVER, the address of the user authentication page for OAuth is:

https://nid.naver.com/naver.oauth?mode=auth_req_token

As a parameter, pass the oauth_token which has been returned as a response to the request for the Request Token to the address. For example, the following URL is created. This URL directs to the user authentication page.

https://nid.naver.com/naver.oauth?mode=auth_req_token&oauth_token=wpsCb0Mcpf9dDDC2

The stage until calling the login page is the stage that corresponds to "the reception desk calls Employee B". Now Employee B should come to the reception desk and identify Guest A. The process to identify whether it is Guest A or not will be necessary. This process in OAuth is when the Service Provider authenticates the User.

After completing the authentication, some authorization is requested as mentioned before, such as, "Guest A has come for a business meeting. Please issue a visitor card to him."

After completing authentication, the Consumer redirects to the URL specified in oauth_callback. At this time, the Service Provider passes new oauth_token and oauth_verifier to the Consumer. These values are used to request the Access Token.

Requesting the Access Token

In OAuth, Access Token is like a visitor card to be issued to Guest A.

Requesting for an Access Token is similar to requesting a Request Token. However, the types of parameters and keys used to generate oauth_signature are different. When requesting the Access Token, oauth_token and oauth_verifer are used, which were issues in the previous step when authentication was performed. Here there is no need for a oauth_callback parameter.

When requesting a Request Token, we have used Consumer Secret Key to generate oauth_token_secret. When requesting an Access Token, we need to generate oauth_token_secret using the value obtained by combining the Consumer Secret Key to oauth_token_secret (Consumer Secret Key + & + oauth_token_secret). This is to change the encryption key to strengthen security.

The following table shows the parameters used to request an Access Token.

Table 5. OAuth Parameters to Request Issuing of Access Token.

ParameterDescription
oauth_consumer_key The key value used by the Service Provider to distinguish the Consumer.
oauth_nonce A certain string created temporarily by the Consumer. The oauth_timestamp value should be unique for a repeat request. This is to prevent malicious repetition of requests.
oauth_signature A signature value that encrypts and encodes the OAuth authentication information. The OAuth authentication information is a concatenated string value of other parameters except oauth_signature itself and the HTTP request method. The encryption method is defined in oauth_signature_method.
oauth_signature_method A method to encrypt oauth_signature. HMAC-SHA1 and HMAC-MD5 are available.
oauth_timestamp A timestamp when the request was generated. It is the accumulated time in seconds counted from 00:00:00 on January 1, 1970.
oauth_version OAuth version.
oauth_verifier The oauth_verifier value passed through oauth_callback when requesting the Request Token.
oauth_token The oauth_token value passed through oauth_callback when requesting the Request Token.

After defining the parameters in the above table, request an Access Token. Then oauth_token and oauth_token_secret are returned. Depending on the Service Provider the user ID or profile may be returned.

Using the Access Token

Finally, we have the visitor card issued. Now you can enter the building. Entering the building with the visitor card is similar to using the Service Provider functions with the user authority. In other words, a user can call the Open API which requests the authority.

For example, to get a list of blogs from a NAVER cafe, the following URL should be called.

http://openapi.naver.com/cafe/getMenuList.xml

To get a list of blogs from NAVER cafes which the user has been subscribed to, the user should request the URL that returns the list of boards from NAVER cafes with a specific user authority. To call the URL, the OAuth parameter should be passed, too.

The following is an example of requesting the Open API using the Access Token. The Authorization field is included in the HTTP header. Write the OAuth parameter in the value of the Authorization field. To use the Access Token, the HEAD method is used, not the GET or POST method.

POST /cafe/getMenuList.xml HTTP/1.1
Authorization: OAuth oauth_consumer_key="dpf43f3p2l4k3l03",oauth_token="nSDFh734d00sl2jdk"
,oauth_signature_method="HMACSHA1",oauth_timestamp="1379123202",oauth_nonce="chapoH",oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D"
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: http://openapi.naver.com

For easy reading, the above Authorization field has been arranged and it is based on the parameter as shown below.

Authorization: OAuth oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_token="nSDFh734d00sl2jdk",
oauth_signature_method="HMACSHA1",
oauth_timestamp="1379123202",
oauth_nonce="csrrkjsd0OUhja",
oauth_signature="MdpQcU8iPGGhytrSoN%2FUDMsK2sui9I%3D"

The following table shows parameters used to call Open APIs using the Access Token.

Table 6. OAuth Parameters Required to Call Open APIs using the Access Token.

ParameterDescription
oauth_consumer_key A key value used by the Service Provider to distinguish the Consumer.
oauth_nonce A certain string created temporarily by the Consumer. The oauth_timestamp value should be unique for a repeat request. This is to prevent malicious repetition of requests.
oauth_signature A signature value that encrypts and encodes the OAuth authentication information. The OAuth authentication information is a concatenated string value of other parameters except oauth_signature itself and the HTTP request method. The encryption method is defined in oauth_signature_method.
oauth_signature_method A method to encrypt oauth_signature. HMAC-SHA1 and HMAC-MD5 are available.
oauth_timestamp A timestamp when the request was generated. It is the accumulated time in seconds counted from 00:00:00 on January 1, 1970.
oauth_version OAuth version
oauth_token oauth_token passed through oauth_callback.

Caution
When a request is made using Access Token, some Service Providers request the parameter realm. The realm is an optional parameter used by WWW-Authenticate HTTP header field.

OAuth 2.0

It is difficult to use OAuth 1.0 for an application that is not the web application. In addition, the procedure is too complicated to produce the OAuth implementation library, and the complicated procedure causes an operational burden upon the Service Provider.

OAuth 2.0 improves these weak points. It is not compatible with OAuth 1.0 and still has no final draft. However, many Internet services companies have already adopted OAuth 2.0. The following are the main features of OAuth 2.0:

  • Enhanced support for applications, not for web applications
  • Does not need encryption
    Uses HTTPS, not HMAC
  • Simplified signature
    Does not need sorting and URL encoding
  • Access Token update
    When Access Token was issued in OAuth 1.0, the Access Token was valid continuously. For Twitter, Access Token does not expire. For higher security, OAuth 2.0 allows to specify the life-time of the Access Token.

The terminology used by OAuth 2.0 is totally different from that of OAuth 1.0. It will be better to understand that the two protocols have the same purpose but they are totally different. However, the final draft has not yet been made; therefore, just understand the characteristics of OAuth 2.0.

Even though 2.0 is an improved version of OAuth and it is becoming one of the key elements in the current Internet ecosystem, the former lead author and editor of the OAuth specifications doesn't think so. I recommend you to familiarize yourself with his explanations and recommendations about what version of OAuth it is good to stick with.

Nevertheless, newcomers in the industry use the authentication service from Facebook or Twitter rather than implementing their unique authentication method, because it can reduce development and operational costs. In addition, this helps to promote users' services through Facebook or Twitter. From the Service Provider side, the core function can be popularized more.

Imagine... just one standard authentication technology... and it is changing the entire Internet industry.

By Changhun Oh, Senior Developer at Social Apps Service Team, NHN Corporation.

About the author:
In 2000, I started programming as a webmaster and it became my vocation... and it will be for the rest of my life. It makes me happy! I want to know everything about development so I read the Hello World (NHN Developers blog). I like creating something. My hobbies are DIY, plastic figure model kits, and camping. I had worked as a technical leader to introduce new technology to the front and optimize the services. Now, I work as an evangelist for open social platform at NHN.



comments powered by Disqus