OAuth Protocol Workflow

http://hueniverse.com/oauth/guide/workflow/
OAuth is best explained with real-life examples. The specification
introduction includes a similar example but focuses on the HTTP calls
syntax. This walk-through demonstrates a typical OAuth session and
includes the perspectives of the resource owner, client, and server. The
websites and people mentioned are fictional. The Scottish references are
real. And so our story begins

Jane is back from her Scotland vacation. She spent 2 weeks on the island
of Islay sampling Scotch. When she gets back home, Jane wants to share
some of her vacation photos with her friends. Jane uses Faji, a photo
sharing site, for sharing journey photos. She signs into her faji.com
account, and uploads two photos which she marks private.
Using OAuth terminology, Jane is the resource owner and Faji the server.
The 2 photos Jane uploaded are the protected resources.

After sharing her photos with a few of her online friends, Jane wants to
also share them with her grandmother. She doesnt want to share her rare
bottle of Scotch with anyone. But grandma doesnt have an internet
connection so Jane plans to order prints and have them mailed to
grandma. Being a responsible person, Jane uses Beppa, an
environmentally friendly photo printing service.
Using OAuth terminology, Beppa is the client. Since Jane marked the
photos as private, Beppa must use OAuth to gain access to the photos in
order to print them.
Jane visits beppa.com and begins to order prints. Beppa supports
importing images from many photo sharing sites, including Faji. Jane
selects the photos source and clicks Continue.

When Beppa added support for Faji photo import, a Beppa developer
known in OAuth as a client developer obtained a set of client credentials
(client identifier and secret) from Faji to be used with Fajis OAuth-enabled
API.
After Jane clicks Continue, something important happens in the
background between Beppa and Faji. Beppa requests from Faji a set of
temporary credentials. At this point, the temporary credentials are not
resource-owner-specific, and can be used by Beppa to gain resource
owner approval from Jane to access her private photos.

Jane clicked Continue and is now waiting for her screen to change. She
sips from her prized Black Bowmore while waiting for the next page to
load.
When Beppa receives the temporary credentials, it redirects Jane to the
Faji OAuth User Authorization URL with the temporary credentials and asks
Faji to redirect Jane back once approval has been granted to
http://beppa.com/order.
Jane has been redirected to Faji and is requested to sign into the site.
OAuth requires that servers first authenticate the resource owner, and
then ask them to grant access to the client.
Jane notices she is now at a Faji page by looking at the browser URL, and
enters her username and password.

OAuth allows Jane to keep her username and password private and not
share them with Beppa or any other site. At no time does Jane enters her
credentials into beppa.com.
After successfully logging into Faji, Jane is asked to grant access to Beppa,
the client. Faji informs Jane of who is requesting access (in this case
Beppa) and the type of access being granted. Jane can approve or deny
access.
Jane makes sure Beppa is getting the limited access it needs. She does
not want to allow Beppa to change her photos or do anything else to

them. She also notes this is a onetime access good for one hour which
should be enough time for Beppa to fetch her photos.

Once Jane approves the request, Faji marks the temporary credentials as
resource-owner-authorized by Jane. Janes browser is redirected back to
Beppa, to the URL previously provided http://beppa.com/order together
with the temporary credentials identifier. This allows Beppa to know it can
now continue to fetch Janes photos.
Jane waits for Beppa to present her with her photos fetched from her Faji
account.

While Jane waits, Beppa uses the authorized Request Token and
exchanges it for an Access Token. Request Tokens are only good for
obtaining User approval, while Access Tokens are used to access Protected
Resources, in this case Janes photos. In the first request, Beppa
exchanges the Request Token for an Access Token and in the second (can
be multiple requests, one for a list of photos, and a few more to get each
photo) request gets the photos.

When Beppa is done, Janes browser refreshes to complete the order.

Example
http://tools.ietf.org/html/rfc5849#section-1.2
Jane (resource owner) has recently uploaded some private vacation
photos (protected resources) to her photo sharing site
'photos.example.net' (server). She would like to use the
'printer.example.com' website (client) to print one of these photos.
Typically, Jane signs into 'photos.example.net' using her username
and password.
However, Jane does not wish to share her username and password with
the 'printer.example.com' website, which needs to access the photo in
order to print it. In order to provide its users with better
service, 'printer.example.com' has signed up for a set of
'photos.example.net' client credentials ahead of time:
Client Identifier
dpf43f3p2l4k3l03
Client Shared-Secret:
kd94hf93k423kf44
The 'printer.example.com' website has also configured its application
to use the protocol endpoints listed in the 'photos.example.net' API
documentation, which use the "HMAC-SHA1" signature method:
Temporary Credential Request
https://photos.example.net/initiate
Resource Owner Authorization URI:
https://photos.example.net/authorize
Token Request URI:
https://photos.example.net/token
Before 'printer.example.com' can ask Jane to grant it access to the
photos, it must first establish a set of temporary credentials with
'photos.example.net' to identify the delegation request. To do so,
the client sends the following HTTPS [RFC2818] request to the server:
POST /initiate HTTP/1.1
Host: photos.example.net
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",

oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131200",
oauth_nonce="wIjqoS",
oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"
The server validates the request and replies with a set of temporary
credentials in the body of the HTTP response (line breaks are for
display purposes only):
HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencoded

oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03
&
oauth_callback_confirmed=true
The client redirects Jane's user-agent to the server's Resource Owner
Authorization endpoint to obtain Jane's approval for accessing her
private photos:
https://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola
The server requests Jane to sign in using her username and password
and if successful, asks her to approve granting 'printer.example.com'
access to her private photos. Jane approves the request and her
user-agent is redirected to the callback URI provided by the client
in the previous request (line breaks are for display purposes only):
http://printer.example.com/ready?
oauth_token=hh5s93j4hdidpola&oauth_verifier=hfdp7dh39dks9884
The callback request informs the client that Jane completed the
authorization process. The client then requests a set of token
credentials using its temporary credentials (over a secure Transport
Layer Security (TLS) channel):
POST /token HTTP/1.1
Host: photos.example.net
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_token="hh5s93j4hdidpola",

oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="walatlh",
oauth_verifier="hfdp7dh39dks9884",
oauth_signature="gKgrFCywp7rO0OXSjdot%2FIHF7IU%3D"
The server validates the request and replies with a set of token
credentials in the body of the HTTP response:
HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencoded

oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00
With a set of token credentials, the client is now ready to request
the private photo:
GET /photos?file=vacation.jpg&size=original HTTP/1.1
Host: photos.example.net
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_token="nnch734d00sl2jdk",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131202",
oauth_nonce="chapoH",
oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D"
The 'photos.example.net' server validates the request and responds
with the requested photo. 'printer.example.com' is able to continue
accessing Jane's private photos using the same set of token
credentials for the duration of Jane's authorization, or until Jane
revokes access.