Journal of Engineering, Computers & Applied Sciences (JEC&AS)                       ISSN No: 2319‐5606      

Volume 2, No.6, June 2013                                                                                                                                 
_________________________________________________________________________________
 
A Survey Paper on Social Sign-On Protocol OAuth 2.0
Er. Gurleen Kaur, Research Scholar, BBSBEC Fatehgarh Sahib(Punjab)
Er. Deepak Aggarwal, Professor, BBSBEC, Fatehgarh Sahib (Punjab)
ABSTRACT
This paper presents the amalgamation of different social sites and the concept of social sign-on. Latest Trends of
using Facebook Platform, Google Friend Connect, Twitter etc have elevated the concept of social sign-on. These
social-networks connect services increase access to and enrich user data in the Social Web, although they also
present several security and privacy challenges. It enables a third-party application to obtain limited access to an
HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource
owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. In this
paper, we have presented the basic concept of the social sign-on protocol OAuth 2.0 and few challenges faced by
this protocol.
Keywords: Social sign-on, OAuth 2.0, third party, Resource server, token

Introduction 3. Third-party applications gain overly broad access to

Social-networking websites let users build social the resource owner's protected resources, leaving
connections with family, friends, and coworkers. resource owners without any ability to restrict
Users can also build profiles for storing and sharing duration or access to a limited subset of resources.
various types of content with others, including 4. Resource owners cannot revoke access to an
photos, videos, and messages. Updating user profiles individual third-party without revoking access to all
with interesting content is a form of self-expression third-parties, and must do so by changing their
that increases interaction in such sites. To encourage password. Compromise of any third-party application
this interaction and provide richer content, social- results in compromise of the end user's password and
networking sites expose their networks to Web all of the data protected by that password.
services in the form of online application
programming interfaces. These APIs allow third- OAuth 2.0 (Open Authentication) Protocol addresses
party developers to interface with the social- these issues by introducing an authorization layer and
networking site, access information and media posted separating the role of the client from that of the
with user profiles, and build social applications that resource owner. In OAuth, the client requests access
aggregate, process, and create content based on users’ to resources controlled by the resource owner and
interests. OAuth 2.0 is one such application that helps hosted by the resource server, and is issued a
to overcome the issues of traditional client-server different set of credentials than those of the resource
authentication model. owner. Instead of using the resource owner's
credentials to access protected resources, the client
Working Of OAUTH 2.0 obtains an access token - a string denoting a specific
In the traditional client-server authentication model, scope, lifetime, and other access attributes. Access
the client requests an access restricted resource tokens are issued to third-party clients by an
(protected resource) on the server by authenticating authorization server with the approval of the resource
with the server using the resource owner's owner. The client uses the access token to access the
credentials. In order to provide third-party protected resources hosted by the resource server.
applications access to restricted resources, the
resource owner shares its credentials with the third- For example, an end-user (resource owner) can grant
party. a printing service (client) access to her protected
This creates several problems and limitations: photos stored at a photo sharing service (resource
1. Third-party applications are required to store the server), without sharing her username and password
resource owner's credentials for future use, typically with the printing service. Instead, she authenticates
a password in clear-text. directly with a server trusted by the photo sharing
2. Servers are required to support password service (authorization server) which issues the
authentication, despite the security weaknesses printing service delegation-specific credentials
inherent in passwords. (access token).

www.borjournals.com                                                           Blue Ocean Research Journals          93 
 
Journal of En
ngineering, C
Computers & Applied Scien nces (JEC&ASS)                       ISSN No: 23 319‐5606      
Volume 2, N 13                                                                                                                                 
No.6, June 201  
___________ ___________ ___________ ____________ ___________________________________________
 
1. Roles in OAuth 2..0 rrequest authoriization and thee types supporrted by
OAuth deffines four roles: tthe authorizatioon server.
3. TThe client rrequests an access tokeen by
1. Resou urce owner aauthenticating with the authhorization server and
An entity capable of graanting access to a protected d ppresenting the authorization ggrant.
resource. When
W the resource owner is a person, it iss 4. TThe authorizattion server autthenticates the client
referred to as an end-userr. aand validates tthe authorizatioon grant, and if valid
iissues an accesss token.
2. Resou urce server 5. TThe client reqquests the prottected resourcee from
The serverr hosting the prrotected resources, capable off tthe resource server andd authenticatees by
accepting and respond ding to proteected resourcee ppresenting the access token.
requests ussing access tok
kens. 6. TThe resource server validatees the access token,
aand if valid, seerves the request.
3. Clientt
An applicaation making prrotected resourrce requests on
n 3. Authorizatioon Grant
behalf off the resourrce owner and a with itss An aauthorization grrant is a credenntial representiing the
authorizatiion. resouurce owner's auuthorization (too access its prootected
resouurces) used byy the client tto obtain an access
4. Autho orization serveer tokenn.
The serverr issuing access tokens to thet client afterr
successfullly authenticatiing the resourrce owner andd Therre are four graant types:
obtaining authorization.
a 1. AAuthorization code,
2. IImplicit,
2. Proto
ocol Flow 3. RResource owneer password crredentials, and
4. CClient credentiials.

Auth horization Cod de

The authorization code is obttained by usinng an
authoorization serveer as an interm mediary between the
cliennt and resourcce owner. Insstead of requuesting
authoorization direcctly from the resource owneer, the
cliennt directs the reesource ownerr to an authoriization
serveer , which in tuurn directs the rresource owneer back
to thhe client withh the authorizzation code. B Before
direccting the resouurce owner bacck to the cliennt with
the authorization code, the aauthorization server
autheenticates the resource ow wner and oobtains
authoorization. Beccause the ressource ownerr only
Fig .1 Abstraact Protocol Flo
ow autheenticates withh the authorization serverr, the
resouurce owner's crredentials are nnever shared w
with the
The abstraact flow illustrrated in Fig. 1 describes thee cliennt.
interaction
n between the four roles and d includes thee
following steps:
s Impllicit
1. The client requestts authorization from thee The implicit grant is a simplifiedd authorizationn code
resourrce owner. Thee authorization request can bee flow optimized forr clients implemmented in a brrowser
made directly to thee resource own ner (as shown),, usingg a scripting laanguage such aas JavaScript. In the
or preeferably indirectly via the authorization n impliicit flow, insstead of issuuing the clieent an
serverr as an intermeddiary. authoorization codee, the client iis issued an access
2. The cllient receives an a authorizatioon grant whichh tokenn directly (as the result of the resource owner
is a crredential representing the ressource owner'ss authoorization). Thhe grant type is implicit as no
authorrization, expressed using onee of four grantt mediate credeentials (such as an authoriization
interm
types defined in this specification or using an n code)) are issued (aand later used to obtain an access
extenssion grant typ pe. The autho orization grantt tokenn).
type depends
d on the method used by
b the client to
o

rjournals.com
www.borj m                                                           Blue  Ocean Resea
arch Journals          94 
 
Journal of Engineering, Computers & Applied Sciences (JEC&AS)                       ISSN No: 2319‐5606      
Volume 2, No.6, June 2013                                                                                                                                 
_________________________________________________________________________________
 
Resource Owner Password Credentials tokens with identical or narrower scope (access
The resource owner password credentials (i.e. tokens may have a shorter lifetime and fewer
username and password) can be used directly as an permissions than authorized by the resource owner).
authorization grant to obtain an access token. The Issuing a refresh token is optional at the discretion of
credentials should only be used when there is a high the authorization server. If the authorization server
degree of trust between the resource owner and the issues a refresh token, it is included when issuing an
client (e.g. the client is part of the device operating access token (i.e. step (D) in Fig. 1). A refresh token
system or a highly privileged application), and when is a string representing the authorization granted to
other authorization grant types are not available (such the client by the resource owner. The string is usually
as an authorization code). opaque to the client. The token denotes an identifier
used to retrieve the authorization information. Unlike
Client Credentials access tokens, refresh tokens are intended for use
The client credentials (or other forms of client only with authorization servers and are never sent to
authentication) can be used as an authorization grant resource servers.
when the authorization scope is limited to the
protected resources under the control of the client, or Challenges Faced By Protocol
to protected resources previously arranged with the However, with the emergence of new OAuth
authorization server. Client credentials are used as an Protocol 2.0, simplicity and performance increased,
authorization grant typically when the client is acting but also many limitations of OAuth 2.0 came into
on its own behalf (the client is also the resource existence:
owner), or is requesting access to protected resources
based on an authorization previously arranged with 1. CSRF Attack
the authorization server. OAuth 2.0 is prone to CSRF (cross-site request
forgery) attack. It’s also known as session riding or
4. Access Token XSRF.
Access tokens are credentials used to access
protected resources. An access token is a string 2. Unbounded tokens
representing an authorization issued to the client. The In 1.0, the client has to present two sets of credentials
string is usually opaque to the client. Tokens on each protected resource request, the token
represent specific scopes and durations of access, credentials and the client credentials. In 2.0, the client
granted by the resource owner, and enforced by the credentials are no longer used. This means that
resource server and authorization server. The token tokens are no longer bound to any particular client
may denote an identifier used to retrieve the type or instance.
authorization information, or self contain the
authorization information in a verifiable manner (i.e. 3. Bearer tokens
a token string consisting of some data and a 2.0 got rid of all signatures and cryptography at the
signature). The access token provides an abstraction protocol level. Instead it relies solely on TLS
layer, replacing different authorization constructs (Transport Layer Security).
(e.g. username and password) with a single token
understood by the resource server. This abstraction 4. Expiring tokens
enables issuing access tokens more restrictive than 2.0 tokens can expire and must be refreshed. This is
the authorization grant used to obtain them, as well as the most significant change for client developers
removing the resource server's need to understand a from 1.0 as they now need to implement token state
wide range of authentication methods. Access tokens management. The reason for token expiration is to
can have different formats, structures, and methods of accommodate self-encoded tokens – encrypted tokens
utilization (e.g. cryptographic properties) based on which can be authenticated by the server without a
the resource server security requirements. database look-up. Because such tokens are self-
encoded, they cannot be revoked and therefore must
5. Refresh Token be short-lived to reduce their exposure. Whatever is
Refresh tokens are credentials used to obtain access gained from the removal of the signature is lost twice
tokens. Refresh tokens are issued to the client by the in the introduction of the token state management
authorization server and are used to obtain a new requirement.
access token when the current access token becomes
invalid or expires, or to obtain additional access

www.borjournals.com                                                           Blue Ocean Research Journals          95 
 
Journal of Engineering, Computers & Applied Sciences (JEC&AS)                       ISSN No: 2319‐5606      
Volume 2, No.6, June 2013                                                                                                                                 
_________________________________________________________________________________
 
5. Grant types [9] Eran Hammer, " OAuth 2.0 and the Road to
In 2.0, authorization grants are exchanged for access Hell", http://hueniverse.com/2012/07/oauth-
tokens. Grant is an abstract concept representing the 2-0-and-the-road-to-hell/ , July 26, 2012
end-user approval. It can be a code received after the [10] Jeremiah Blatz, "CSRF: Attack and
user clicks ‘Approve’ on an access request, or the Defense",
user’s actual username and password. The original http://www.mcafee.com/us/resources/white-
idea behind grants was to enable multiple flows. 1.0 papers/wp-csrf-attack-defense.pdf
provides a single flow which aims to accommodate
multiple client types. 2.0 adds significant amount of
specialization for different client type.

Conclusion
OAuth 2.0 presents an exalted concept of social sign-
on by providing more security than traditional
concepts. But, it can be more secure if all the
confrontation faced by this protocol are met. Issues
like CSRF attack should be construed for developing
an enhanced protocol.

References
[1] San-Tsai Sun , “Simple But Not Secure: An
Empirical Security Analysis of OAuth 2.0-
Based Single Sign-On Systems” ,
http://blogs.ubc.ca/computersecurity/files/20
12/04/San-Tsai.pdf
[2] Barry Leiba, " OAuth Web Authorization  
Protocol ", www.computer.org/internet  
computing, Vol. 16, No. 1.  
January/February, 2012  
[3] Bhagyaraj Gowrigolla, Sathyalakshmi sivaji,  
" Design and auditing of Cloud computing
security", Information and Automation for
Sustainability (ICIAFs), 2010 5th
International Conference, Dec. 2010, pp.
292 - 297
[4] Chetan Bansal, Karthikeyan Bhargavan,
Sergio Maffeis, "Discovering concrete
attacks on website authorization by formal
analysis",
http://www.doc.ic.ac.uk/~maffeis/csf12.pdf
[5] M. Noureddine, " A provisioning model
towards OAuth 2.0 performance
optimization", Cybernetic Intelligent
Systems (CIS), 2011 IEEE 10th
International ConferenceSept. 2011, pp. 76-
80
[6] D. Hardt, http://tools.ietf.org/html/draft-ietf-
oauth-v2
[7] OAuth Community site, http://oauth.net
[8] Eran Hammer, "Introduction to OAuth 2.0",
http://hueniverse.com/2010/05/introducing-
oauth-2-0/ , May 15, 2010

www.borjournals.com                                                           Blue Ocean Research Journals          96