Secure web service with Oauth

VIETNAM NATIONAL UNIVERSITY, HANOI
UNIVERSITY OF ENGINEERING AND TECHNOLOGY
======
STUDENT SCIENTIFIC RESEARCH CONTEST
Year: 2012
Research name: Secure web service with Oauth
Student name: Pham Cong Quang Gender: Male
Class: QH-2008-I/CQ-CA Faculty: Computer Science
Supervisor: Dr.Vo Dinh Hieu
2
TABLE OF CONTENT
I.SUMMARY 4
II.MOTIVATION 5
III.IMPLEMENTATION 6
2.1 WEB SERVICE

6
2.1.1 Denion 6
2.1.2 Characters and components of web service 7
2.1.2.1 Characters 7
2.1.2.2 Elements 8
A, SOAP 8
B. WSDL 10
C. XML 12
D. Web API 13
2.1.3 WS security 14
2.2 OPEN ID

15
2.3 OAUTH

16
INTRODUCTION

16
END-USER BENEFITS: 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. WHEN USE WEB
SERVICE, USERS PUT THEMSELVES AT RISK SHARING THE SAME PRIVATE INFORMATION. OAUTH IS THE RESCUE.

16
BOTH THE VALET KEY AND ATM CARDS ARE GOOD METAPHORS FOR OAUTH FROM A USER PERSPECTIVE. INSTEAD OF GIVING YOUR
ATM CARD AND PIN CODE, THE CARD CAN DOUBLE AS A CREDIT CARD WITH A SIGNATURE AUTHORIZATION. JUST LIKE YOUR
USERNAME AND PASSWORD PROVIDE FULL ACCESS TO YOUR RESOURCES, YOUR ATM CARD AND PIN CODE PROVIDE YOU WITH GREAT
CONTROL OVER YOUR BANK ACCOUNTS – MUCH MORE THAN JUST CHARGING GOODS. BUT WHEN YOU REPLACE THE PIN CODE WITH
YOUR SIGNATURE, THE CARD BECOMES VERY LIMITED AND CAN ONLY BE USED FOR LIMITED ACCESS.

16
USERS DON’T CARE ABOUT PROTOCOLS AND STANDARDS – THEY CARE ABOUT BETTER EXPERIENCE WITH ENHANCED PRIVACY AND
SECURITY. THIS IS EXACTLY WHAT OAUTH SETS TO ACHIEVE. WITH WEB SERVICES ON THE RISE, PEOPLE EXPECT THEIR SERVICES TO
WORK TOGETHER IN ORDER TO ACCOMPLISH SOMETHING NEW. INSTEAD OF USING A SINGLE SITE FOR ALL THEIR ONLINE NEEDS,
USERS USE ONE SITE FOR THEIR PHOTOS, ANOTHER FOR VIDEOS, ANOTHER FOR EMAIL, AND SO ON. NO ONE SITE CAN DO EVERYTHING
BETTER. IN ORDER TO ENABLE THIS KIND OF INTEGRATION, SITES NEED TO ACCESS THE USER RESOURCES FROM OTHER SITES, AND
THESE ARE OFTEN PROTECTED (PRIVATE FAMILY PHOTOS, WORK DOCUMENTS, BANK RECORDS). THEY NEED A KEY TO GET IN.

16
THE KEY USED BY USERS IS USUALLY A COMBINATION OF USERNAME AND PASSWORD. THIS CAN BE AN OPENID OR ANY OTHER LOGIN
CREDENTIAL. BUT THIS KEY IS TOO POWERFUL AND UNRESTRICTED TO SHARE AROUND. IT ALSO CANNOT BE UNSHARED ONCE HANDED
OUT EXCEPT FOR CHANGING IT WHICH WILL VOID ACCESS TO EVERY SITE, NOT JUST THE ONE THE USER INTENDS TO BLOCK. OAUTH
ADDRESSES THAT BY ALLOWING USERS TO HAND OUT TOKENS INSTEAD. EACH TOKEN GRANTS ACCESS TO A SPECIFIC SITE (A VIDEO
EDITING SITE) FOR SPECIFIC RESOURCES (JUST VIDEOS FROM LAST WEEKEND) AND FOR A DEFINED DURATION (THE NEXT 2 HOURS).
.

16
UNLIKE OPENID WHERE USERS MUST DO SOMETHING FIRST – GET AN OPENID IDENTITY THEY CAN USE TO SIGN-INTO SITES – OAUTH
IS COMPLETELY TRANSPARENT TO THE USERS. IN MANY CASES (IF DONE RIGHT), THE END-USER WILL NOT KNOW ANYTHING ABOUT
OAUTH, WHAT IT IS OR HOW IT WORKS. THE USER EXPERIENCE WILL BE SPECIFIC TO THE IMPLEMENTATION OF BOTH THE SITE
REQUESTING ACCESS AND THE ONE STORING THE RESOURCES, AND ADJUSTED TO THE DEVICE BEING USED (WEB BROWSER, MOBILE
PHONE, PDA, SET-TOP BOX).

17
A TYPICAL EXAMPLE OFFERED BY THE SPEC IS WHEN A USER WANTS TO PRINT A PHOTO STORED ON ANOTHER SITE. THE INTERACTION
GOES SOMETHING LIKE THIS: THE USER SIGNS INTO THE PRINTER WEBSITE AND PLACE AN ORDER FOR PRINTS. THE PRINTER WEBSITE
ASKS WHICH PHOTOS TO PRINT AND THE USER CHOOSES THE NAME OF THE SITE WHERE HER PHOTOS ARE STORED (FROM THE LIST OF
SITES SUPPORTED BY THE PRINTER). THE PRINTER WEBSITE SENDS THE USER TO THE PHOTO SITE TO GRANT ACCESS. AT THE PHOTO
SITE THE USER SIGNS INTO HER ACCOUNT AND IS ASKED IF SHE REALLY WANTS TO SHARE HER PHOTOS WITH THE PRINTER. IF SHE
AGREES, SHE IS SENT BACK TO THE PRINTER SITE WHICH CAN NOW ACCESS THE PHOTOS. AT NO POINT DID THE USER SHARE HER
USERNAME AND PASSWORD WITH THE PRINTER SITE.

17
SCOPE

17
WHAT IS PUBLICLY KNOWN AS ‘OAUTH’ IS REALLY THE ‘OAUTH CORE 1.0’ SPECIFICATION. THE CORE DESIGNATION IS USED TO
STRESS THAT THIS IS THE SKELETON OTHER EXTENSIONS AND PROTOCOLS CAN BUILD UPON. OAUTH CORE 1.0 DOES NOT BY ITSELF
3
PROVIDE MANY DESIRED FEATURES SUCH AS AUTOMATED DISCOVERY OF ENDPOINTS, LANGUAGE SUPPORT, SUPPORT FOR XML-RPC
AND SOAP, STANDARD DEFINITION OF RESOURCE ACCESS, OPENID INTEGRATION, A FULL RANGE OF SIGNING ALGORITHMS, AND
MANY OTHER GREAT IDEAS

17
THIS WAS INTENTIONAL AND IS VIEWED BY THE AUTHORS AS A BENEFIT. AS THE NAME IMPLIES, CORE DEALS WITH THE MOST
FUNDAMENTAL ASPECTS OF THE PROTOCOL:

17
• ESTABLISH A MECHANISM FOR EXCHANGING A USERNAME AND PASSWORD FOR A TOKEN WITH DEFINED RIGHTS

17
• PROVIDE TOOLS TO PROTECT THESE TOKENS

17
IT IS IMPORTANT TO UNDERSTAND THAT SECURITY AND PRIVACY ARE NOT GUARANTEED BY THE PROTOCOL. IN FACT, OAUTH BY ITSELF
PROVIDES NO PRIVACY AT ALL AND DEPENDS ON OTHER PROTOCOLS TO ACCOMPLISH THAT (SUCH AS SSL). WITH THAT SAID, OAUTH
CAN BE IMPLEMENTED IN A VERY SECURE MANNER AND THE SPECIFICATION INCLUDES A GOOD AMOUNT OF SECURITY
CONSIDERATIONS TO TAKE INTO ACCOUNT WHEN WORKING WITH SENSITIVE RESOURCES. JUST LIKE USING PASSWORDS TOGETHER
WITH USERNAMES TO GAIN ACCESS, SITES WILL USE TOKENS TOGETHER WITH SECRETS TO ACCESS RESOURCES. AND JUST LIKE
PASSWORDS, SECRETS MUST BE PROTECTED.

18
DEFINITIONS

18
SECTION 3 CONTAINS DEFINITIONS TO FUNDAMENTAL PROTOCOL CONCEPTS REFERENCED THROUGHOUT THE SPEC. BECAUSE
UNDERSTANDING OAUTH DEPENDS ON THESE TERMS, THEY DESERVE SOME EXPLANATION:

18
• 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.

18
• 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.

18
• 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.

18
• 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.

18
• 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.

19
2.4 COMPARISON BETWEEN OAUTH AND OPENID

19
2.5 COMBINE OPENID AND OAUTH FOR SECURING WEB SERVICE

21
CONCLUSION 26

REFERENCES 27
4
I . Summary
Today, internet is developing very fast and it is being popular all over the world.
Therefore, software engineering has a lot of changes. Desktop application now is
replaced by web application. With computer connected internet and any browser, you can
use a lot of application. For examples, we can use Google docs to create and edit
documents, or use Google calendar to manage time, events or use Flick to store, share,
edit your pictures…We ever heard something about cloud computing, web service…Web
services can easily understood that they can convert your applications into web
applications and they are published, found and used through the Web. Web service now
become popular so improving it is important and difficult work especially in security
problems. Hence, Oauth (Open Authorization) protocol was developed and first
published in 2007 quickly become standard authorization protocol in web service
security. It allows users use third party application without share username and password.
In this document we will understand about Oauth definition and the way to apply it into
building web service.
5
I I. Motiv ation
Today internet develop very fast, especially in Viet Nam in recent year, internet become
popular. The quality of internet also increases considerably. Therefore, web applications
gradually become familiar with people using internet. Today, only with any browser
connected internet, we can use a huge number application that in the old days we can
only use in desktop environment. We do not need to install into computer, hardware
requirement is not too high, so clearly web applications have a lot of advantages.
Certainly, we ever used many famous web applications like Google docs where we can
create, edit, and store our documents, or Flick where we can upload and share our
pictures, or many social network pages like Facebook, Twitter…also are web
applications. We can call them are web services and with the quick increment of web
services, security problems become the most important thing because almost security

problem come from internet. We can see that a lot of internet users lost their account,
control…by hackers. Therefore, the requirement for new protocol for web service that
has advantages for both users and developers appeared: Oauth. This protocol quickly
became standard for authorization of web service. A lot of web services applied Oauth
like Facebook, Twitter, Google, Yahoo…and it also important with developers…In Viet
Nam, securing web service with Oauth is very important.
6
I II. I mplementation
In this part, we will understand many related thing to solve our problem
2.1 Web service
2.1.1 Definition
Firstly, we need to know what web service is.
Web services come into being long times go. They have a lot of application in many
fields. Web service is place that store data and implement data. A lot of users can use
web service for create their own applications. Using web services we can save a lot of
time and force and applications also are better.
Follow wiki A Web service is a method of communication between two electronic
devices over the web (internet).
In the summary, web service can understood like these thing
• Web services are application components
• Web services communicate using open protocols
• Web services are self-contained and self-describing
• Web services can be discovered using UDDI
• Web services can be used by other applications
• XML is the basis for Web services
How does it work?
The basic Web services platform is XML + HTTP.
XML provides a language which can be used between different platforms and
programming languages and still express complex messages and functions.
The HTTP protocol is the most used Internet protocol.

7
Web services platform elements:
• SOAP (Simple Object Access Protocol)
• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)
2.1.2 Characters and components of web service
2.1.2.1 Characters
• Interoperability has Highest Priority
When all major platforms could access the Web using Web browsers, different platforms
could interact. For these platforms to work together, Web-applications were developed.
Web-applications are simply applications that run on the web. These are built around the
Web browser standards and can be used by any browser on any platform
• Web Services take Web-applications to the Next Level
By using Web services, your application can publish its function or message to the rest of
the world.
• Web services use XML to code and to decode data, and SOAP to transport it
(using open protocols)
• Web Services have Two Types of Uses
– Reusable application-components.
– Connect existing software.
Web services can help to solve the interoperability problem by giving different
applications a way to link their data.
With Web services you can exchange data between different applications and different
platforms.
8
2.1.2.2 Elements
A, SOAP
SOAP is an XML-based protocol to let applications exchange information over HTTP.
Or more simple: SOAP is a protocol for accessing a Web Service.
• SOAP stands for Simple Object Access Protocol

• SOAP is a communication protocol
• SOAP is a format for sending messages
• SOAP is designed to communicate via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls
• SOAP is a W3C standard
Why SOAP?
It is important for application development to allow Internet communication between
programs. Today's applications communicate using Remote Procedure Calls (RPC)
between objects like DCOM and CORBA, but HTTP was not designed for this. RPC
represents a compatibility and security problem; firewalls and proxy servers will
normally block this kind of traffic.
A better way to communicate between applications is over HTTP, because HTTP is
supported by all Internet browsers and servers. SOAP was created to accomplish this.
SOAP provides a way to communicate between applications running on different
operating systems, with different technologies and programming languages.
More about SOAP we can find in />A SOAP Example
9
In the example below, a GetStockPrice request is sent to a server. The request has a
StockName parameter, and a Price parameter that will be returned in the response. The
namespace for the function is defined in " />A SOAP request:
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope

xmlns:soap=" />soap:encodingStyle=" /><soap:Body xmlns:m=" /> <m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
The SOAP response:
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap=" />soap:encodingStyle=" /><soap:Body xmlns:m=" /> <m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
10
</soap:Body>
</soap:Envelope>
B. WSDL
WSDL is an XML-based language for locating and describing Web services.
• WSDL stands for Web Services Description Language
• WSDL is based on XML
• WSDL is used to describe Web services
• WSDL is used to locate Web services
• WSDL is a W3C standard
WSDL is a document written in XML. The document describes a Web service. It
specifies the location of the service and the operations (or methods) the service exposes.
The WSDL Document Structure
A WSDL document describes a web service using these major elements:
Element Defines
<types> The data types used by the web service

<message> The messages used by the web service
<portType> The operations performed by the web service
<binding> The communication protocols used by the web service
The main structure of a WSDL document looks like this:
<definitions>
<types>
definition of types
</types>
<message>
definition of a message
</message>
11
<portType>
definition of a port
</portType>
<binding>
definition of a binding
</binding>
</definitions>
A WSDL document can also contain other elements, like extension elements, and a
service element that makes it possible to group together the definitions of several web
services in one single WSDL document.
WSDL Example
This is a simplified fraction of a WSDL document:
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
In this example the <portType> element defines "glossaryTerms" as the name of a port,
and "getTerm" as the name of an operation.
12
The "getTerm" operation has an input message called "getTermRequest" and an output
messagecalled "getTermResponse".
The <message> elements define the parts of each message and the associated data types.
Compared to traditional programming, glossaryTerms is a function library, "getTerm" is
a function with "getTermRequest" as the input parameter, and getTermResponse as the
return parameter.
C. XML
What is XML?
• XML stands for EXtensible Markup Language
• XML is a markup language much like HTML
• XML was designed to carry data, not to display data
• XML tags are not predefined. You must define your own tags
• XML is designed to be self-descriptive
• XML is a W3C Recommendation
The Difference between XML and HTML that XML is not a replacement for HTML and
XML and HTML were designed with different goals:
• XML was designed to transport and store data, with focus on what data is
• HTML was designed to display data, with focus on how data looks
HTML is about displaying information, while XML is about carrying information.
Maybe it is a little hard to understand, but XML does not DO anything. XML was created
to structure, store, and transport information

Some characters of XML we should care about
• With XML You Invent Your Own Tags
• XML is Not a Replacement for HTML
• XML is a software- and hardware-independent tool for carrying information.
XML is now as important for the Web as HTML was to the foundation of the
Web.
13
• XML is the most common tool for data transmissions between all sorts of
applications.
• XML Separates Data from HTML
• XML Simplifies Data Sharing
• XML Simplifies Data Transport
• XML Simplifies Platform Changes
• XML Makes Your Data More Available
• XML is used to Create New Internet Languages
• A lot of new Internet languages are created with XML.
An Example XML Document
XML documents use a self-describing and simple syntax:
<?xml version="1.0" encoding="ISO-8859-1"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
D. Web API
Web services in a service oriented architecture.
Web API is a development in Web services (in a movement called Web 2.0) where
emphasis has been moving away from SOAP based services towards representational
14

state transfer (REST) based communications. REST services do not require XML, SOAP,
or WSDL service-API definitions.
Web APIs allow the combination of multiple Web services into new applications known
as mashups.
When used in the context of Web development, Web API is typically a defined set of
Hypertext Transfer Protocol (HTTP) request messages along with a definition of the
structure of response messages, usually expressed in an Extensible Markup Language
(XML) or JavaScript Object Notation (JSON) format.
When running composite Web services, each sub service can be considered autonomous.
The user has no control over these services. Also the Web services themselves are not
reliable; the service provider may remove, change or update their services without giving
notice to users. The reliability and fault tolerance is not well supported; faults may
happen during the execution. Exception handling in the context of Web services is still an
open research issue, although this can still be handled by responding with an error object
to the clients.
2.1.3 WS security
As we can see in the previous part, security in web service is the most important thing.
Firstly, we must know basic components of security: confidentiality, integrity,
availability
And now the challenges of Web service security
• Authentication
• Authorization
• Identity management
• Encryption of messages
• Integrity of messages
Each of challenges in web service security problems has their own methods but not
always they are all good. Work to find the best solution for security of web service is now
still hard job. But we temporary do not care about other thing. In this document I will
show you Oauth protocol for authorization in web service. It is quite safe and trusty.
15

2.2 Open ID
OpenID is an open standard that describes how users can be authenticated in a
decentralized manner, eliminating the need for services to provide their own ad hoc
systems and allowing users to consolidate their digital identities. Users may create
accounts with their preferred OpenID identity providers, and then use those accounts as
the basis for signing on to any website which accepts OpenID authentication. The
OpenID standard provides a framework for the communication that must take place
between the identity provider and the OpenID acceptor (the ‘relying party’). An
extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user
attributes, such as name and gender, from the OpenID identity provider to the relying
party (each relying party may request a different set of attributes, depending on its
requirements).
The OpenID protocol does not rely on a central authority to authenticate a user's identity.
Moreover, neither services nor the OpenID standard may mandate a specific means by
which to authenticate users, allowing for approaches ranging from the common (such as
passwords) to the novel (such as smart cards or biometrics).
The term OpenID may also refer to an identifier as specified in the OpenID standard;
these identifiers take the form of a unique URI, and are managed by some 'OpenID
provider' that handles authentication.
OpenID enables an End-user, the entity that wants to assert a particular identity, to
communicate with a Relying party (RP), the site that wants to verify the end-user's
identifier. Other terms for this party include "service provider" or the now obsolete
"consumer". This communication is done through the exchange of an Identifier
or OpenID, which is the URL or XRI chosen by the end-user to name the end-user's
identity. An Identity provider or OpenID provider (OP) , which is a service that
specializes in registering OpenID URLs or XRIs, provides the OpenID authentication
(and possibly other identity services). The exchange is enabled by a User-agent, which is
the program (such as a browser) used by the end-user to communicate with the relying
party and OpenID provider.
16

2.3 Oauth
Introduction
End-User Benefits: 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. When use web service, users put themselves
at risk sharing the same private information. OAuth is the rescue.
Both the valet key and ATM cards are good metaphors for OAuth from a user
perspective. Instead of giving your ATM card and PIN code, the card can double as a
credit card with a signature authorization. Just like your username and password
provide full access to your resources, your ATM card and PIN code provide you with
great control over your bank accounts – much more than just charging goods. But
when you replace the PIN code with your signature, the card becomes very limited
and can only be used for limited access.
Users don’t care about protocols and standards – they care about better experience with
enhanced privacy and security. This is exactly what OAuth sets to achieve. With web
services on the rise, people expect their services to work together in order to
accomplish something new. Instead of using a single site for all their online needs,
users use one site for their photos, another for videos, another for email, and so on.
No one site can do everything better. In order to enable this kind of integration, sites
need to access the user resources from other sites, and these are often protected
(private family photos, work documents, bank records). They need a key to get in.
The key used by users is usually a combination of username and password. This can be
an OpenID or any other login credential. But this key is too powerful and unrestricted
to share around. It also cannot be unshared once handed out except for changing it
which will void access to every site, not just the one the user intends to block. OAuth
addresses that by allowing users to hand out tokens instead. Each token grants access
to a specific site (a video editing site) for specific resources (just videos from last
weekend) and for a defined duration (the next 2 hours).
17
Unlike OpenID where users must do something first – get an OpenID identity they can

use to sign-into sites – OAuth is completely transparent to the users. In many cases
(if done right), the end-user will not know anything about OAuth, what it is or how it
works. The user experience will be specific to the implementation of both the site
requesting access and the one storing the resources, and adjusted to the device being
used (web browser, mobile phone, PDA, set-top box).
A typical example offered by the spec is when a user wants to print a photo stored on
another site. The interaction goes something like this: the user signs into the printer
website and place an order for prints. The printer website asks which photos to print
and the user chooses the name of the site where her photos are stored (from the list of
sites supported by the printer). The printer website sends the user to the photo site to
grant access. At the photo site the user signs into her account and is asked if she
really wants to share her photos with the printer. If she agrees, she is sent back to the
printer site which can now access the photos. At no point did the user share her
username and password with the printer site.
Scope
What is publicly known as ‘OAuth’ is really the ‘OAuth Core 1.0’ specification. The
Core designation is used to stress that this is the skeleton other extensions and
protocols can build upon. OAuth Core 1.0 does NOT by itself provide many desired
features such as automated discovery of endpoints, language support, support for
XML-RPC and SOAP, standard definition of resource access, OpenID integration, a
full range of signing algorithms, and many other great ideas
This was intentional and is viewed by the authors as a benefit. As the name implies, Core
deals with the most fundamental aspects of the protocol:
• Establish a mechanism for exchanging a username and password for a token with
defined rights
• Provide tools to protect these tokens
18
It is important to understand that security and privacy are not guaranteed by the protocol.
In fact, OAuth by itself provides no privacy at all and depends on other protocols to
accomplish that (such as SSL). With that said, OAuth can be implemented in a very

secure manner and the specification includes a good amount of security
considerations to take into account when working with sensitive resources. Just like
using passwords together with usernames to gain access, sites will use tokens
together with secrets to access resources. And just like passwords, secrets must be
protected.
Definitions
Section 3 contains definitions to fundamental protocol concepts referenced throughout
the spec. Because understanding OAuth depends on these terms, they deserve some
explanation:
• 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.

19
• 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.
2.4 Comparison between Oauth and OpenID
OAuth, OpenID…they sound like the same thing and they kind of do vaguely similar
things. But OAuth is not Open ID. They have a different purpose.
To start with, here’s what OAuth does have in common with Open ID:
 They both live in the general domain of security, identity, and authorization
 They are open web standards. Created and evolved by people with an itch to
scratch and evolved pragmatically by a loose, fluid, alliance. Think REST, not
SOAP.
 They both celebrate decentralization. There is no central Open ID or OAuth server
that holds all the security information in the universe (cf Passport). Anyone can set
up as a server or a client.
 They both involve browser redirects from the website you’re trying to use – the
“consumer” website – to a distinct “provider” website, and back again. Meanwhile,
those websites talk to each other behind the scenes to verify what just happened.
 The user can actively manage the provider website, exerting control over which
websites can talk to it and for how long.
And there are some differences:
Open ID gives you one login for multiple sites. Each time you need to log into Zooomr –
a site using Open ID – you will be redirected to your Open ID site where you login, and
then back to Zooomr. OAuth lets you authorize one website – the consumer – to access
your data from another website – the provider.
With Open ID, there is no suggestion of two web apps sharing your data. Except in the
very limited sense that the Open ID provider may hold some general information about
you, e.g. some photos, addresses, phone numbers, etc., and with your consent, send it

back to the consumer so you don’t have to re-enter all the boring profile details again.
However, this is data of a generic, non-application-specific, nature. (And even this
20
limited form of sharing is an extension to the core Open ID spec.) With OAuth, any
information you hold on any website can be shared with another website. You could
share your GMail with a clever consumer that automatically tags items by inspecting the
content, if GMail was an OpenAuth consumer.
Or you could copy your GMail address book into Facebook, by allowing Facebook to
read your GMail account. Right now, the only way to do that is to give Facebook your
GMail username and password. Clearly a dumb thing to do, and that’s exactly the kind of
thing OAuth is set up to prevent. OAuth prevents it by explicitly asking you if you want
to let Facebook grab your details from the provider. That’s not a problem Open ID
solves. Even if Facebook and GMail used Open ID and you had accounts with both
against the same Open ID, you still couldn’t get Facebook to read your GMail account.
The Open ID provider wouldn’t let Facebook log in to GMail as if it was you. Even if an
Open ID extension came along to allow it, you wouldn’t want it. It’s too coarse-grained
and would allow the consumer to do too much potential damage. OAuth is more fine-
grained – consumers can do some things with your provider data, not everything.
The following drawing highlights the differences between using OpenID vs. OAuth for
authentication. Note that with OpenID, the process starts by the application asking the
user for their identity (typically an openid URI), whereas in the case of OAuth, the
application directly requests a limited access OAuth Token (valet key) to access the APIs
(enter the house) on the user's behalf. If the user can grant that access, the application can
21
retrieve the unique identifier for establishing the profile (identity) using the APIs.
2.5 Combine OpenID and Oauth for securing web service
As we can see a lot of thing above, OpenID and Oauth for authentication and
authorization in web service are the secure methods. Therefore, we will find the
way to apply both of them to protect our service, maybe it is combination between
these protocols into only one extension

This extension describes how to embed an OAuth approval request into an OpenID
authentication request to permit combined user approval. For security reasons, the OAuth
access token is not returned in the OpenID authentication response. Instead a mechanism
to obtain the access token is provided
Unlike standard OAuth, the OpenID OAuth Extension does not provision request
tokens in a server-to-server request from the Combined Consumer to the request
token endpoint at the Combined Provider. Instead, the Combined Provider returns an
already-approved request token to the Combined Consumer as part of the OpenID
authentication response.
22
The Combined Consumer then exchanges the request token for an access token at the
access token endpoint of the Combined Provider, following standard OAuth practice.
The process can be described in many below steps:
• Extension Namespace
All OpenID messages that contain an OpenID OAuth Extension element MUST
contain the following extension namespace declaration:
openid.ns.<alias>= />• Discovery
The OpenID OAuth Extension namespace
" SHOULD be listed as an <xrd:Type>
child element of the <xrd:Service> element in the XRDS discovery document
• Before Requesting Authentication - Registration
The Combined Consumer and the Combined Provider agree on a consumer key
and consumer secret
The Combined Provider SHOULD in addition obtain, from the Combined
Consumer, a list of valid OpenID realms that the Combined Consumer may use
in subsequent authentication requests. The Combined Provider SHOULD verify
that the Combined Consumer is authorized to use those realms.
• Requesting Authentication
When requesting OpenID Authentication via the protocol mode "checkid_setup"
or "checkid_immediate", this extension can be used to request that the end user

authorize an OAuth access token at the same time as an OpenID authentication.
This is done by sending the following parameters as part of the OpenID request.
openid.ns.oauth
REQUIRED. Value: " />openid.oauth.consumer
REQUIRED. Value: The consumer key agreed upon in Section 7.
23
openid.oauth.scope
OPTIONAL. Value: A string that encodes, in a way possibly specific to the
Combined Provider, one or more scopes for the OAuth token expected in the
authentication response.
• Authorizing the OAuth Request
If the OpenID OAuth Extension is present in the authentication request, the
Combined Provider SHOULD verify that the consumer key passed in the
request is authorized to be used for the realm passed in the request. If this
verification succeeds, the Combined Provider SHOULD determine that
delegation of access from a user to the Combined Consumer has been requested.
The Combined Provider SHOULD NOT issue an approved request token unless
it has user consent to perform such delegation.
• Responding to Authentication Requests
If the OpenID authentication request cannot be fulfilled then the OAuth request
SHOULD be considered to fail and the Provider MUST NOT send any OpenID
OAuth Extension values in the response.
The remainder of this section specifies how to handle the OAuth request in
cases when the OpenID authentication response is a positive assertion.
If the end user does wish to delegate access to the Combined Consumer, the
Combined Provider MUST include and MUST sign the following parameters.
openid.ns.oauth
REQUIRED.
openid.oauth.request_token
REQUIRED. A user-approved request token.

openid.oauth.scope
OPTIONAL. A string that encodes, in a way possibly specific to the Combined
Provider, one or more scopes that the returned request token is valid for. This will
typically indicate a subset of the scopes requested
24
To note that the OAuth Authorization was declined or not valid, the Combined
Provider SHALL only respond with the parameter "openid.ns.oauth".
• Obtaining the Access Token
To exchange the request token for an access token, the Combined Consumer
sends an access token request to the access token endpoint of the Combined
Provider. It SHALL use the following values to create the OAuth access token
request:
consumer key: Combined Consumers use the consumer key they established with the
Combined Provider
consumer secret: Combined Consumers use the consumer secret they established
with the Combined Provider
OAuth token: Combined Consumers use the request token
OAuth token secret: Combined Consumers use the empty string.
The Combined Provider verify the request and either issue the access token or
send an error response.
The example here
25
User use extension to login to site using OpenID and request permission to site
access data from service.
Now user already login and the site also can use your user data