[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5849

Network Working Group                               E. Hammer-Lahav, Ed.
Internet-Draft                                                   B. Cook
Intended status: Standards Track                      September 30, 2008
Expires: April 3, 2009


             OAuth: HTTP Authorization Delegation Protocol
                         draft-hammer-oauth-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 3, 2009.

Abstract

   This document specifies OAuth, an HTTP authorization delegation
   protocol for accessing protected resources.













Hammer-Lahav & Cook       Expires April 3, 2009                 [Page 1]

Internet-Draft        OAuth Authorization Protocol        September 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Documentation and Registration . . . . . . . . . . . . . . . .  5
     4.1.   Request URLs  . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.   Service Providers . . . . . . . . . . . . . . . . . . . .  6
     4.3.   Consumers . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Parameters . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.   Consumer Request Parameters . . . . . . . . . . . . . . .  7
     5.2.   Service Provider Response Parameters  . . . . . . . . . .  7
     5.3.   OAuth HTTP Authorization Scheme . . . . . . . . . . . . .  7
       5.3.1.  Authorization Header . . . . . . . . . . . . . . . . .  7
       5.3.2.  WWW-Authenticate Header  . . . . . . . . . . . . . . .  8
   6.  Authenticating with OAuth  . . . . . . . . . . . . . . . . . .  8
     6.1.   Obtaining an Unauthorized Request Token . . . . . . . . .  9
       6.1.1.  Consumer Obtains a Request Token . . . . . . . . . . .  9
       6.1.2.  Service Provider Issues an Unauthorized Request
               Token  . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.2.   Obtaining User Authorization  . . . . . . . . . . . . . . 10
       6.2.1.  Consumer Directs the User to the Service Provider  . . 10
       6.2.2.  Service Provider Authenticates the User and
               Obtains Consent  . . . . . . . . . . . . . . . . . . . 11
       6.2.3.  Service Provider Directs the User Back to the
               Consumer . . . . . . . . . . . . . . . . . . . . . . . 12
     6.3.   Obtaining an Access Token . . . . . . . . . . . . . . . . 12
       6.3.1.  Consumer Requests an Access Token  . . . . . . . . . . 12
       6.3.2.  Service Provider Grants an Access Token  . . . . . . . 13
   7.  Accessing Protected Resources  . . . . . . . . . . . . . . . . 14
   8.  Nonce and Timestamp  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Signing Requests . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.   Signature Base String . . . . . . . . . . . . . . . . . . 15
       9.1.1.  Parameter Encoding . . . . . . . . . . . . . . . . . . 15
       9.1.2.  Normalize Request Parameters . . . . . . . . . . . . . 16
       9.1.3.  Construct Request URL  . . . . . . . . . . . . . . . . 17
       9.1.4.  Concatenate Request Elements . . . . . . . . . . . . . 17
     9.2.   HMAC-SHA1 . . . . . . . . . . . . . . . . . . . . . . . . 17
       9.2.1.  Generating Signature . . . . . . . . . . . . . . . . . 18
       9.2.2.  Verifying Signature  . . . . . . . . . . . . . . . . . 18
     9.3.   RSA-SHA1  . . . . . . . . . . . . . . . . . . . . . . . . 18
       9.3.1.  Generating Signature . . . . . . . . . . . . . . . . . 18
       9.3.2.  Verifying Signature  . . . . . . . . . . . . . . . . . 18
     9.4.   PLAINTEXT . . . . . . . . . . . . . . . . . . . . . . . . 19
       9.4.1.  Generating Signature . . . . . . . . . . . . . . . . . 19
       9.4.2.  Verifying Signature  . . . . . . . . . . . . . . . . . 19
   10. HTTP Response Codes  . . . . . . . . . . . . . . . . . . . . . 19
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20



Hammer-Lahav & Cook       Expires April 3, 2009                 [Page 2]

Internet-Draft        OAuth Authorization Protocol        September 2008


   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
     12.1.  Credentials and Token Exchange  . . . . . . . . . . . . . 20
     12.2.  RSA-SHA1 Signature Method . . . . . . . . . . . . . . . . 20
     12.3.  PLAINTEXT Signature Method  . . . . . . . . . . . . . . . 20
     12.4.  Confidentiality of Requests . . . . . . . . . . . . . . . 21
     12.5.  Spoofing by Counterfeit Servers . . . . . . . . . . . . . 21
     12.6.  Proxying and Caching of Authenticated Content . . . . . . 21
     12.7.  Plaintext Storage of Credentials  . . . . . . . . . . . . 21
     12.8.  Secrecy of the Consumer Secret  . . . . . . . . . . . . . 22
     12.9.  Phishing Attacks  . . . . . . . . . . . . . . . . . . . . 22
     12.10. Scoping of Access Requests  . . . . . . . . . . . . . . . 22
     12.11. Entropy of Secrets  . . . . . . . . . . . . . . . . . . . 22
     12.12. Denial of Service / Resource Exhaustion Attacks . . . . . 23
     12.13. Cryptographic Attacks . . . . . . . . . . . . . . . . . . 24
     12.14. Signature Base String Compatibility . . . . . . . . . . . 24
   Appendix A.     Appendix A - Protocol Example  . . . . . . . . . . 24
   Appendix A.1.   Documentation and Registration . . . . . . . . . . 24
   Appendix A.2.   Obtaining a Request Token  . . . . . . . . . . . . 25
   Appendix A.3.   Requesting User Authorization  . . . . . . . . . . 26
   Appendix A.4.   Obtaining an Access Token  . . . . . . . . . . . . 26
   Appendix A.5.   Accessing Protected Resources  . . . . . . . . . . 26
   Appendix A.5.1. Generating Signature Base String . . . . . . . . . 26
   Appendix A.5.2. Calculating Signature Value  . . . . . . . . . . . 27
   Appendix A.5.3. Requesting Protected Resource  . . . . . . . . . . 27
   Appendix B.     Contributors . . . . . . . . . . . . . . . . . . . 28
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     13.1.  Normative References  . . . . . . . . . . . . . . . . . . 29
     13.2.  Informative References  . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
   Intellectual Property and Copyright Statements . . . . . . . . . . 31





















Hammer-Lahav & Cook       Expires April 3, 2009                 [Page 3]

Internet-Draft        OAuth Authorization Protocol        September 2008


1.  Introduction

   The OAuth protocol enables websites or applications (Consumers) to
   access Protected Resources from a web service (Service Provider) via
   an API, without requiring Users to disclose their Service Provider
   credentials to the Consumers.  More generally, OAuth creates a
   freely-implementable and generic methodology for API authentication.

   An example use case is allowing printing service printer.example.com
   (the Consumer), to access private photos stored on photos.example.net
   (the Service Provider) without requiring Users to provide their
   photos.example.net credentials to printer.example.com.

   OAuth does not require a specific user interface or interaction
   pattern, nor does it specify how Service Providers authenticate
   Users, making the protocol ideally suited for cases where
   authentication credentials are unavailable to the Consumer, such as
   with OpenID.

   OAuth aims to unify the experience and implementation of delegated
   web service authentication into a single, community-driven protocol.
   OAuth builds on existing protocols and best practices that have been
   independently implemented by various websites.  An open standard,
   supported by large and small providers alike, promotes a consistent
   and trusted experience for both application developers and the users
   of those applications.

   Discussion of this draft should take place on the OAuth mailing list
   located at oauth@googlegroups.com.  To join the list, visit
   http://groups.google.com/group/oauth (you will be asked to provide a
   reason to join solely as a spam filter).


2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Definitions

   Service Provider:  A web application that allows access via OAuth.

   User:  An individual who has an account with the Service Provider.






Hammer-Lahav & Cook       Expires April 3, 2009                 [Page 4]

Internet-Draft        OAuth Authorization Protocol        September 2008


   Consumer:  A website or application that uses OAuth to access the
      Service Provider on behalf of the User.

   Protected Resource(s):  Data controlled by the Service Provider,
      which the Consumer can access through authentication.

   Consumer Developer:  An individual or organization that implements a
      Consumer.

   Consumer Key:  A value used by the Consumer to identify itself to the
      Service Provider.

   Consumer Secret:  A secret used by the Consumer to establish
      ownership of the Consumer Key.

   Request Token:  A value used by the Consumer to obtain authorization
      from the User, and exchanged for an Access Token.

   Access Token:  A value used by the Consumer to gain access to the
      Protected Resources on behalf of the User, instead of using the
      User's Service Provider credentials.

   Token Secret:  A secret used by the Consumer to establish ownership
      of a given Token.

   OAuth Protocol Parameters:  Parameters with names beginning with
      "oauth_".


4.  Documentation and Registration

   OAuth includes a Consumer Key and matching Consumer Secret that
   together authenticate the Consumer (as opposed to the User) with the
   Service Provider.  Consumer-specific identification allows the
   Service Provider to vary access levels to Consumers (such as un-
   throttled access to resources).

   Service Providers SHOULD NOT rely on the Consumer Secret as a method
   to verify the Consumer identity, unless the Consumer Secret is known
   to be inaccessible to anyone other than the Consumer and the Service
   Provider.  The Consumer Secret MAY be an empty string (for example
   when no Consumer verification is needed, or when verification is
   achieved through other means such as RSA).

4.1.  Request URLs

   OAuth defines three request URLs:




Hammer-Lahav & Cook       Expires April 3, 2009                 [Page 5]

Internet-Draft        OAuth Authorization Protocol        September 2008


   Request Token URL:  The URL used to obtain an unauthorized Request
      Token, described in Section 6.1.

   User Authorization URL:  The URL used to obtain User authorization
      for Consumer access, described in Section 6.2.

   Access Token URL:  The URL used to exchange the User-authorized
      Request Token for an Access Token, described in Section 6.3.

   The three URLs MUST include scheme, authority, and path, and MAY
   include query and fragment as defined by [RFC3986] section 3.  The
   request URL query MUST NOT contain any OAuth Protocol Parameters.
   For example:

     http://sp.example.com/authorize

4.2.  Service Providers

   The Service Provider's responsibility is to enable Consumer
   Developers to establish a Consumer Key and Consumer Secret.  The
   process and requirements for provisioning these are entirely up to
   the Service Providers.

   The Service Provider's documentation includes:

   1.  The URLs (Section 4.1) the Consumer will use when making OAuth
       requests, and the HTTP methods (i.e.  GET, POST, etc.) used in
       the Request Token URL and Access Token URL.

   2.  Signature methods supported by the Service Provider.

   3.  Any additional request parameters that the Service Provider
       requires in order to obtain a Token.  Service Provider specific
       parameters MUST NOT begin with "oauth_".

4.3.  Consumers

   The Consumer Developer MUST establish a Consumer Key and a Consumer
   Secret with the Service Provider.  The Consumer Developer MAY also be
   required to provide additional information to the Service Provider
   upon registration.


5.  Parameters

   OAuth Protocol Parameter names and values are case sensitive.  Each
   OAuth Protocol Parameters MUST NOT appear more than once per request,
   and are REQUIRED unless otherwise noted.



Hammer-Lahav & Cook       Expires April 3, 2009                 [Page 6]

Internet-Draft        OAuth Authorization Protocol        September 2008


5.1.  Consumer Request Parameters

   OAuth Protocol Parameters are sent from the Consumer to the Service
   Provider in one of three methods, in order of decreasing preference:

   1.  In the HTTP "Authorization" header as defined in OAuth HTTP
       Authorization Scheme (Section 5.3).

   2.  As the HTTP request body with a " content-type " of
       "application/x-www-form-urlencoded" as defined by
       [W3C.REC-html40-19980424].

   3.  Added to the URLs in the query part (as defined by [RFC3986]
       section 3).

   In addition to these defined methods, future extensions may describe
   alternate methods for sending the OAuth Protocol Parameters.  The
   methods for sending other request parameters are left undefined, but
   SHOULD NOT use the OAuth HTTP Authorization Scheme (Section 5.3)
   header.

5.2.  Service Provider Response Parameters

   Response parameters such as Tokens and Token Secrets are sent by the
   Service Provider to the Consumer in the HTTP response body using the
   "application/x-www-form-urlencoded" content type as defined by
   [W3C.REC-html40-19980424].  For example:

     oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b

5.3.  OAuth HTTP Authorization Scheme

   This section defines an [RFC2617] extension to support OAuth.  It
   uses the standard HTTP "Authorization" and "WWW-Authenticate" headers
   to pass OAuth Protocol Parameters.

   It is RECOMMENDED that Service Providers accept the HTTP
   "Authorization" header.  Consumers SHOULD be able to send OAuth
   Protocol Parameters in the OAuth "Authorization" header.

   The extension auth-scheme (as defined by [RFC2617]) is "OAuth" and is
   case-insensitive.

5.3.1.  Authorization Header

   The OAuth Protocol Parameters are sent in the "Authorization" header
   the following way:




Hammer-Lahav & Cook       Expires April 3, 2009                 [Page 7]

Internet-Draft        OAuth Authorization Protocol        September 2008


   1.  Parameter names and values are encoded per Parameter Encoding
       (Section 9.1.1).

   2.  For each parameter, the name is immediately followed by an '='
       character (ASCII code 61), a '"' character (ASCII code 34), the
       parameter value (MAY be empty), and another '"' character (ASCII
       code 34).

   3.  Parameters are separated by a comma character (ASCII code 44) and
       OPTIONAL linear whitespace per [RFC2617].

   4.  The OPTIONAL "realm" parameter is added and interpreted per
       [RFC2617], section 1.2.

   For example:

     Authorization: OAuth realm="http://sp.example.com/",
     oauth_consumer_key="0685bd9184jfhq22",
     oauth_token="ad180jjd733klru7",
     oauth_signature_method="HMAC-SHA1",
     oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
     oauth_timestamp="137131200",
     oauth_nonce="4572616e48616d6d65724c61686176",
     oauth_version="1.0"

5.3.2.  WWW-Authenticate Header

   Service Providers MAY indicate their support for the extension by
   returning the OAuth HTTP "WWW-Authenticate" header upon Consumer
   requests for Protected Resources.  As per [RFC2617] such a response
   MAY include additional HTTP "WWW-Authenticate" headers:

   For example:

     WWW-Authenticate: OAuth realm="http://sp.example.com/"

   The realm parameter defines a protection realm per [RFC2617], section
   1.2.


6.  Authenticating with OAuth

   OAuth authentication is the process in which Users grant access to
   their Protected Resources without sharing their credentials with the
   Consumer.  OAuth uses Tokens generated by the Service Provider
   instead of the User's credentials in Protected Resources requests.
   The process uses two Token types:




Hammer-Lahav & Cook       Expires April 3, 2009                 [Page 8]

Internet-Draft        OAuth Authorization Protocol        September 2008


   Request Token:  Used by the Consumer to ask the User to authorize
      access to the Protected Resources.  The User-authorized Request
      Token is exchanged for an Access Token, MUST only be used once,
      and MUST NOT be used for any other purpose.  It is RECOMMENDED
      that Request Tokens have a limited lifetime.

   Access Token:  Used by the Consumer to access the Protected Resources
      on behalf of the User.  Access Tokens MAY limit access to certain
      Protected Resources, and MAY have a limited lifetime.  Service
      Providers SHOULD allow Users to revoke Access Tokens.  Only the
      Access Token SHALL be used to access the Protect Resources.

   OAuth Authentication is done in three steps:

   1.  The Consumer obtains an unauthorized Request Token.

   2.  The User authorizes the Request Token.

   3.  The Consumer exchanges the Request Token for an Access Token.

6.1.  Obtaining an Unauthorized Request Token

   The Consumer obtains an unauthorized Request Token by asking the
   Service Provider to issue a Token.  The Request Token's sole purpose
   is to receive User approval and can only be used to obtain an Access
   Token.  The Request Token process goes as follows:

6.1.1.  Consumer Obtains a Request Token

   To obtain a Request Token, the Consumer sends an HTTP request to the
   Service Provider's Request Token URL.  The Service Provider
   documentation specifies the HTTP method for this request, and HTTP
   POST is RECOMMENDED.  The request MUST be signed and contains the
   following parameters:

   oauth_consumer_key:  The Consumer Key.

   oauth_signature_method:  The signature method the Consumer used to
      sign the request.

   oauth_signature:  The signature as defined in Signing Requests
      (Section 9).

   oauth_timestamp:  As defined in Nonce and Timestamp (Section 8).







Hammer-Lahav & Cook       Expires April 3, 2009                 [Page 9]

Internet-Draft        OAuth Authorization Protocol        September 2008


   oauth_nonce:  As defined in Nonce and Timestamp (Section 8).

   oauth_version:  OPTIONAL.  If present, value MUST be " 1.0 ".
      Service Providers MUST assume the protocol version to be "1.0" if
      this parameter is not present.  Service Providers' response to
      non-"1.0" value is left undefined.

   Additional parameters:  Any additional parameters, as defined by the
      Service Provider.

6.1.2.  Service Provider Issues an Unauthorized Request Token

   The Service Provider verifies the signature and Consumer Key. If
   successful, it generates a Request Token and Token Secret and returns
   them to the Consumer in the HTTP response body as defined in Service
   Provider Response Parameters (Section 5.2).  The Service Provider
   MUST ensure the Request Token cannot be exchanged for an Access Token
   until the User successfully grants access in Obtaining User
   Authorization (Section 6.2).

   The response contains the following parameters:

   oauth_token:  The Request Token.

   oauth_token_secret:  The Token Secret.

   Additional parameters:  Any additional parameters, as defined by the
      Service Provider.

   If the request fails verification or is rejected for other reasons,
   the Service Provider SHOULD respond with the appropriate response
   code as defined in HTTP Response Codes (Section 10).  The Service
   Provider MAY include some further details about why the request was
   rejected in the HTTP response body as defined in Service Provider
   Response Parameters (Section 5.2).

6.2.  Obtaining User Authorization

   The Consumer cannot use the Request Token until it has been
   authorized by the User.  Obtaining User authorization includes the
   following steps:

6.2.1.  Consumer Directs the User to the Service Provider

   In order for the Consumer to be able to exchange the Request Token
   for an Access Token, the Consumer MUST obtain approval from the User
   by directing the User to the Service Provider.  The Consumer
   constructs an HTTP GET request to the Service Provider's User



Hammer-Lahav & Cook       Expires April 3, 2009                [Page 10]

Internet-Draft        OAuth Authorization Protocol        September 2008


   Authorization URL with the following parameter:

   oauth_token:  OPTIONAL.  The Request Token obtained in the previous
      step.  The Service Provider MAY declare this parameter as
      REQUIRED, or accept requests to the User Authorization URL without
      it, in which case it will prompt the User to enter it manually.

   oauth_callback:  OPTIONAL.  The Consumer MAY specify a URL the
      Service Provider will use to redirect the User back to the
      Consumer when Obtaining User Authorization (Section 6.2) is
      complete.

   Additional parameters:  Any additional parameters, as defined by the
      Service Provider.

   Once the request URL has been constructed the Consumer redirects the
   User to the URL via the User's web browser.  If the Consumer is
   incapable of automatic HTTP redirection, the Consumer SHALL notify
   the User how to manually go to the constructed request URL.

   Note: If a Service Provider knows a Consumer to be running on a
   mobile device or set-top box, the Service Provider SHOULD ensure that
   the User Authorization URL and Request Token are suitable for manual
   entry.

6.2.2.  Service Provider Authenticates the User and Obtains Consent

   The Service Provider verifies the User's identity and asks for
   consent as detailed.  OAuth does not specify how the Service Provider
   authenticates the User.  However, it does define a set of REQUIRED
   steps:

   o  The Service Provider MUST first verify the User's identity before
      asking for consent.  It MAY prompt the User to sign in if the User
      has not already done so.

   o  The Service Provider presents to the User information about the
      Consumer requesting access (as registered by the Consumer
      Developer).  The information includes the duration of the access
      and the Protected Resources provided.  The information MAY include
      other details specific to the Service Provider.

   o  The User MUST grant or deny permission for the Service Provider to
      give the Consumer access to the Protected Resources on behalf of
      the User.  If the User denies the Consumer access, the Service
      Provider MUST NOT allow access to the Protected Resources.

   When displaying any identifying information about the Consumer to the



Hammer-Lahav & Cook       Expires April 3, 2009                [Page 11]

Internet-Draft        OAuth Authorization Protocol        September 2008


   User based on the Consumer Key, the Service Provider MUST inform the
   User if it is unable to assure the Consumer's true identity.  The
   method in which the Service Provider informs the User and the quality
   of the identity assurance is beyond the scope of this specification.

6.2.3.  Service Provider Directs the User Back to the Consumer

   After the User authenticates with the Service Provider and grants
   permission for Consumer access, the Consumer MUST be notified that
   the Request Token has been authorized and ready to be exchanged for
   an Access Token.  If the User denies access, the Consumer MAY be
   notified that the Request Token has been revoked.

   If the Consumer provided a callback URL in "oauth_callback" (as
   described in Consumer Directs the User to the Service Provider
   (Section 6.2.1)), the Service Provider constructs an HTTP GET request
   URL, and redirects the User's web browser to that URL with the
   following parameters:

   oauth_token:  The Request Token the User authorized or denied.

   The callback URL MAY include Consumer provided query parameters.  The
   Service Provider MUST retain them unmodified and append the
   "oauth_token" parameter to the existing query.

   If no callback URL was provided, the Service Provider instructs the
   User to manually inform the Consumer that authorization has
   completed.

6.3.  Obtaining an Access Token

   The Consumer exchanges the Request Token for an Access Token capable
   of accessing the Protected Resources.  Obtaining an Access Token
   includes the following steps:

6.3.1.  Consumer Requests an Access Token

   The Request Token and Token Secret MUST be exchanged for an Access
   Token and Token Secret.

   To request an Access Token, the Consumer makes an HTTP request to the
   Service Provider's Access Token URL.  The Service Provider
   documentation specifies the HTTP method for this request, and HTTP
   POST is RECOMMENDED.  The request MUST be signed per Signing Requests
   (Section 9), and contains the following parameters:






Hammer-Lahav & Cook       Expires April 3, 2009                [Page 12]

Internet-Draft        OAuth Authorization Protocol        September 2008


   oauth_consumer_key:  The Consumer Key.

   oauth_token:  The Request Token obtained previously.

   oauth_signature_method:  The signature method the Consumer used to
      sign the request.

   oauth_signature:  The signature as defined in Signing Requests
      (Section 9).

   oauth_timestamp:  As defined in Nonce and Timestamp (Section 8).

   oauth_nonce:  As defined in Nonce and Timestamp (Section 8).

   oauth_version:  OPTIONAL.  If present, value MUST be " 1.0 ".
      Service Providers MUST assume the protocol version to be "1.0" if
      this parameter is not present.  Service Providers' response to
      non-"1.0" value is left undefined.

   No additional Service Provider specific parameters are allowed when
   requesting an Access Token to ensure all Token related information is
   present prior to seeking User approval.

6.3.2.  Service Provider Grants an Access Token

   The Service Provider MUST ensure that:

   o  The request signature has been successfully verified.

   o  The Request Token has never been exchanged for an Access Token.

   o  The Request Token matches the Consumer Key.

   If successful, the Service Provider generates an Access Token and
   Token Secret and returns them in the HTTP response body as defined in
   Service Provider Response Parameters (Section 5.2).  The Access Token
   and Token Secret are stored by the Consumer and used when signing
   Protected Resources requests.  The response contains the following
   parameters:

   oauth_token:  The Access Token.

   oauth_token_secret:  The Token Secret.

   Additional parameters:  Any additional parameters, as defined by the
      Service Provider.

   If the request fails verification or is rejected for other reasons,



Hammer-Lahav & Cook       Expires April 3, 2009                [Page 13]

Internet-Draft        OAuth Authorization Protocol        September 2008


   the Service Provider SHOULD respond with the appropriate response
   code as defined in HTTP Response Codes (Section 10).  The Service
   Provider MAY include some further details about why the request was
   rejected in the HTTP response body as defined in Service Provider
   Response Parameters (Section 5.2).


7.  Accessing Protected Resources

   After successfully receiving the Access Token and Token Secret, the
   Consumer is able to access the Protected Resources on behalf of the
   User.  The request MUST be signed per Signing Requests (Section 9),
   and contains the following parameters:

   oauth_consumer_key:  The Consumer Key.

   oauth_token:  The Access Token.

   oauth_signature_method:  The signature method the Consumer used to
      sign the request.

   oauth_signature:  The signature as defined in Signing Requests
      (Section 9).

   oauth_timestamp:  As defined in Nonce and Timestamp (Section 8).

   oauth_nonce:  As defined in Nonce and Timestamp (Section 8).

   oauth_version:  OPTIONAL.  If present, value MUST be "1.0".  Service
      Providers MUST assume the protocol version to be "1.0" if this
      parameter is not present.  Service Providers' response to
      non-"1.0" value is left undefined.

   Additional parameters:  Any additional parameters, as defined by the
      Service Provider.


8.  Nonce and Timestamp

   Unless otherwise specified by the Service Provider, the timestamp is
   expressed in the number of seconds since January 1, 1970 00:00:00
   GMT.  The timestamp value MUST be a positive integer and MUST be
   equal or greater than the timestamp used in previous requests.

   The Consumer SHALL then generate a Nonce value that is unique for all
   requests with that timestamp, Consumer Key, and Token combination.  A
   nonce is a random string, uniquely generated for each request.  The
   nonce allows the Service Provider to verify that a request has never



Hammer-Lahav & Cook       Expires April 3, 2009                [Page 14]

Internet-Draft        OAuth Authorization Protocol        September 2008


   been made before and helps prevent replay attacks when requests are
   made over a non-secure channel (such as HTTP).


9.  Signing Requests

   All Token requests and Protected Resources requests MUST be signed by
   the Consumer and verified by the Service Provider.  The purpose of
   signing requests is to prevent unauthorized parties from using the
   Consumer Key and Tokens when making Token requests or Protected
   Resources requests.  The signature process encodes the Consumer
   Secret and Token Secret into a verifiable value which is included
   with the request.

   OAuth does not mandate a particular signature method, as each
   implementation can have its own unique requirements.  The protocol
   defines three signature methods: "HMAC-SHA1", "RSA-SHA1", and
   "PLAINTEXT", but Service Providers are free to implement and document
   their own methods.  Recommending any particular method is beyond the
   scope of this specification.

   The Consumer declares a signature method in the
   "oauth_signature_method" parameter, generates a signature, and stores
   it in the "oauth_signature" parameter.  The Service Provider verifies
   the signature as specified in each method.  When verifying a Consumer
   signature, the Service Provider SHOULD check the request nonce to
   ensure it has not been used in a previous Consumer request.

   The signature process MUST NOT change the request parameter names or
   values, with the exception of the "oauth_signature" parameter.

9.1.  Signature Base String

   The Signature Base String is a consistent reproducible concatenation
   of the request elements into a single string.  The string is used as
   an input in hashing or signing algorithms.  The "HMAC-SHA1" signature
   method provides both a standard and an example of using the Signature
   Base String with a signing algorithm to generate signatures.

9.1.1.  Parameter Encoding

   All parameter names and values MUST be encoded prior to constructing
   the Signature Base String.  The encoding process uses the parameters
   in their original decoded form.  It is essential that parameters are
   encoded in a certain way and need to be processed without any prior
   encoding.

   Text names and values are first encoded as UTF-8 octets per



Hammer-Lahav & Cook       Expires April 3, 2009                [Page 15]

Internet-Draft        OAuth Authorization Protocol        September 2008


   [RFC3629].  All parameter names and values are then escaped using the
   [RFC3986] percent-encoding (%XX) mechanism as follows:

   o  Characters not in the unreserved character set ([RFC3986] section
      2.3) MUST be encoded.

   o  Characters in the unreserved character set MUST NOT be encoded.

   o  Hexadecimal characters in encodings MUST be upper case.


                 unreserved = ALPHA, DIGIT, '-', '.', '_', '~'

9.1.2.  Normalize Request Parameters

   The request parameters are collected, sorted and concatenated into a
   normalized string:

   o  Parameters in the OAuth HTTP Authorization header (Section 5.3.1)
      excluding the "realm" parameter.

   o  Parameters in the HTTP POST request body (with a "content-type" of
      "application/x-www-form-urlencoded").

   o  Added to the URLs in the query part (as defined by [RFC3986]
      section 3).

   The "oauth_signature" parameter MUST be excluded.

   The parameters are normalized into a single string as follows:

   1.  Parameters are sorted by name, using lexicographical byte value
       ordering.  If two or more parameters share the same name, they
       are sorted by their value.  For example:

     a=1, c=hi%20there, f=25, f=50, f=a, z=p, z=t

   2.  Parameters are concatenated in their sorted order into a single
       string.  For each parameter, the name is separated from the
       corresponding value by an '=' character (ASCII code 61), even if
       the value is empty.  Each name-value pair is separated by an '&'
       character (ASCII code 38).  For example:

     a=1&c=hi%20there&f=25&f=50&f=a&z=p&z=t







Hammer-Lahav & Cook       Expires April 3, 2009                [Page 16]

Internet-Draft        OAuth Authorization Protocol        September 2008


9.1.3.  Construct Request URL

   The Signature Base String includes the request absolute URL, tying
   the signature to a specific endpoint.  The URL used in the Signature
   Base String MUST include the scheme, authority, and path, and MUST
   exclude the query and fragment as defined by [RFC3986] section 3.

   If the absolute request URL is not available to the Service Provider
   (it is always available to the Consumer), it can be constructed by
   combining the scheme being used, the HTTP "Host" header, and the
   relative HTTP request URL.  If the "Host" header is not available,
   the Service Provider SHOULD use the host name communicated to the
   Consumer in the documentation or other means.

   The Service Provider SHOULD document the form of URL used in the
   Signature Base String to avoid ambiguity due to URL normalization.
   Unless specified, URL scheme and authority MUST be lowercase and
   include the port number; "http" default port 80 and "https" default
   port 443 MUST be excluded.

   For example, the request:

     HTTP://Example.com:80/resource?id=123

   Is included in the Signature Base String as:

     http://example.com/resource

9.1.4.  Concatenate Request Elements

   The following items MUST be concatenated in order into a single
   string.  Each item is encoded (Section 9.1.1) and separated by an '&'
   character (ASCII code 38), even if empty.

   1.  The HTTP request method used to send the request.  Value MUST be
       uppercase, for example: "HEAD", " GET ", "POST", etc.

   2.  The request URL from Section 9.1.3.

   3.  The normalized request parameters string from Section 9.1.2.

   See Signature Base String example in Appendix A.5.1.

9.2.  HMAC-SHA1

   The "HMAC-SHA1" signature method uses the HMAC-SHA1 signature
   algorithm as defined in [RFC2104] where the Signature Base String is
   the "text" and the "key" is the concatenated values (each first



Hammer-Lahav & Cook       Expires April 3, 2009                [Page 17]

Internet-Draft        OAuth Authorization Protocol        September 2008


   encoded per Parameter Encoding (Section 9.1.1)) of the Consumer
   Secret and Token Secret, separated by an '&' character (ASCII code
   38) even if empty.

9.2.1.  Generating Signature

   "oauth_signature" is set to the calculated "digest" octet string,
   first base64-encoded per [RFC2045] section 6.8, then URL-encoded per
   Parameter Encoding (Section 9.1.1).

9.2.2.  Verifying Signature

   The Service Provider verifies the request by generating a new request
   signature octet string, and comparing it to the signature provided by
   the Consumer, first URL-decoded per Parameter Encoding
   (Section 9.1.1), then base64-decoded per [RFC2045] section 6.8.  The
   signature is generated using the request parameters as provided by
   the Consumer, and the Consumer Secret and Token Secret as stored by
   the Service Provider.

9.3.  RSA-SHA1

   The "RSA-SHA1" signature method uses the RSASSA-PKCS1-v1_5 signature
   algorithm as defined in [RFC3447] section 8.2 (more simply known as
   PKCS#1), using SHA-1 as the hash function for EMSA-PKCS1-v1_5.  It is
   assumed that the Consumer has provided its RSA public key in a
   verified way to the Service Provider, in a manner which is beyond the
   scope of this specification.

9.3.1.  Generating Signature

   The Signature Base String is signed using the Consumer's RSA private
   key per [RFC3447] section 8.2.1, where "K" is the Consumer's RSA
   private key, "M" the Signature Base String, and "S" is the result
   signature octet string:

     S = RSASSA-PKCS1-V1_5-SIGN (K, M)

   "oauth_signature" is set to "S", first base64-encoded per [RFC2045]
   section 6.8, then URL-encoded per Parameter Encoding (Section 9.1.1).

9.3.2.  Verifying Signature

   The Service Provider verifies the signature per [RFC3447] section
   8.2.2, where " (n, e) " is the Consumer's RSA public key, "M" is the
   Signature Base String, and "S" is the octet string representation of
   the "oauth_signature" value:




Hammer-Lahav & Cook       Expires April 3, 2009                [Page 18]

Internet-Draft        OAuth Authorization Protocol        September 2008


     RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)

9.4.  PLAINTEXT

   The " PLAINTEXT " method does not provide any security protection and
   SHOULD only be used over a secure channel such as HTTPS.  It does not
   use the Signature Base String.

9.4.1.  Generating Signature

   "oauth_signature" is set to the concatenated encoded values of the
   Consumer Secret and Token Secret, separated by a '&' character (ASCII
   code 38), even if either secret is empty.  The result MUST be encoded
   again.

   These examples show the value of "oauth_signature" for Consumer
   Secret "djr9rjt0jd78jf88" and 3 different Token Secrets:

   jjd999tj88uiths3:
      "oauth_signature"="djr9rjt0jd78jf88%26jjd999tj88uiths3"

   jjd99$tj88uiths3:
      "oauth_signature"="djr9rjt0jd78jf88%26jjd99%2524tj88uiths3"

   Empty:  "oauth_signature"="djr9rjt0jd78jf88%26"

9.4.2.  Verifying Signature

   The Service Provider verifies the request by breaking the signature
   value into the Consumer Secret and Token Secret, and ensures they
   match the secrets stored locally.


10.  HTTP Response Codes

   This section applies only to the Request Token and Access Token
   requests.  In general, the Service Provider SHOULD use the response
   codes defined in [RFC2616] Section 10.  When the Service Provider
   rejects a Consumer request, it SHOULD respond with HTTP 400 Bad
   Request or HTTP 401 Unauthorized.

   o  HTTP 400 Bad Request

      *  Unsupported parameter

      *  Unsupported signature method





Hammer-Lahav & Cook       Expires April 3, 2009                [Page 19]

Internet-Draft        OAuth Authorization Protocol        September 2008


      *  Missing required parameter

      *  Duplicated OAuth Protocol Parameter

   o  HTTP 401 Unauthorized

      *  Invalid Consumer Key

      *  Invalid / expired Token

      *  Invalid signature

      *  Invalid / used nonce


11.  IANA Considerations

   This memo includes no request to IANA.


12.  Security Considerations

12.1.  Credentials and Token Exchange

   The OAuth specification does not describe any mechanism for
   protecting Tokens and secrets from eavesdroppers when they are
   transmitted from the Service Provider to the Consumer in
   Section 6.1.2 and Section 6.3.2.  Service Providers should ensure
   that these transmissions are protected using transport-layer
   mechanisms such as TLS or SSL.

12.2.  RSA-SHA1 Signature Method

   When used with "RSA-SHA1" signatures, the OAuth protocol does not use
   the Consumer Secret and Token Secret.  This means the protocol relies
   completely on the secrecy of the Private Key used by the Consumer to
   sign requests.

12.3.  PLAINTEXT Signature Method

   When used with "PLAINTEXT" signatures, the OAuth protocol makes no
   attempts to protect User credentials from eavesdroppers or man-in-
   the-middle attacks.  The "PLAINTEXT" signature algorithm is only
   intended to be used in conjunction with a transport-layer security
   mechanism such as TLS or SSL which does provide such protection.  If
   transport-layer protection is unavailable, the "PLAINTEXT" signature
   method should not be used.




Hammer-Lahav & Cook       Expires April 3, 2009                [Page 20]

Internet-Draft        OAuth Authorization Protocol        September 2008


12.4.  Confidentiality of Requests

   While OAuth provides a mechanism for verifying the integrity of
   requests, it provides no guarantee of request confidentiality.
   Unless further precautions are taken, eavesdroppers will have full
   access to request content.  Service Providers should carefully
   consider the kinds of data likely to be sent as part of such
   requests, and should employ transport-layer security mechanisms to
   protect sensitive resources.

12.5.  Spoofing by Counterfeit Servers

   OAuth makes no attempt to verify the authenticity of the Service
   Provider.  A hostile party could take advantage of this by
   intercepting the Consumer's requests and returning misleading or
   otherwise incorrect responses.  Service providers should consider
   such attacks when developing services based on OAuth, and should
   require transport-layer security for any requests where the
   authenticity of the Service Provider or of request responses is an
   issue.

12.6.  Proxying and Caching of Authenticated Content

   The HTTP Authorization scheme (Section 5.3) is optional.  However,
   [RFC2616] relies on the "Authorization" and "WWW-Authenticate"
   headers to distinguish authenticated content so that it can be
   protected.  Proxies and caches, in particular, may fail to adequately
   protect requests not using these headers.

   For example, private authenticated content may be stored in (and thus
   retrievable from) publicly-accessible caches.  Service Providers not
   using the HTTP Authorization scheme (Section 5.3) should take care to
   use other mechanisms, such as the "Cache-Control" header, to ensure
   that authenticated content is protected.

12.7.  Plaintext Storage of Credentials

   The Consumer Secret and Token Secret function the same way passwords
   do in traditional authentication systems.  In order to compute the
   signatures used in the non-"PLAINTEXT" methods, the Service Provider
   must have access to these secrets in plaintext form.  This is in
   contrast, for example, to modern operating systems, which store only
   a one-way hash of user credentials.

   If an attacker were to gain access to these secrets - or worse, to
   the Service Provider's database of all such secrets - he or she would
   be able to perform any action on behalf of any User.  Accordingly, it
   is critical that Service Providers protect these secrets from



Hammer-Lahav & Cook       Expires April 3, 2009                [Page 21]

Internet-Draft        OAuth Authorization Protocol        September 2008


   unauthorized access.

12.8.  Secrecy of the Consumer Secret

   In many applications, the Consumer application will be under the
   control of potentially untrusted parties.  For example, if the
   Consumer is a freely available desktop application, an attacker may
   be able to download a copy for analysis.  In such cases, attackers
   will be able to recover the Consumer Secret used to authenticate the
   Consumer to the Service Provider.

   Accordingly, Service Providers should not use the Consumer Secret
   alone to verify the identity of the Consumer.  Where possible, other
   factors such as IP address should be used as well.

12.9.  Phishing Attacks

   Wide deployment of OAuth and similar protocols may cause Users to
   become inured to the practice of being redirected to websites where
   they are asked to enter their passwords.  If Users are not careful to
   verify the authenticity of these websites before entering their
   credentials, it will be possible for attackers to exploit this
   practice to steal Users' passwords.

   Service Providers should attempt to educate Users about the risks
   phishing attacks pose, and should provide mechanisms that make it
   easy for Users to confirm the authenticity of their sites.

12.10.  Scoping of Access Requests

   By itself, OAuth does not provide any method for scoping the access
   rights granted to a Consumer.  A Consumer either has access to
   Protected Resources or it doesn't.  Many applications will, however,
   require greater granularity of access rights.  For example, Service
   Providers may wish to make it possible to grant access to some
   Protected Resources but not others, or to grant only limited access
   (such as read-only access) to those Protected Resources.

   When implementing OAuth, Service Providers should consider the types
   of access Users may wish to grant Consumers, and should provide
   mechanisms to do so.  Service Providers should also take care to
   ensure that Users understand the access they are granting, as well as
   any risks that may be involved.

12.11.  Entropy of Secrets

   Unless a transport-layer security protocol is used, eavesdroppers
   will have full access to OAuth requests and signatures, and will thus



Hammer-Lahav & Cook       Expires April 3, 2009                [Page 22]

Internet-Draft        OAuth Authorization Protocol        September 2008


   be able to mount offline brute-force attacks to recover the
   Consumer's credentials used.  Service Providers should be careful to
   assign Token Secrets and Consumer Secrets which are long enough - and
   random enough - to resist such attacks for at least the length of
   time that the secrets are valid.

   For example, if Token Secrets are valid for two weeks, Service
   Providers should ensure that it is not possible to mount a brute
   force attack that recovers the Token Secret in less than two weeks.
   Of course, Service Providers are urged to err on the side of caution,
   and use the longest secrets reasonable.

   It is equally important that the pseudo-random number generator
   (PRNG) used to generate these secrets be of sufficiently high
   quality.  Many PRNG implementations generate number sequences that
   may appear to be random, but which nevertheless exhibit patterns or
   other weaknesses which make cryptanalysis or brute force attacks
   easier.  Implementors should be careful to use cryptographically
   secure PRNGs to avoid these problems.

12.12.  Denial of Service / Resource Exhaustion Attacks

   The OAuth protocol has a number of features which may make resource
   exhaustion attacks against Service Providers possible.  For example,
   if a Service Provider includes a nontrivial amount of entropy in
   Token Secrets as recommended above, then an attacker may be able to
   exhaust the Service Provider's entropy pool very quickly by
   repeatedly obtaining Request Tokens from the Service Provider.

   Similarly, OAuth requires Service Providers to track used nonces.  If
   an attacker is able to use many nonces quickly, the resources
   required to track them may exhaust available capacity.  And again,
   OAuth can require Service Providers to perform potentially expensive
   computations in order to verify the signature on incoming requests.
   An attacker may exploit this to perform a denial of service attack by
   sending a large number of invalid requests to the Service Provider.

   Resource Exhaustion attacks are by no means specific to OAuth.
   However, OAuth implementors should be careful to consider the
   additional avenues of attack that OAuth exposes, and design their
   implementations accordingly.  For example, entropy starvation
   typically results in either a complete denial of service while the
   system waits for new entropy or else in weak (easily guessable)
   secrets.  When implementing OAuth, Service Providers should consider
   which of these presents a more serious risk for their application and
   design accordingly.





Hammer-Lahav & Cook       Expires April 3, 2009                [Page 23]

Internet-Draft        OAuth Authorization Protocol        September 2008


12.13.  Cryptographic Attacks

   SHA-1, the hash algorithm used in "HMAC-SHA1" signatures, has been
   shown [SHA1-CHARACTERISTICS] to have a number of cryptographic
   weaknesses that significantly reduce its resistance to collision
   attacks.  Practically speaking, these weaknesses are difficult to
   exploit, and by themselves do not pose a significant risk to users of
   OAuth.  They may, however, make more efficient attacks possible, and
   NIST has announced [SHA-COMMENTS] that it will phase out use of SHA-1
   by 2010.  Service Providers should take this into account when
   considering whether SHA-1 provides an adequate level of security for
   their applications.

12.14.  Signature Base String Compatibility

   The Signature Base String has been designed to support the signature
   methods defined in this specification.  When designing additional
   signature methods, the Signature Base String should be evaluated to
   ensure compatibility with the algorithms used.

   The Signature Base String cannot guarantee the order in which
   parameters are sent.  If parameter ordering is important and affects
   the result of a request, the Signature Base String will not protect
   against request manipulation.


Appendix A.  Appendix A - Protocol Example

   In this example, the Service Provider photos.example.net is a photo
   sharing website, and the Consumer printer.example.com is a photo
   printing website.  Jane, the User, would like printer.example.com to
   print the private photo " vacation.jpg " stored at
   photos.example.net.

   When Jane signs-into photos.example.net using her username and
   password, she can access the photo by going to the URL
   "http://photos.example.net/photo?file=vacation.jpg".  Other Users
   cannot access that photo, and Jane does not want to share her
   username and password with printer.example.com.

   The requests in this example use the URL query method when sending
   parameters.  This is done to simplify the example and should not be
   taken as an endorsement of one method over the others.

Appendix A.1.  Documentation and Registration

   The Service Provider documentation explains how to register for a
   Consumer Key and Consumer Secret, and declares the following URLs:



Hammer-Lahav & Cook       Expires April 3, 2009                [Page 24]

Internet-Draft        OAuth Authorization Protocol        September 2008


   Request Token URL:  https://photos.example.net/request_token, using
      HTTP POST

   User Authorization URL:  http://photos.example.net/authorize, using
      HTTP GET

   Access Token URL:  https://photos.example.net/access_token, using
      HTTP POST

   Photo (Protected Resource) URL:  http://photos.example.net/photo with
      required parameter "file" and optional parameter "size"

   The Service Provider declares support for the " HMAC-SHA1 " signature
   method for all requests, and "PLAINTEXT" only for secure (HTTPS)
   requests.

   The Consumer printer.example.com already established a Consumer Key
   and Consumer Secret with photos.example.net and advertizes its
   printing services for photos stored on photos.example.net.  The
   Consumer registration is:

   Consumer Key:  " dpf43f3p2l4k3l03 "

   Consumer Secret:  "kd94hf93k423kf44"

Appendix A.2.  Obtaining a Request Token

   After Jane informs printer.example.com that she would like to print
   her vacation photo stored at photos.example.net, the printer website
   tries to access the photo and receives HTTP 401 Unauthorized
   indicating it is private.  The Service Provider includes the
   following header with the response:

     WWW-Authenticate: OAuth realm="http://photos.example.net/"

   The Consumer sends the following HTTP POST request to the Service
   Provider:

   https://photos.example.net/request_token?
   oauth_consumer_key=dpf43f3p2l4k3l03&oauth_signature_method=PLAINTEXT&
   oauth_signature=kd94hf93k423kf44%26&oauth_timestamp=1191242090&
   oauth_nonce=hsu94j3884jdopsl&oauth_version=1.0

   The Service Provider checks the signature and replies with an
   unauthorized Request Token in the body of the HTTP response:

     oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03




Hammer-Lahav & Cook       Expires April 3, 2009                [Page 25]

Internet-Draft        OAuth Authorization Protocol        September 2008


Appendix A.3.  Requesting User Authorization

   The Consumer redirects Jane's browser to the Service Provider User
   Authorization URL to obtain Jane's approval for accessing her private
   photos.

   http://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola&
   oauth_callback=http%3A%2F%2Fprinter.example.com%2Frequest_token_ready

   The Service Provider asks Jane to sign-in using her username and
   password and, if successful, asks her if she approves granting
   printer.example.com access to her private photos.  If Jane approves
   the request, the Service Provider redirects her back to the
   Consumer's callback URL:

     http://printer.example.com/request_token_ready?
     oauth_token=hh5s93j4hdidpola

Appendix A.4.  Obtaining an Access Token

   Now that the Consumer knows Jane approved the Request Token, it asks
   the Service Provider to exchange it for an Access Token:

     https://photos.example.net/access_token?
     oauth_consumer_key=dpf43f3p2l4k3l03&
     oauth_token=hh5s93j4hdidpola&oauth_signature_method=PLAINTEXT&
     oauth_signature=kd94hf93k423kf44%26hdhd0244k9j7ao03&
     oauth_timestamp=1191242092&
     oauth_nonce=dji430splmx33448&oauth_version=1.0

   The Service Provider checks the signature and replies with an Access
   Token in the body of the HTTP response:

     oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00

Appendix A.5.  Accessing Protected Resources

   The Consumer is now ready to request the private photo.  Since the
   photo URL is not secure (HTTP), it must use "HMAC-SHA1".

Appendix A.5.1.  Generating Signature Base String

   To generate the signature, it first needs to generate the Signature
   Base String.  The request contains the following parameters
   ("oauth_signature" excluded) which are ordered and concatenated into
   a normalized string:





Hammer-Lahav & Cook       Expires April 3, 2009                [Page 26]

Internet-Draft        OAuth Authorization Protocol        September 2008


   oauth_consumer_key:  "dpf43f3p2l4k3l03"

   oauth_token:  "nnch734d00sl2jdk"

   oauth_signature_method:  "HMAC-SHA1"

   oauth_timestamp:  "1191242096"

   oauth_nonce:  "kllo9940pd9333jh"

   oauth_version:  "1.0"

   file:  "vacation.jpg"

   size:  "original"

   The following inputs are used to generate the Signature Base String:

   1.  "GET"

   2.  "http://photos.example.net/photos"

   3.  "file=vacation.jpg&oauth_consumer_key=dpf43f3p2l4k3l03&oauth_nonc
       e=kllo9940pd9333jh&oauth_signature_method=HMAC-SHA1&oauth_timesta
       mp=1191242096&oauth_token=nnch734d00sl2jdk&oauth_version=1.0&size
       =original"

   The Signature Base String is:

  GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26
  oauth_consumer_key%3Ddpf43f3p2l4k3l03%26
  oauth_nonce%3Dkllo9940pd9333jh%26
  oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26
  oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal

Appendix A.5.2.  Calculating Signature Value

   HMAC-SHA1 produces the following "digest" value as a base64-encoded
   string (using the Signature Base String as "text" and "
   kd94hf93k423kf44&pfkkdhi9sl3r4s00 " as "key"):

     tR3+Ty81lMeYAr/Fid0kMTYa/WM=

Appendix A.5.3.  Requesting Protected Resource

   All together, the Consumer request for the photo is:





Hammer-Lahav & Cook       Expires April 3, 2009                [Page 27]

Internet-Draft        OAuth Authorization Protocol        September 2008


     http://photos.example.net/photos?file=vacation.jpg&size=original

     Authorization: OAuth realm="http://photos.example.net/",
     oauth_consumer_key="dpf43f3p2l4k3l03",
     oauth_token="nnch734d00sl2jdk",
     oauth_signature_method="HMAC-SHA1",
     oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D",
     oauth_timestamp="1191242096",
     oauth_nonce="kllo9940pd9333jh",
     oauth_version="1.0"

   And if using query parameters:

     http://photos.example.net/photos?file=vacation.jpg&size=original&
     oauth_consumer_key=dpf43f3p2l4k3l03&oauth_token=nnch734d00sl2jdk&
     oauth_signature_method=HMAC-SHA1&
     oauth_signature=tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D&
     oauth_timestamp=1191242096&
     oauth_nonce=kllo9940pd9333jh&oauth_version=1.0

   photos.example.net checks the signature and responds with the
   requested photo.


Appendix B.  Contributors

   The content and concepts within are a product of the OAuth community.
   It has been originally published as the [OAuth Core 1.0] community
   specification and was authored by:

      Mark Atwood (me@mark.atwood.name)

      Richard M. Conlan (zeveck@google.com)

      Blaine Cook (romeda@gmail.com)

      Leah Culver (leah@pownce.com)

      Kellan Elliott-McCrea (kellan@flickr.com)

      Larry Halff (larry@ma.gnolia.com)

      Eran Hammer-Lahav (eran@hueniverse.com)

      Ben Laurie (benl@google.com)

      Chris Messina (chris@citizenagency.com)




Hammer-Lahav & Cook       Expires April 3, 2009                [Page 28]

Internet-Draft        OAuth Authorization Protocol        September 2008


      John Panzer (jpanzer@acm.org)

      Sam Quigley (quigley@emerose.com)

      David Recordon (david@sixapart.com)

      Eran Sandler (eran@yedda.com)

      Jonathan Sergent (sergent@google.com)

      Todd Sieling (todd@ma.gnolia.com)

      Brian Slesinsky (brian-oauth@slesinsky.org)

      Andy Smith (andy@jaiku.com)


13.  References

13.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A., and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.




Hammer-Lahav & Cook       Expires April 3, 2009                [Page 29]

Internet-Draft        OAuth Authorization Protocol        September 2008


   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [W3C.REC-html40-19980424]
              Raggett, D., Jacobs, I., and A. Hors, "HTML 4.0
              Specification", World Wide Web Consortium
              Recommendation REC-html40-19980424, April 1998,
              <http://www.w3.org/TR/1998/REC-html40-19980424>.

13.2.  Informative References

   [OAuth Core 1.0]
              OAuth, OCW., "OAuth Core 1.0".

   [SHA-COMMENTS]
              National Institute of Standards and Technolog, NIST.,
              "NIST Brief Comments on Recent Cryptanalytic Attacks on
              Secure Hashing Functions and the Continued Security
              Provided by SHA-1, August, 2004.".

   [SHA1-CHARACTERISTICS]
              De Canniere, C. and C. Rechberger, "Finding SHA-1
              Characteristics: General Results and Applications".


Authors' Addresses

   Eran Hammer-Lahav (editor)

   Email: eran@hueniverse.com
   URI:   http://hueniverse.com


   Blaine Cook

   Email: romeda@gmail.com
   URI:   http://romeda.org/













Hammer-Lahav & Cook       Expires April 3, 2009                [Page 30]

Internet-Draft        OAuth Authorization Protocol        September 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Hammer-Lahav & Cook       Expires April 3, 2009                [Page 31]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/