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".
[]
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]
