diff options
| author | Andrew Arnott <andrewarnott@gmail.com> | 2009-02-01 21:16:38 -0800 |
|---|---|---|
| committer | Andrew Arnott <andrewarnott@gmail.com> | 2009-02-01 21:16:38 -0800 |
| commit | cb11568e9f265ed675848d8290cad6cb842b7b05 (patch) | |
| tree | d97007d561ab99a434b79d01fbcabba66e8673f8 /doc/specs | |
| parent | cab7574242cbd7a054b56ebd322f0cce560de912 (diff) | |
| download | DotNetOpenAuth-cb11568e9f265ed675848d8290cad6cb842b7b05.zip DotNetOpenAuth-cb11568e9f265ed675848d8290cad6cb842b7b05.tar.gz DotNetOpenAuth-cb11568e9f265ed675848d8290cad6cb842b7b05.tar.bz2 | |
Whitespace
Diffstat (limited to 'doc/specs')
| -rw-r--r-- | doc/specs/OAuth Core 1.0.htm | 4872 |
1 files changed, 2436 insertions, 2436 deletions
diff --git a/doc/specs/OAuth Core 1.0.htm b/doc/specs/OAuth Core 1.0.htm index 6a9857e..eab3602 100644 --- a/doc/specs/OAuth Core 1.0.htm +++ b/doc/specs/OAuth Core 1.0.htm @@ -1,2438 +1,2438 @@ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml" lang="en"><head>
-<title>OAuth Core 1.0</title>
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<meta name="description" content="OAuth Core 1.0">
-<style type="text/css">
- body {
- font-family: "lucida grande", verdana, arial, helvetica, sans-serif;
- font-size: 83%; color: #000; background-color: #FFF;
- margin: 2em;
- }
- h1, h2, h3, h4, h5, h6 {
- font-family: helvetica neue, arial, "MS Sans Serif", sans-serif;
- font-weight: bold; font-style: normal;
- }
- h1 { color: #111; background-color: transparent; padding-bottom: 2px; border-bottom: 4px solid #efefef; }
- h3 { color: #333; background-color: transparent; }
-
-
- td.header {
- font-family: arial, helvetica, sans-serif; font-size: x-small;
- vertical-align: top; width: 33%;
- color: #FFF; background-color: #666;
- }
- td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
- td.author-text { font-size: x-small; }
-
- /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
- a.info {
- /* This is the key. */
- position: relative;
- z-index: 24;
- }
- a.info:hover {
- z-index: 25;
- color: #FFF; background-color: #369;
- text-decoration: none;
- }
- a.info span { display: none; }
- a.info:hover span.info {
- /* The span will display just on :hover state. */
- display: block;
- position: absolute;
- font-size: smaller;
- top: 2em; left: -5em; width: 15em;
- padding: 2px; border: 1px solid #333;
- color: #369; background-color: #EEE;
- text-align: left;
- }
-
- a { font-weight: bold; }
- a:link { color: #369; background-color: transparent; }
- a:visited { color: #666; background-color: transparent; }
- a:active { color: #888; background-color: transparent; }
-
- p { margin-left: 2em; margin-right: 2em; }
- p.copyright { font-size: x-small; }
- p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
- table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
- td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
-
- ol.text { margin-left: 1em; margin-right: 2em; }
- ul.text { margin-left: 1em; margin-right: 2em; }
- li { margin-left: 1em; padding-left: 1.2em; }
-
- /* RFC-2629 <spanx>s and <artwork>s. */
- em { font-style: italic; }
- strong { font-weight: bold; }
- dfn { font-weight: bold; font-style: normal; }
- cite { font-weight: normal; font-style: normal; }
- tt { color: #036; }
- tt, pre, pre dfn, pre em, pre cite, pre span {
- font-family: "Courier New", Courier, monospace; font-size: small;
- }
- pre {
- text-align: left; padding: 4px;
- color: #000; background-color: #f7f7f7;
- width: auto;
- }
- pre dfn { color: #369; }
- pre em { color: #66F; background-color: #FFC; font-weight: normal; }
- pre .key { color: #33C; font-weight: bold; }
- pre .id { color: #369; }
- pre .str { color: #000; background-color: #CFF; }
- pre .val { color: #066; }
- pre .rep { color: #909; }
- pre .oth { color: #000; background-color: #FCF; }
- pre .err { background-color: #FCC; }
-
- /* RFC-2629 <texttable>s. */
- table.all, table.full, table.headers, table.none {
- font-size: small; text-align: center; border-width: 2px;
- vertical-align: top; border-collapse: collapse;
- }
- table.all, table.full { border-style: solid; border-color: black; }
- table.headers, table.none { border-style: none; }
- th {
- font-weight: bold; border-color: #000;
- border-width: 2px 2px 3px 2px;
- }
- table.all th, table.full th { border-style: solid; }
- table.headers th { border-style: none none solid none; }
- table.none th { border-style: none; }
- table.all td {
- border-style: solid; border-color: #333;
- border-width: 1px 2px;
- }
- table.full td, table.headers td, table.none td { border-style: none; }
-
- hr { height: 1px; border:1px solid #e7e7e7; background-color:#e7e7e7;}
- hr.insert {
- width: 80%; border-style: none; border-width: 0;
- color: #CCC; background-color: #CCC;
- }
-</style>
-</head><body>
-<p><span style="float: right;">December 4, 2007</span></p>
-
-<h1><br>OAuth Core 1.0</h1>
-
-<h3>Abstract</h3>
-
-<p>
- 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.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p>
- 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.
-
-</p><a name="toc"></a><br><hr>
-<h3>Table of Contents</h3>
-<p class="toc">
-<a href="#anchor1">1.</a>
-Authors<br>
-<a href="#anchor2">2.</a>
-Notation and Conventions<br>
-<a href="#anchor3">3.</a>
-Definitions<br>
-<a href="#anchor4">4.</a>
-Documentation and Registration<br>
- <a href="#request_urls">4.1.</a>
-Request URLs<br>
- <a href="#anchor5">4.2.</a>
-Service Providers<br>
- <a href="#anchor6">4.3.</a>
-Consumers<br>
-<a href="#anchor7">5.</a>
-Parameters<br>
- <a href="#encoding_parameters">5.1.</a>
-Parameter Encoding<br>
- <a href="#consumer_req_param">5.2.</a>
-Consumer Request Parameters<br>
- <a href="#response_parameters">5.3.</a>
-Service Provider Response Parameters<br>
- <a href="#auth_header">5.4.</a>
-OAuth HTTP Authorization Scheme<br>
-<a href="#anchor9">6.</a>
-Authenticating with OAuth<br>
- <a href="#auth_step1">6.1.</a>
-Obtaining an Unauthorized Request Token<br>
- <a href="#auth_step2">6.2.</a>
-Obtaining User Authorization<br>
- <a href="#auth_step3">6.3.</a>
-Obtaining an Access Token<br>
-<a href="#anchor13">7.</a>
-Accessing Protected Resources<br>
-<a href="#nonce">8.</a>
-Nonce and Timestamp<br>
-<a href="#signing_process">9.</a>
-Signing Requests<br>
- <a href="#anchor14">9.1.</a>
-Signature Base String<br>
- <a href="#anchor16">9.2.</a>
-HMAC-SHA1<br>
- <a href="#anchor19">9.3.</a>
-RSA-SHA1<br>
- <a href="#anchor22">9.4.</a>
-PLAINTEXT<br>
-<a href="#http_codes">10.</a>
-HTTP Response Codes<br>
-<a href="#anchor25">Appendix A.</a>
-Appendix A - Protocol Example<br>
-<a href="#anchor26">Appendix A.1.</a>
-Documentation and Registration<br>
-<a href="#anchor27">Appendix A.2.</a>
-Obtaining a Request Token<br>
-<a href="#anchor28">Appendix A.3.</a>
-Requesting User Authorization<br>
-<a href="#anchor29">Appendix A.4.</a>
-Obtaining an Access Token<br>
-<a href="#anchor30">Appendix A.5.</a>
-Accessing Protected Resources<br>
-<a href="#anchor33">Appendix B.</a>
-Security Considerations<br>
-<a href="#anchor34">Appendix B.1.</a>
-Credentials and Token Exchange<br>
-<a href="#anchor35">Appendix B.2.</a>
-PLAINTEXT Signature Method<br>
-<a href="#anchor36">Appendix B.3.</a>
-Confidentiality of Requests<br>
-<a href="#anchor37">Appendix B.4.</a>
-Spoofing by Counterfeit Servers<br>
-<a href="#anchor38">Appendix B.5.</a>
-Proxying and Caching of Authenticated Content<br>
-<a href="#anchor39">Appendix B.6.</a>
-Plaintext Storage of Credentials<br>
-<a href="#anchor40">Appendix B.7.</a>
-Secrecy of the Consumer Secret<br>
-<a href="#anchor41">Appendix B.8.</a>
-Phishing Attacks<br>
-<a href="#anchor42">Appendix B.9.</a>
-Scoping of Access Requests<br>
-<a href="#anchor43">Appendix B.10.</a>
-Entropy of Secrets<br>
-<a href="#anchor44">Appendix B.11.</a>
-Denial of Service / Resource Exhaustion Attacks<br>
-<a href="#anchor45">Appendix B.12.</a>
-Cryptographic Attacks<br>
-<a href="#anchor46">Appendix B.13.</a>
-Signature Base String Compatibility<br>
-<a href="#rfc.references1">11.</a>
-References<br>
-<a href="#rfc.authors">§</a>
-Author’s Address<br>
-</p>
-
-<p><br clear="all"></p>
-
-<p><a name="anchor1"></a><br></p><hr>
-
-<p><a name="rfc.section.1"></a></p><h3>1.
-Authors</h3>
-
-<ul>
- <li><span class="vcard"><span class="fn">Mark Atwood</span> (<span class="email">me@mark.atwood.name</span>)</span></li>
- <li><span class="vcard"><span class="fn">Richard M. Conlan</span> (<span class="email">zeveck@google.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">Blaine Cook</span> (<span class="email">blaine@twitter.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">Leah Culver</span> (<span class="email">leah@pownce.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">Kellan Elliott-McCrea</span> (<span class="email">kellan@flickr.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">Larry Halff</span> (<span class="email">larry@ma.gnolia.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">Eran Hammer-Lahav</span> (<span class="email">eran@hueniverse.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">Ben Laurie</span> (<span class="email">benl@google.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">Chris Messina</span> (<span class="email">chris@citizenagency.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">John Panzer</span> (<span class="email">jpanzer@acm.org</span>)</span></li>
- <li><span class="vcard"><span class="fn">Sam Quigley</span> (<span class="email">quigley@emerose.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">David Recordon</span> (<span class="email">david@sixapart.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">Eran Sandler</span> (<span class="email">eran@yedda.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">Jonathan Sergent</span> (<span class="email">sergent@google.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">Todd Sieling</span> (<span class="email">todd@ma.gnolia.com</span>)</span></li>
- <li><span class="vcard"><span class="fn">Brian Slesinsky</span> (<span class="email">brian-oauth@slesinsky.org</span>)</span></li>
- <li><span class="vcard"><span class="fn">Andy Smith</span> (<span class="email">andy@jaiku.com</span>)</span></li>
-</ul>
-
-<p><a name="anchor2"></a><br></p><hr>
-
-<p><a name="rfc.section.2"></a></p><h3>2.
-Notation and Conventions</h3>
-
-<p>
- 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 <a class="info" href="#RFC2119">[RFC2119]<span> (</span><span class="info">Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .</span><span>)</span></a>.
- Domain name examples use <a class="info" href="#RFC2606">[RFC2606]<span> (</span><span class="info">Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” .</span><span>)</span></a>.
-
-</p>
-
-<p><a name="anchor3"></a><br></p><hr>
-
-<p><a name="rfc.section.3"></a></p><h3>3.
-Definitions</h3>
-
-<p>
- </p>
-<blockquote class="text"><dl>
-<dt>Service Provider:</dt>
-<dd>
- A web application that allows access via OAuth.
-
-</dd>
-<dt>User:</dt>
-<dd>
- An individual who has an account with the Service Provider.
-
-</dd>
-<dt>Consumer:</dt>
-<dd>
- A website or application that uses OAuth to access the Service
- Provider on behalf of the User.
-
-</dd>
-<dt>Protected Resource(s):</dt>
-<dd>
- Data controlled by the Service Provider, which the Consumer can
- access through authentication.
-
-</dd>
-<dt>Consumer Developer:</dt>
-<dd>
- An individual or organization that implements a Consumer.
-
-</dd>
-<dt>Consumer Key:</dt>
-<dd>
- A value used by the Consumer to identify itself to the Service
- Provider.
-
-</dd>
-<dt>Consumer Secret:</dt>
-<dd>
- A secret used by the Consumer to establish ownership of the
- Consumer Key.
-
-</dd>
-<dt>Request Token:</dt>
-<dd>
- A value used by the Consumer to obtain authorization from the User,
- and exchanged for an Access Token.
-
-</dd>
-<dt>Access Token:</dt>
-<dd>
- 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.
-
-</dd>
-<dt>Token Secret:</dt>
-<dd>
- A secret used by the Consumer to establish ownership of a given
- Token.
-
-</dd>
-<dt>OAuth Protocol Parameters:</dt>
-<dd>
- Parameters with names beginning with <tt>oauth_</tt>.
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p><a name="anchor4"></a><br></p><hr>
-
-<p><a name="rfc.section.4"></a></p><h3>4.
-Documentation and Registration</h3>
-
-<p>
- OAuth includes a Consumer Key and matching Consumer Secret that
- together authenticate the Consumer (as opposed to the User) to the
- Service Provider. Consumer-specific identification allows the Service
- Provider to vary access levels to Consumers (such as un-throttled access
- to resources).
-
-</p>
-
-<p>
- 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).
-
-</p>
-
-<p><a name="request_urls"></a><br></p><hr>
-
-<p><a name="rfc.section.4.1"></a></p><h3>4.1.
-Request URLs</h3>
-
-<p>
- OAuth defines three request URLs:
-
- </p>
-<blockquote class="text"><dl>
-<dt>Request Token URL:</dt>
-<dd>
- The URL used to obtain an unauthorized Request Token, described
- in <a class="info" href="#auth_step1">Section 6.1<span> (</span><span class="info">Obtaining an Unauthorized Request Token</span><span>)</span></a>.
-
-</dd>
-<dt>User Authorization URL:</dt>
-<dd>
- The URL used to obtain User authorization for Consumer access,
- described in <a class="info" href="#auth_step2">Section 6.2<span> (</span><span class="info">Obtaining User Authorization</span><span>)</span></a>.
-
-</dd>
-<dt>Access Token URL:</dt>
-<dd>
- The URL used to exchange the User-authorized Request Token for
- an Access Token, described in <a class="info" href="#auth_step3">Section 6.3<span> (</span><span class="info">Obtaining an Access Token</span><span>)</span></a>.
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p>
- The three URLs MUST include scheme, authority, and path, and MAY
- include query and fragment as defined by <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a>
- section 3. The request URL query MUST NOT contain any OAuth Protocol
- Parameters. For example:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> http://sp.example.com/authorize
-</pre></div><p>
-
-
-</p>
-
-<p><a name="anchor5"></a><br></p><hr>
-
-<p><a name="rfc.section.4.2"></a></p><h3>4.2.
-Service Providers</h3>
-
-<p>
- 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.
-
-</p>
-
-<p>
- The Service Provider’s documentation includes:
-
- </p>
-<ol class="text">
-<li>
- The <a class="info" href="#request_urls">URLs<span> (</span><span class="info">Request URLs</span><span>)</span></a> 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.
-
-</li>
-<li>
- Signature methods supported by the Service Provider.
-
-</li>
-<li>
- Any additional request parameters that the Service Provider
- requires in order to obtain a Token. Service Provider specific
- parameters MUST NOT begin with <tt>oauth_</tt>.
-
-</li>
-</ol><p>
-
-</p>
-
-<p><a name="anchor6"></a><br></p><hr>
-
-<p><a name="rfc.section.4.3"></a></p><h3>4.3.
-Consumers</h3>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="anchor7"></a><br></p><hr>
-
-<p><a name="rfc.section.5"></a></p><h3>5.
-Parameters</h3>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="encoding_parameters"></a><br></p><hr>
-
-<p><a name="rfc.section.5.1"></a></p><h3>5.1.
-Parameter Encoding</h3>
-
-<p>
- All parameter names and values are escaped using the
- <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> percent-encoding (%xx) mechanism.
- Characters not in the unreserved character set
- (<a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> section 2.3) MUST be encoded. Characters
- in the unreserved character set MUST NOT be encoded. Hexadecimal
- characters in encodings MUST be upper case. Text names and values
- MUST be encoded as UTF-8 octets before percent-encoding them per
- <a class="info" href="#RFC3629">[RFC3629]<span> (</span><span class="info">Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .</span><span>)</span></a>.
-
-</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> unreserved = ALPHA, DIGIT, '-', '.', '_', '~'
-</pre></div>
-<a name="consumer_req_param"></a><br><hr>
-
-<a name="rfc.section.5.2"></a><h3>5.2.
-Consumer Request Parameters</h3>
-
-<p>
- OAuth Protocol Parameters are sent from the Consumer to the Service
- Provider in one of three methods, in order of decreasing preference:
- </p>
-<ol class="text">
-<li>
- In the HTTP <tt>Authorization</tt> header as defined in
- <a class="info" href="#auth_header">OAuth HTTP Authorization Scheme<span> (</span><span class="info">OAuth HTTP Authorization Scheme</span><span>)</span></a>.
-
-</li>
-<li>
- As the HTTP POST request body with a <tt>
- content-type
- </tt> of
- <tt>application/x-www-form-urlencoded</tt>.
-
-</li>
-<li>
- Added to the URLs in the query part (as defined by
- <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> section 3).
-
-</li>
-</ol><p>
-
-</p>
-
-<p>
- 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
- <a class="info" href="#auth_header">OAuth HTTP Authorization Scheme<span> (</span><span class="info">OAuth HTTP Authorization Scheme</span><span>)</span></a> header.
-
-</p>
-
-<p><a name="response_parameters"></a><br></p><hr>
-
-<p><a name="rfc.section.5.3"></a></p><h3>5.3.
-Service Provider Response Parameters</h3>
-
-<p>
- Response parameters are sent by the Service
- Provider to return Tokens and other information to the Consumer in
- the HTTP response body. The parameter names and values are first
- encoded as per <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>, and concatenated with the ‘&’ character (ASCII code 38)
- as defined in <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> Section 2.1. For example:
-
-</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b
-</pre></div>
-<a name="auth_header"></a><br><hr>
-
-<a name="rfc.section.5.4"></a><h3>5.4.
-OAuth HTTP Authorization Scheme</h3>
-
-<p>
- This section defines an <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks,
-J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen,
-A., and L. Stewart, “HTTP Authentication: Basic and Digest Access
-Authentication,” .</span><span>)</span></a> extension to
- support OAuth. It uses the standard HTTP <tt>Authorization</tt> and
- <tt>WWW-Authenticate</tt> headers to pass OAuth Protocol Parameters.
-
-</p>
-
-<p>
- It is RECOMMENDED that Service Providers accept the HTTP
- <tt>Authorization</tt> header. Consumers SHOULD be able to send OAuth
- Protocol Parameters in the OAuth <tt>Authorization</tt> header.
-
-</p>
-
-<p>
- The extension auth-scheme (as defined by
- <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks,
-J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen,
-A., and L. Stewart, “HTTP Authentication: Basic and Digest Access
-Authentication,” .</span><span>)</span></a>) is <tt>OAuth</tt> and is case-insensitive.
-
-</p>
-
-<p><a name="auth_header_authorization"></a><br></p><hr>
-
-<p><a name="rfc.section.5.4.1"></a></p><h3>5.4.1.
-Authorization Header</h3>
-
-<p>
- The OAuth Protocol Parameters are sent in the <tt>Authorization</tt>
- header the following way:
-
- </p>
-<ol class="text">
-<li>
- Parameter names and values are encoded per
- <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>.
-
-</li>
-<li>
- 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).
-
-</li>
-<li>
- Parameters are separated by a comma character (ASCII code 44)
- and OPTIONAL linear whitespace per <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks,
-J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen,
-A., and L. Stewart, “HTTP Authentication: Basic and Digest Access
-Authentication,” .</span><span>)</span></a>.
-
-</li>
-<li>
- The OPTIONAL <tt>realm</tt> parameter is added and interpreted per
- <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks,
-J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen,
-A., and L. Stewart, “HTTP Authentication: Basic and Digest Access
-Authentication,” .</span><span>)</span></a>, section 1.2.
-
-</li>
-</ol><p>
-
-</p>
-
-<p>
- For example:
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> 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"
-</pre></div><p>
-
-
-</p>
-
-<p><a name="anchor8"></a><br></p><hr>
-
-<p><a name="rfc.section.5.4.2"></a></p><h3>5.4.2.
-WWW-Authenticate Header</h3>
-
-<p>
- Service Providers MAY indicate their support for the extension by
- returning the OAuth HTTP <tt>WWW-Authenticate</tt>
- header upon Consumer requests for Protected Resources. As per
- <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks,
-J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen,
-A., and L. Stewart, “HTTP Authentication: Basic and Digest Access
-Authentication,” .</span><span>)</span></a> such a response MAY include additional
- HTTP <tt>WWW-Authenticate</tt> headers:
-
-</p>
-
-<p>
- For example:
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> WWW-Authenticate: OAuth realm="http://sp.example.com/"
-</pre></div><p>
-
-
-</p>
-
-<p>
- The realm parameter defines a protection realm per
- <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks,
-J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen,
-A., and L. Stewart, “HTTP Authentication: Basic and Digest Access
-Authentication,” .</span><span>)</span></a>, section 1.2.
-
-</p>
-
-<p><a name="anchor9"></a><br></p><hr>
-
-<p><a name="rfc.section.6"></a></p><h3>6.
-Authenticating with OAuth</h3>
-
-<p>
- 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:
-
- </p>
-<blockquote class="text"><dl>
-<dt>Request Token:</dt>
-<dd>
- 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.
-
-</dd>
-<dt>Access Token:</dt>
-<dd>
- 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.
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p>
- OAuth Authentication is done in three steps:
-
- </p>
-<ol class="text">
-<li>
- The Consumer obtains an unauthorized Request Token.
-
-</li>
-<li>
- The User authorizes the Request Token.
-
-</li>
-<li>
- The Consumer exchanges the Request Token for an Access Token.
-
-</li>
-</ol><p>
-
-</p>
-
-<p><img src="OAuth%20Core%201.0_files/diagram.png" alt=""></p>
-<a name="auth_step1"></a><br><hr>
-
-<a name="rfc.section.6.1"></a><h3>6.1.
-Obtaining an Unauthorized Request Token</h3>
-
-<p>
- 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:
-
-</p>
-
-<p><a name="obtain_request_token"></a><br></p><hr>
-
-<p><a name="rfc.section.6.1.1"></a></p><h3>6.1.1.
-Consumer Obtains a Request Token</h3>
-
-<p>
- 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:
-
- </p>
-<blockquote class="text"><dl>
-<dt>oauth_consumer_key:</dt>
-<dd>
- The Consumer Key.
-
-</dd>
-<dt>oauth_signature_method:</dt>
-<dd>
- The signature method the Consumer used to sign the request.
-
-</dd>
-<dt>oauth_signature:</dt>
-<dd>
- The signature as defined in
- <a class="info" href="#signing_process">Signing Requests<span> (</span><span class="info">Signing Requests</span><span>)</span></a>.
-
-</dd>
-<dt>oauth_timestamp:</dt>
-<dd>
- As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>.
-
-</dd>
-<dt>oauth_nonce:</dt>
-<dd>
- As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>.
-
-</dd>
-<dt>oauth_version:</dt>
-<dd>
- OPTIONAL. If present, value MUST be <tt>
- 1.0
- </tt>. Service Providers
- MUST assume the protocol version to be <tt>1.0</tt> if this parameter
- is not present. Service Providers’ response to non-<tt>1.0</tt> value
- is left undefined.
-
-</dd>
-<dt>Additional parameters:</dt>
-<dd>
- Any additional parameters, as defined by the Service Provider.
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p><a name="request_grant"></a><br></p><hr>
-
-<p><a name="rfc.section.6.1.2"></a></p><h3>6.1.2.
-Service Provider Issues an Unauthorized Request Token</h3>
-
-<p>
- 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 <a class="info" href="#response_parameters">Service Provider Response Parameters<span> (</span><span class="info">Service Provider Response Parameters</span><span>)</span></a>.
- The Service Provider MUST ensure the Request
- Token cannot be exchanged for an Access Token until the User
- successfully grants access in <a class="info" href="#auth_step2">Obtaining
- User Authorization<span> (</span><span class="info">Obtaining User Authorization</span><span>)</span></a>.
-
-</p>
-
-<p>
- The response contains the following parameters:
-
- </p>
-<blockquote class="text"><dl>
-<dt>oauth_token:</dt>
-<dd>
- The Request Token.
-
-</dd>
-<dt>oauth_token_secret:</dt>
-<dd>
- The Token Secret.
-
-</dd>
-<dt>Additional parameters:</dt>
-<dd>
- Any additional parameters, as defined by the Service Provider.
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p>
- If the request fails verification or is rejected for other reasons,
- the Service Provider SHOULD respond with the appropriate response
- code as defined in <a class="info" href="#http_codes">HTTP Response Codes<span> (</span><span class="info">HTTP Response Codes</span><span>)</span></a>.
- The Service Provider MAY include some further details about why the
- request was rejected in the HTTP response body as defined in
- <a class="info" href="#response_parameters">Service Provider Response Parameters<span> (</span><span class="info">Service Provider Response Parameters</span><span>)</span></a>.
-
-</p>
-
-<p><a name="auth_step2"></a><br></p><hr>
-
-<p><a name="rfc.section.6.2"></a></p><h3>6.2.
-Obtaining User Authorization</h3>
-
-<p>
- The Consumer cannot use the Request Token until it has been
- authorized by the User. Obtaining User authorization includes
- the following steps:
-
-</p>
-
-<p><a name="user_auth_redirected"></a><br></p><hr>
-
-<p><a name="rfc.section.6.2.1"></a></p><h3>6.2.1.
-Consumer Directs the User to the Service Provider</h3>
-
-<p>
- 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 Authorization URL with the following parameter:
-
- </p>
-<blockquote class="text"><dl>
-<dt>oauth_token:</dt>
-<dd>
- 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.
-
-</dd>
-<dt>oauth_callback:</dt>
-<dd>
- OPTIONAL. The Consumer MAY specify a URL the Service Provider
- will use to redirect the User back to the Consumer when
- <a class="info" href="#auth_step2">Obtaining User Authorization<span> (</span><span class="info">Obtaining User Authorization</span><span>)</span></a>
- is complete.
-
-</dd>
-<dt>Additional parameters:</dt>
-<dd>
- Any additional parameters, as defined by the Service Provider.
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="anchor10"></a><br></p><hr>
-
-<p><a name="rfc.section.6.2.2"></a></p><h3>6.2.2.
-Service Provider Authenticates the User and Obtains Consent</h3>
-
-<p>
- 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:
-
- </p>
-<ul class="text">
-<li>
- 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.
-
-</li>
-<li>
- 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.
-
-</li>
-<li>
- 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.
-
-</li>
-</ul><p>
-
-</p>
-
-<p>
- When displaying any identifying information about the Consumer to
- the 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.
-
-</p>
-
-<p><a name="anchor11"></a><br></p><hr>
-
-<p><a name="rfc.section.6.2.3"></a></p><h3>6.2.3.
-Service Provider Directs the User Back to the Consumer</h3>
-
-<p>
- 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.
-
-</p>
-
-<p>
- If the Consumer provided a callback URL in <tt>oauth_callback</tt> (as
- described in <a class="info" href="#user_auth_redirected">Consumer Directs the User to the Service Provider<span> (</span><span class="info">Consumer Directs the User to the Service Provider</span><span>)</span></a>),
- the Service Provider constructs an HTTP GET request URL, and
- redirects the User’s web browser to that URL with the following
- parameters:
-
- </p>
-<blockquote class="text"><dl>
-<dt>oauth_token:</dt>
-<dd>
- The Request Token the User authorized or denied.
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p>
- The callback URL MAY include Consumer provided query parameters.
- The Service Provider MUST retain them unmodified and append the
- <tt>oauth_token</tt> parameter to the existing query.
-
-</p>
-
-<p>
- If no callback URL was provided, the Service Provider instructs
- the User to manually inform the Consumer that authorization has
- completed.
-
-</p>
-
-<p><a name="auth_step3"></a><br></p><hr>
-
-<p><a name="rfc.section.6.3"></a></p><h3>6.3.
-Obtaining an Access Token</h3>
-
-<p>
- The Consumer exchanges the Request Token for an Access Token capable
- of accessing the Protected Resources. Obtaining an Access Token
- includes the following steps:
-
-</p>
-
-<p><a name="anchor12"></a><br></p><hr>
-
-<p><a name="rfc.section.6.3.1"></a></p><h3>6.3.1.
-Consumer Requests an Access Token</h3>
-
-<p>
- The Request Token and Token Secret MUST be exchanged for an Access
- Token and Token Secret.
-
-</p>
-
-<p>
- 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
- <a class="info" href="#signing_process">Signing Requests<span> (</span><span class="info">Signing Requests</span><span>)</span></a>,
- and contains the following parameters:
-
- </p>
-<blockquote class="text"><dl>
-<dt>oauth_consumer_key:</dt>
-<dd>
- The Consumer Key.
-
-</dd>
-<dt>oauth_token:</dt>
-<dd>
- The Request Token obtained previously.
-
-</dd>
-<dt>oauth_signature_method:</dt>
-<dd>
- The signature method the Consumer used to sign the request.
-
-</dd>
-<dt>oauth_signature:</dt>
-<dd>
- The signature as defined in <a class="info" href="#signing_process">Signing Requests<span> (</span><span class="info">Signing Requests</span><span>)</span></a>.
-
-</dd>
-<dt>oauth_timestamp:</dt>
-<dd>
- As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>.
-
-</dd>
-<dt>oauth_nonce:</dt>
-<dd>
- As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>.
-
-</dd>
-<dt>oauth_version:</dt>
-<dd>
- OPTIONAL. If present, value MUST be <tt>
- 1.0
- </tt>. Service Providers
- MUST assume the protocol version to be <tt>1.0</tt> if this parameter
- is not present. Service Providers’ response to non-<tt>1.0</tt> value
- is left undefined.
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="access_grant"></a><br></p><hr>
-
-<p><a name="rfc.section.6.3.2"></a></p><h3>6.3.2.
-Service Provider Grants an Access Token</h3>
-
-<p>
- The Service Provider MUST ensure that:
-
- </p>
-<ul class="text">
-<li>
- The request signature has been successfully verified.
-
-</li>
-<li>
- The Request Token has never been exchanged for an Access Token.
-
-</li>
-<li>
- The Request Token matches the Consumer Key.
-
-</li>
-</ul><p>
-
-</p>
-
-<p>
- If successful, the Service Provider generates an Access Token and
- Token Secret and returns them in the HTTP response body as defined
- in <a class="info" href="#response_parameters">Service Provider Response Parameters<span> (</span><span class="info">Service Provider Response Parameters</span><span>)</span></a>.
- The Access Token and Token Secret are stored by the Consumer and
- used when signing Protected Resources requests. The response
- contains the following parameters:
-
- </p>
-<blockquote class="text"><dl>
-<dt>oauth_token:</dt>
-<dd>
- The Access Token.
-
-</dd>
-<dt>oauth_token_secret:</dt>
-<dd>
- The Token Secret.
-
-</dd>
-<dt>Additional parameters:</dt>
-<dd>
- Any additional parameters, as defined by the Service Provider.
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p>
- If the request fails verification or is rejected for other reasons,
- the Service Provider SHOULD respond with the appropriate response
- code as defined in <a class="info" href="#http_codes">HTTP Response Codes<span> (</span><span class="info">HTTP Response Codes</span><span>)</span></a>.
- The Service Provider MAY include some further details about why the
- request was rejected in the HTTP response body as defined in
- <a class="info" href="#response_parameters">Service Provider Response Parameters<span> (</span><span class="info">Service Provider Response Parameters</span><span>)</span></a>.
-
-</p>
-
-<p><a name="anchor13"></a><br></p><hr>
-
-<p><a name="rfc.section.7"></a></p><h3>7.
-Accessing Protected Resources</h3>
-
-<p>
- 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
- <a class="info" href="#signing_process">Signing Requests<span> (</span><span class="info">Signing Requests</span><span>)</span></a>, and
- contains the following parameters:
-
- </p>
-<blockquote class="text"><dl>
-<dt>oauth_consumer_key:</dt>
-<dd>
- The Consumer Key.
-
-</dd>
-<dt>oauth_token:</dt>
-<dd>
- The Access Token.
-
-</dd>
-<dt>oauth_signature_method:</dt>
-<dd>
- The signature method the Consumer used to sign the request.
-
-</dd>
-<dt>oauth_signature:</dt>
-<dd>
- The signature as defined in
- <a class="info" href="#signing_process">Signing Requests<span> (</span><span class="info">Signing Requests</span><span>)</span></a>.
-
-</dd>
-<dt>oauth_timestamp:</dt>
-<dd>
- As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>.
-
-</dd>
-<dt>oauth_nonce:</dt>
-<dd>
- As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>.
-
-</dd>
-<dt>oauth_version:</dt>
-<dd>
- OPTIONAL. If present, value MUST be <tt>1.0</tt>. Service Providers
- MUST assume the protocol version to be <tt>1.0</tt> if this parameter
- is not present. Service Providers’ response to non-<tt>1.0</tt> value
- is left undefined.
-
-</dd>
-<dt>Additional parameters:</dt>
-<dd>
- Any additional parameters, as defined by the Service Provider.
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p><a name="nonce"></a><br></p><hr>
-
-<p><a name="rfc.section.8"></a></p><h3>8.
-Nonce and Timestamp</h3>
-
-<p>
- 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.
-
-</p>
-
-<p>
- The Consumer SHALL then generate a Nonce value that is unique for all
- requests with that timestamp. A nonce is a random string, uniquely
- generated for each request. The nonce allows the Service Provider to
- verify that a request has never been made before and helps prevent
- replay attacks when requests are made over a non-secure channel
- (such as HTTP).
-
-</p>
-
-<p><a name="signing_process"></a><br></p><hr>
-
-<p><a name="rfc.section.9"></a></p><h3>9.
-Signing Requests</h3>
-
-<p>
- 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.
-
-</p>
-
-<p>
- OAuth does not mandate a particular signature method, as each
- implementation can have its own unique requirements. The protocol
- defines three signature methods: <tt>HMAC-SHA1</tt>,
- <tt>RSA-SHA1</tt>, and
- <tt>PLAINTEXT</tt>, but Service Providers
- are free to implement and document their own methods.
- Recommending any particular method is beyond the scope of this specification.
-
-</p>
-
-<p>
- The Consumer declares a signature method in the <tt>oauth_signature_method</tt>
- parameter, generates a signature, and stores it in the <tt>oauth_signature</tt>
- 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.
-
-</p>
-
-<p>
- The signature process MUST NOT change the request parameter names or
- values, with the exception of the <tt>oauth_signature</tt> parameter.
-
-</p>
-
-<p><a name="anchor14"></a><br></p><hr>
-
-<p><a name="rfc.section.9.1"></a></p><h3>9.1.
-Signature Base String</h3>
-
-<p>
- 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 <tt>HMAC-SHA1</tt> signature
- method provides both a standard and an example of using the Signature
- Base String with a signing algorithm to generate signatures. All
- the request parameters MUST be encoded as described in
- <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a> prior to
- constructing the Signature Base String.
-
-</p>
-
-<p><a name="sig_norm_param"></a><br></p><hr>
-
-<p><a name="rfc.section.9.1.1"></a></p><h3>9.1.1.
-Normalize Request Parameters</h3>
-
-<p>
- The request parameters are collected, sorted and concatenated into
- a normalized string:
-
- </p>
-<ul class="text">
-<li>
- Parameters in the <a class="info" href="#auth_header_authorization">OAuth HTTP Authorization header<span> (</span><span class="info">Authorization Header</span><span>)</span></a> excluding the <tt>realm</tt>
- parameter.
-
-</li>
-<li>
- Parameters in the HTTP POST request body (with a
- <tt>content-type</tt> of
- <tt>application/x-www-form-urlencoded</tt>).
-
-</li>
-<li>
- HTTP GET parameters added to the URLs in the query part (as defined by
- <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> section 3).
-
-</li>
-</ul><p>
-
-</p>
-
-<p>
- The <tt>oauth_signature</tt> parameter MUST be
- excluded.
-
-</p>
-
-<p>
- The parameters are normalized into a single string as follows:
-
- </p>
-<ol class="text">
-<li>
- 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:
-
- <div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> a=1, c=hi%20there, f=25, f=50, f=a, z=p, z=t
-</pre></div>
-
-</li>
-<li>
- 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:
-
- <div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> a=1&c=hi%20there&f=25&f=50&f=a&z=p&z=t
-</pre></div>
-
-</li>
-</ol><p>
-
-</p>
-
-<p><a name="sig_url"></a><br></p><hr>
-
-<p><a name="rfc.section.9.1.2"></a></p><h3>9.1.2.
-Construct Request URL</h3>
-
-<p>
- 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 <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a>
- section 3.
-
-</p>
-
-<p>
- 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 <tt>Host</tt>
- header, and the relative HTTP request URL. If the
- <tt>Host</tt> header is not available, the Service
- Provider SHOULD use the host name communicated to the Consumer in the
- documentation or other means.
-
-</p>
-
-<p>
- 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; <tt>http</tt> default
- port 80 and <tt>https</tt> default port 443 MUST
- be excluded.
-
-</p>
-
-<p>
- For example, the request:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> HTTP://Example.com:80/resource?id=123
-</pre></div><p>
-
-
- Is included in the Signature Base String as:
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> http://example.com/resource
-</pre></div><p>
-
-
-</p>
-
-<p><a name="anchor15"></a><br></p><hr>
-
-<p><a name="rfc.section.9.1.3"></a></p><h3>9.1.3.
-Concatenate Request Elements</h3>
-
-<p>
- The following items MUST be concatenated in order into a single
- string. Each item is <a class="info" href="#encoding_parameters">encoded<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>
- and separated by an ‘&’ character (ASCII code 38), even if empty.
-
- </p>
-<ol class="text">
-<li>
- The HTTP request method used to send the request. Value MUST be
- uppercase, for example: <tt>HEAD</tt>, <tt>
- GET
- </tt>, <tt>POST</tt>, etc.
-
-</li>
-<li>
- The request URL from <a class="info" href="#sig_url">Section 9.1.2<span> (</span><span class="info">Construct Request URL</span><span>)</span></a>.
-
-</li>
-<li>
- The normalized request parameters string from <a class="info" href="#sig_norm_param">Section 9.1.1<span> (</span><span class="info">Normalize Request Parameters</span><span>)</span></a>.
-
-</li>
-</ol><p>
-
-</p>
-
-<p>
- See Signature Base String example in <a class="info" href="#sig_base_example">Appendix A.5.1<span> (</span><span class="info">Generating Signature Base String</span><span>)</span></a>.
-
-</p>
-
-<p><a name="anchor16"></a><br></p><hr>
-
-<p><a name="rfc.section.9.2"></a></p><h3>9.2.
-HMAC-SHA1</h3>
-
-<p>
- The <tt>HMAC-SHA1</tt> signature method uses the HMAC-SHA1 signature
- algorithm as defined in <a class="info" href="#RFC2104">[RFC2104]<span> (</span><span class="info">Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .</span><span>)</span></a> where the Signature
- Base String is the <tt>text</tt> and the
- <tt>key</tt> is the concatenated values
- (each first encoded per <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>)
- of the Consumer Secret and Token Secret, separated by an ‘&’
- character (ASCII code 38) even if empty.
-
-</p>
-
-<p><a name="anchor17"></a><br></p><hr>
-
-<p><a name="rfc.section.9.2.1"></a></p><h3>9.2.1.
-Generating Signature</h3>
-
-<p>
- <tt>oauth_signature</tt> is set
- to the calculated <tt>digest</tt> octet string, first base64-encoded per
- <a class="info" href="#RFC2045">[RFC2045]<span> (</span><span class="info">Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .</span><span>)</span></a> section 6.8, then URL-encoded per
- <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>.
-
-</p>
-
-<p><a name="anchor18"></a><br></p><hr>
-
-<p><a name="rfc.section.9.2.2"></a></p><h3>9.2.2.
-Verifying Signature</h3>
-
-<p>
- 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 <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>,
- then base64-decoded per <a class="info" href="#RFC2045">[RFC2045]<span> (</span><span class="info">Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .</span><span>)</span></a> 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.
-
-</p>
-
-<p><a name="anchor19"></a><br></p><hr>
-
-<p><a name="rfc.section.9.3"></a></p><h3>9.3.
-RSA-SHA1</h3>
-
-<p>
- The <tt>RSA-SHA1</tt> signature method uses the
- RSASSA-PKCS1-v1_5 signature algorithm as defined in
- <a class="info" href="#RFC3447">[RFC3447]<span> (</span><span class="info">Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .</span><span>)</span></a> 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.
-
-</p>
-
-<p><a name="anchor20"></a><br></p><hr>
-
-<p><a name="rfc.section.9.3.1"></a></p><h3>9.3.1.
-Generating Signature</h3>
-
-<p>
- The Signature Base String is signed using the Consumer’s RSA private
- key per <a class="info" href="#RFC3447">[RFC3447]<span> (</span><span class="info">Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .</span><span>)</span></a> section 8.2.1, where <tt>K</tt> is the
- Consumer’s RSA private key, <tt>M</tt> the Signature Base String, and <tt>S</tt> is
- the result signature octet string:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> S = RSASSA-PKCS1-V1_5-SIGN (K, M)
-</pre></div><p>
-
-
-</p>
-
-<p>
- <tt>oauth_signature</tt> is set to <tt>S</tt>, first base64-encoded per
- <a class="info" href="#RFC2045">[RFC2045]<span> (</span><span class="info">Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .</span><span>)</span></a> section 6.8, then URL-encoded per
- <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>.
-
-</p>
-
-<p><a name="anchor21"></a><br></p><hr>
-
-<p><a name="rfc.section.9.3.2"></a></p><h3>9.3.2.
-Verifying Signature</h3>
-
-<p>
- The Service Provider verifies the signature per <a class="info" href="#RFC3447">[RFC3447]<span> (</span><span class="info">Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .</span><span>)</span></a>
- section 8.2.2, where <tt>
- (n, e)
- </tt> is the Consumer’s RSA public key, <tt>M</tt>
- is the Signature Base String, and <tt>S</tt> is the octet string
- representation of the <tt>oauth_signature</tt> value:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)
-</pre></div><p>
-
-
-</p>
-
-<p><a name="anchor22"></a><br></p><hr>
-
-<p><a name="rfc.section.9.4"></a></p><h3>9.4.
-PLAINTEXT</h3>
-
-<p>
- The <tt>
- PLAINTEXT
- </tt> 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.
-
-</p>
-
-<p><a name="anchor23"></a><br></p><hr>
-
-<p><a name="rfc.section.9.4.1"></a></p><h3>9.4.1.
-Generating Signature</h3>
-
-<p>
- <tt>oauth_signature</tt> 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.
-
-</p>
-
-<p>
- These examples show the value of <tt>oauth_signature</tt>
- for Consumer Secret <tt>djr9rjt0jd78jf88</tt> and
- 3 different Token Secrets:
-
- </p>
-<blockquote class="text"><dl>
-<dt>jjd999tj88uiths3:</dt>
-<dd>
- <tt>oauth_signature</tt>=<tt>djr9rjt0jd78jf88%26jjd999tj88uiths3</tt>
-
-</dd>
-<dt>jjd99$tj88uiths3:</dt>
-<dd>
- <tt>oauth_signature</tt>=<tt>djr9rjt0jd78jf88%26jjd99%2524tj88uiths3</tt>
-
-</dd>
-<dt>Empty:</dt>
-<dd>
- <tt>oauth_signature</tt>=<tt>djr9rjt0jd78jf88%26</tt>
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p><a name="anchor24"></a><br></p><hr>
-
-<p><a name="rfc.section.9.4.2"></a></p><h3>9.4.2.
-Verifying Signature</h3>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="http_codes"></a><br></p><hr>
-
-<p><a name="rfc.section.10"></a></p><h3>10.
-HTTP Response Codes</h3>
-
-<p>
- This section applies only to the Request Token and Access Token
- requests. In general, the Service Provider SHOULD use the
- response codes defined in <a class="info" href="#RFC2616">[RFC2616]<span> (</span><span class="info">Fielding,
-R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T.
-Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .</span><span>)</span></a> Section 10. When
- the Service Provider rejects a Consumer request, it SHOULD respond with
- HTTP 400 Bad Request or HTTP 401 Unauthorized.
-
- </p>
-<ul class="text">
-<li>
- HTTP 400 Bad Request
-
-<ul class="text">
-<li>
- Unsupported parameter
-
-</li>
-<li>
- Unsupported signature method
-
-</li>
-<li>
- Missing required parameter
-
-</li>
-<li>
- Duplicated OAuth Protocol Parameter
-
-</li>
-</ul>
-
-</li>
-<li>
- HTTP 401 Unauthorized
-
-<ul class="text">
-<li>
- Invalid Consumer Key
-
-</li>
-<li>
- Invalid / expired Token
-
-</li>
-<li>
- Invalid signature
-
-</li>
-<li>
- Invalid / used nonce
-
-</li>
-</ul>
-
-</li>
-</ul><p>
-
-</p>
-
-<p><a name="anchor25"></a><br></p><hr>
-
-<p><a name="rfc.section.A"></a></p><h3>Appendix A.
-Appendix A - Protocol Example</h3>
-
-<p>
- 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 <tt>
- vacation.jpg
- </tt> stored at photos.example.net.
-
-</p>
-
-<p>
- When Jane signs-into photos.example.net using her username and
- password, she can access the photo by going to the URL
- <tt>http://photos.example.net/photo?file=vacation.jpg</tt>. Other Users
- cannot access that photo, and Jane does not want to share her
- username and password with printer.example.com.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="anchor26"></a><br></p><hr>
-
-<p><a name="rfc.section.A.1"></a></p><h3>Appendix A.1.
-Documentation and Registration</h3>
-
-<p>
- The Service Provider documentation explains how to register for a
- Consumer Key and Consumer Secret, and declares the following URLs:
-
- </p>
-<blockquote class="text"><dl>
-<dt>Request Token URL:</dt>
-<dd>
- https://photos.example.net/request_token, using HTTP POST
-
-</dd>
-<dt>User Authorization URL:</dt>
-<dd>
- http://photos.example.net/authorize, using HTTP GET
-
-</dd>
-<dt>Access Token URL:</dt>
-<dd>
- https://photos.example.net/access_token, using HTTP POST
-
-</dd>
-<dt>Photo (Protected Resource) URL:</dt>
-<dd>
- http://photos.example.net/photo with required parameter
- <tt>file</tt> and optional parameter <tt>size</tt>
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p>
- The Service Provider declares support for the <tt>
- HMAC-SHA1
- </tt> signature
- method for all requests, and <tt>PLAINTEXT</tt> only for secure (HTTPS)
- requests.
-
-</p>
-
-<p>
- 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:
-
- </p>
-<blockquote class="text"><dl>
-<dt>Consumer Key:</dt>
-<dd>
- <tt>
- dpf43f3p2l4k3l03
- </tt>
-
-</dd>
-<dt>Consumer Secret:</dt>
-<dd>
- <tt>kd94hf93k423kf44</tt>
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p><a name="anchor27"></a><br></p><hr>
-
-<p><a name="rfc.section.A.2"></a></p><h3>Appendix A.2.
-Obtaining a Request Token</h3>
-
-<p>
- 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:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> WWW-Authenticate: OAuth realm="http://photos.example.net/"
-</pre></div><p>
-
-
-</p>
-
-<p>
- The Consumer sends the following HTTP POST request to the Service
- Provider:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> 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
-</pre></div><p>
-
-
-</p>
-
-<p>
- The Service Provider checks the signature and replies with an
- unauthorized Request Token in the body of the HTTP response:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03
-</pre></div><p>
-
-
-</p>
-
-<p><a name="anchor28"></a><br></p><hr>
-
-<p><a name="rfc.section.A.3"></a></p><h3>Appendix A.3.
-Requesting User Authorization</h3>
-
-<p>
- The Consumer redirects Jane’s browser to the Service Provider
- User Authorization URL to obtain Jane’s approval for accessing
- her private photos.
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> http://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola&oauth_callback=http%3A%2F%2Fprinter.example.com%2Frequest_token_ready
-</pre></div><p>
-
-
-</p>
-
-<p>
- 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:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> http://printer.example.com/request_token_ready?oauth_token=hh5s93j4hdidpola
-</pre></div><p>
-
-
-</p>
-
-<p><a name="anchor29"></a><br></p><hr>
-
-<p><a name="rfc.section.A.4"></a></p><h3>Appendix A.4.
-Obtaining an Access Token</h3>
-
-<p>
- Now that the Consumer knows Jane approved the Request Token, it
- asks the Service Provider to exchange it for an Access Token:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> 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
-</pre></div><p>
-
-
-</p>
-
-<p>
- The Service Provider checks the signature and replies with an
- Access Token in the body of the HTTP response:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00
-</pre></div><p>
-
-
-</p>
-
-<p><a name="anchor30"></a><br></p><hr>
-
-<p><a name="rfc.section.A.5"></a></p><h3>Appendix A.5.
-Accessing Protected Resources</h3>
-
-<p>
- The Consumer is now ready to request the private photo. Since the
- photo URL is not secure (HTTP), it must use <tt>HMAC-SHA1</tt>.
-
-</p>
-
-<p><a name="sig_base_example"></a><br></p><hr>
-
-<p><a name="rfc.section.A.5.1"></a></p><h3>Appendix A.5.1.
-Generating Signature Base String</h3>
-
-<p>
- To generate the signature, it first needs to generate the Signature
- Base String. The request contains the following parameters
- (<tt>oauth_signature</tt> excluded) which are ordered and concatenated into
- a normalized string:
-
- </p>
-<blockquote class="text"><dl>
-<dt>oauth_consumer_key:</dt>
-<dd>
- <tt>dpf43f3p2l4k3l03</tt>
-
-</dd>
-<dt>oauth_token:</dt>
-<dd>
- <tt>nnch734d00sl2jdk</tt>
-
-</dd>
-<dt>oauth_signature_method:</dt>
-<dd>
- <tt>HMAC-SHA1</tt>
-
-</dd>
-<dt>oauth_timestamp:</dt>
-<dd>
- <tt>1191242096</tt>
-
-</dd>
-<dt>oauth_nonce:</dt>
-<dd>
- <tt>kllo9940pd9333jh</tt>
-
-</dd>
-<dt>oauth_version:</dt>
-<dd>
- <tt>1.0</tt>
-
-</dd>
-<dt>file:</dt>
-<dd>
- <tt>vacation.jpg</tt>
-
-</dd>
-<dt>size:</dt>
-<dd>
- <tt>original</tt>
-
-</dd>
-</dl></blockquote><p>
-
-</p>
-
-<p>
- The following inputs are used to generate the Signature Base String:
-
- </p>
-<ol class="text">
-<li>
- <tt>GET</tt>
-
-</li>
-<li>
- <tt>http://photos.example.net/photos</tt>
-
-</li>
-<li>
- <tt>file=vacation.jpg&oauth_consumer_key=dpf43f3p2l4k3l03&oauth_nonce=kllo9940pd9333jh&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1191242096&oauth_token=nnch734d00sl2jdk&oauth_version=1.0&size=original</tt>
-
-</li>
-</ol><p>
-
-</p>
-
-<p>
- The Signature Base String is:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal
-</pre></div><p>
-
-
-</p>
-
-<p><a name="anchor31"></a><br></p><hr>
-
-<p><a name="rfc.section.A.5.2"></a></p><h3>Appendix A.5.2.
-Calculating Signature Value</h3>
-
-<p>
- HMAC-SHA1 produces the following <tt>digest</tt> value as a base64-encoded
- string (using the Signature Base String as <tt>text</tt> and
- <tt>
- kd94hf93k423kf44&pfkkdhi9sl3r4s00
- </tt> as <tt>key</tt>):
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> tR3+Ty81lMeYAr/Fid0kMTYa/WM=
-</pre></div><p>
-
-
-</p>
-
-<p><a name="anchor32"></a><br></p><hr>
-
-<p><a name="rfc.section.A.5.3"></a></p><h3>Appendix A.5.3.
-Requesting Protected Resource</h3>
-
-<p>
- All together, the Consumer request for the photo is:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> 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"
-</pre></div><p>
-
-
-</p>
-
-<p>
- And if using query parameters:
-
- </p>
-<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> 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
-</pre></div><p>
-
-
-</p>
-
-<p>
- photos.example.net checks the signature and responds with the
- requested photo.
-
-</p>
-
-<p><a name="anchor33"></a><br></p><hr>
-
-<p><a name="rfc.section.B"></a></p><h3>Appendix B.
-Security Considerations</h3>
-
-<p><a name="anchor34"></a><br></p><hr>
-
-<p><a name="rfc.section.B.1"></a></p><h3>Appendix B.1.
-Credentials and Token Exchange</h3>
-
-<p>
- 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 <a class="info" href="#request_grant">Section 6.1.2<span> (</span><span class="info">Service Provider Issues an Unauthorized Request Token</span><span>)</span></a>
- and <a class="info" href="#access_grant">Section 6.3.2<span> (</span><span class="info">Service Provider Grants an Access Token</span><span>)</span></a>. Service Providers should ensure
- that these transmissions are protected using transport-layer mechanisms
- such as TLS or SSL.
-
-</p>
-
-<p><a name="anchor35"></a><br></p><hr>
-
-<p><a name="rfc.section.B.2"></a></p><h3>Appendix B.2.
-PLAINTEXT Signature Method</h3>
-
-<p>
- When used with <tt>PLAINTEXT</tt> signatures, the
- OAuth protocol makes no attempts to protect User credentials from
- eavesdroppers or man-in-the-middle attacks.
- The <tt>PLAINTEXT</tt> 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
- <tt>PLAINTEXT</tt> signature method should not be
- used.
-
-</p>
-
-<p><a name="anchor36"></a><br></p><hr>
-
-<p><a name="rfc.section.B.3"></a></p><h3>Appendix B.3.
-Confidentiality of Requests</h3>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="anchor37"></a><br></p><hr>
-
-<p><a name="rfc.section.B.4"></a></p><h3>Appendix B.4.
-Spoofing by Counterfeit Servers</h3>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="anchor38"></a><br></p><hr>
-
-<p><a name="rfc.section.B.5"></a></p><h3>Appendix B.5.
-Proxying and Caching of Authenticated Content</h3>
-
-<p>
- The <a class="info" href="#auth_header">HTTP Authorization scheme<span> (</span><span class="info">OAuth HTTP Authorization Scheme</span><span>)</span></a> is
- optional. However, <a class="info" href="#RFC2616">[RFC2616]<span> (</span><span class="info">Fielding,
-R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T.
-Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .</span><span>)</span></a> relies on the
- <tt>Authorization</tt> and
- <tt>WWW-Authenticate</tt> 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.
-
-</p>
-
-<p>
- For example, private authenticated content may be stored in (and thus
- retrievable from) publicly-accessible caches. Service Providers not
- using the <a class="info" href="#auth_header">HTTP Authorization scheme<span> (</span><span class="info">OAuth HTTP Authorization Scheme</span><span>)</span></a>
- should take care to use other mechanisms, such as the
- <tt>Cache-Control</tt> header, to ensure that
- authenticated content is protected.
-
-</p>
-
-<p><a name="anchor39"></a><br></p><hr>
-
-<p><a name="rfc.section.B.6"></a></p><h3>Appendix B.6.
-Plaintext Storage of Credentials</h3>
-
-<p>
- 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-<tt>PLAINTEXT</tt>
- 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.
-
-</p>
-
-<p>
- 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
- unauthorized access.
-
-</p>
-
-<p><a name="anchor40"></a><br></p><hr>
-
-<p><a name="rfc.section.B.7"></a></p><h3>Appendix B.7.
-Secrecy of the Consumer Secret</h3>
-
-<p>
- 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.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="anchor41"></a><br></p><hr>
-
-<p><a name="rfc.section.B.8"></a></p><h3>Appendix B.8.
-Phishing Attacks</h3>
-
-<p>
- 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.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="anchor42"></a><br></p><hr>
-
-<p><a name="rfc.section.B.9"></a></p><h3>Appendix B.9.
-Scoping of Access Requests</h3>
-
-<p>
- 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.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="anchor43"></a><br></p><hr>
-
-<p><a name="rfc.section.B.10"></a></p><h3>Appendix B.10.
-Entropy of Secrets</h3>
-
-<p>
- Unless a transport-layer security protocol is used, eavesdroppers will
- have full access to OAuth requests and signatures, and will thus 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.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="anchor44"></a><br></p><hr>
-
-<p><a name="rfc.section.B.11"></a></p><h3>Appendix B.11.
-Denial of Service / Resource Exhaustion Attacks</h3>
-
-<p>
- 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.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="anchor45"></a><br></p><hr>
-
-<p><a name="rfc.section.B.12"></a></p><h3>Appendix B.12.
-Cryptographic Attacks</h3>
-
-<p>
- SHA-1, the hash algorithm used in <tt>HMAC-SHA1</tt>
- signatures, has been <a class="info" href="#SHA1">shown<span> (</span><span class="info">De Canniere, C. and C. Rechberger, “Finding SHA-1 Characteristics: General Results and Applications,” .</span><span>)</span></a> [SHA1] 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 <a class="info" href="#NIST">announced<span> (</span><span class="info">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,” .</span><span>)</span></a> [NIST] 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.
-
-</p>
-
-<p><a name="anchor46"></a><br></p><hr>
-
-<p><a name="rfc.section.B.13"></a></p><h3>Appendix B.13.
-Signature Base String Compatibility</h3>
-
-<p>
- 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.
-
-</p>
-
-<p>
- 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.
-
-</p>
-
-<p><a name="rfc.references1"></a><br></p><hr>
-
-<h3>11. References</h3>
-
-<table border="0" width="99%">
-<tbody><tr><td class="author-text" valign="top"><a name="NIST">[NIST]</a></td>
-<td class="author-text">National Institute of Standards and Technolog, NIST., “<a href="http://csrc.nist.gov/hash_standards_comments.pdf">NIST Brief Comments on Recent Cryptanalytic Attacks on Secure Hashing Functions and the Continued Security Provided by SHA-1</a>.”</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC2045">[RFC2045]</a></td>
-<td class="author-text">Freed, N. and N. Borenstein, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>,” RFC 2045.</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC2104">[RFC2104]</a></td>
-<td class="author-text">Krawczyk, H., Bellare, M., and R. Canetti, “<a href="http://tools.ietf.org/html/rfc2104">HMAC: Keyed-Hashing for Message Authentication</a>,” RFC 2104.</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
-<td class="author-text">Bradner, B., “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” RFC 2119.</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC2606">[RFC2606]</a></td>
-<td class="author-text">Eastlake, D. and A. Panitz, “<a href="http://tools.ietf.org/html/rfc2606">Reserved Top Level DNS Names</a>,” RFC 2606.</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
-<td class="author-text">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol – HTTP/1.1</a>,” RFC 2616.</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC2617">[RFC2617]</a></td>
-<td class="author-text">Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>,” RFC 2617.</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC3447">[RFC3447]</a></td>
-<td class="author-text">Jonsson, J. and B. Kaliski, “<a href="http://tools.ietf.org/html/rfc3447">Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1</a>,” RFC 3447.</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC3629">[RFC3629]</a></td>
-<td class="author-text">Yergeau, F., “<a href="http://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of Unicode and ISO 10646</a>,” RFC 3629.</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
-<td class="author-text">Berners-Lee, T., “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifiers (URI): Generic Syntax</a>,” RFC 3986.</td></tr>
-<tr><td class="author-text" valign="top"><a name="SHA1">[SHA1]</a></td>
-<td class="author-text">De Canniere, C. and C. Rechberger, “<a href="http://dx.doi.org/10.1007/11935230_1">Finding SHA-1 Characteristics: General Results and Applications</a>.”</td></tr>
-</tbody></table>
-
-<p><a name="rfc.authors"></a><br></p><hr>
-
-<h3>Author’s Address</h3>
-
-<table border="0" cellpadding="0" cellspacing="0" width="99%">
-<tbody><tr><td class="author-text"> </td>
-<td class="author-text">OAuth Core Workgroup</td></tr>
-<tr><td class="author" align="right">Email: </td>
-<td class="author-text"><a href="mailto:spec@oauth.net">spec@oauth.net</a></td></tr>
-</tbody></table>
-<script type="text/javascript">
- var gaJsHost = (("https:" == document.location.protocol) ?
- "https://ssl." : "http://www.");
- document.write(unescape("%3Cscript src='" + gaJsHost +
- "google-analytics.com/ga.js'
-type='text/javascript'%3E%3C/script%3E"));
-</script>
-<script type="text/javascript">
- var pageTracker = _gat._getTracker("UA-31771-2");
- pageTracker._initData();
- pageTracker._trackPageview();
-</script>
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en"><head> +<title>OAuth Core 1.0</title> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<meta name="description" content="OAuth Core 1.0"> +<style type="text/css"> + body { + font-family: "lucida grande", verdana, arial, helvetica, sans-serif; + font-size: 83%; color: #000; background-color: #FFF; + margin: 2em; + } + h1, h2, h3, h4, h5, h6 { + font-family: helvetica neue, arial, "MS Sans Serif", sans-serif; + font-weight: bold; font-style: normal; + } + h1 { color: #111; background-color: transparent; padding-bottom: 2px; border-bottom: 4px solid #efefef; } + h3 { color: #333; background-color: transparent; } + + + td.header { + font-family: arial, helvetica, sans-serif; font-size: x-small; + vertical-align: top; width: 33%; + color: #FFF; background-color: #666; + } + td.author { font-weight: bold; font-size: x-small; margin-left: 4em; } + td.author-text { font-size: x-small; } + + /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */ + a.info { + /* This is the key. */ + position: relative; + z-index: 24; + } + a.info:hover { + z-index: 25; + color: #FFF; background-color: #369; + text-decoration: none; + } + a.info span { display: none; } + a.info:hover span.info { + /* The span will display just on :hover state. */ + display: block; + position: absolute; + font-size: smaller; + top: 2em; left: -5em; width: 15em; + padding: 2px; border: 1px solid #333; + color: #369; background-color: #EEE; + text-align: left; + } + + a { font-weight: bold; } + a:link { color: #369; background-color: transparent; } + a:visited { color: #666; background-color: transparent; } + a:active { color: #888; background-color: transparent; } + + p { margin-left: 2em; margin-right: 2em; } + p.copyright { font-size: x-small; } + p.toc { font-size: small; font-weight: bold; margin-left: 3em; } + table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; } + td.toc { font-size: small; font-weight: bold; vertical-align: text-top; } + + ol.text { margin-left: 1em; margin-right: 2em; } + ul.text { margin-left: 1em; margin-right: 2em; } + li { margin-left: 1em; padding-left: 1.2em; } + + /* RFC-2629 <spanx>s and <artwork>s. */ + em { font-style: italic; } + strong { font-weight: bold; } + dfn { font-weight: bold; font-style: normal; } + cite { font-weight: normal; font-style: normal; } + tt { color: #036; } + tt, pre, pre dfn, pre em, pre cite, pre span { + font-family: "Courier New", Courier, monospace; font-size: small; + } + pre { + text-align: left; padding: 4px; + color: #000; background-color: #f7f7f7; + width: auto; + } + pre dfn { color: #369; } + pre em { color: #66F; background-color: #FFC; font-weight: normal; } + pre .key { color: #33C; font-weight: bold; } + pre .id { color: #369; } + pre .str { color: #000; background-color: #CFF; } + pre .val { color: #066; } + pre .rep { color: #909; } + pre .oth { color: #000; background-color: #FCF; } + pre .err { background-color: #FCC; } + + /* RFC-2629 <texttable>s. */ + table.all, table.full, table.headers, table.none { + font-size: small; text-align: center; border-width: 2px; + vertical-align: top; border-collapse: collapse; + } + table.all, table.full { border-style: solid; border-color: black; } + table.headers, table.none { border-style: none; } + th { + font-weight: bold; border-color: #000; + border-width: 2px 2px 3px 2px; + } + table.all th, table.full th { border-style: solid; } + table.headers th { border-style: none none solid none; } + table.none th { border-style: none; } + table.all td { + border-style: solid; border-color: #333; + border-width: 1px 2px; + } + table.full td, table.headers td, table.none td { border-style: none; } + + hr { height: 1px; border:1px solid #e7e7e7; background-color:#e7e7e7;} + hr.insert { + width: 80%; border-style: none; border-width: 0; + color: #CCC; background-color: #CCC; + } +</style> +</head><body> +<p><span style="float: right;">December 4, 2007</span></p> + +<h1><br>OAuth Core 1.0</h1> + +<h3>Abstract</h3> + +<p> + 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. + +</p> + +<p> + 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. + +</p> + +<p> + 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. + +</p> + +<p> + 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. + +</p><a name="toc"></a><br><hr> +<h3>Table of Contents</h3> +<p class="toc"> +<a href="#anchor1">1.</a> +Authors<br> +<a href="#anchor2">2.</a> +Notation and Conventions<br> +<a href="#anchor3">3.</a> +Definitions<br> +<a href="#anchor4">4.</a> +Documentation and Registration<br> + <a href="#request_urls">4.1.</a> +Request URLs<br> + <a href="#anchor5">4.2.</a> +Service Providers<br> + <a href="#anchor6">4.3.</a> +Consumers<br> +<a href="#anchor7">5.</a> +Parameters<br> + <a href="#encoding_parameters">5.1.</a> +Parameter Encoding<br> + <a href="#consumer_req_param">5.2.</a> +Consumer Request Parameters<br> + <a href="#response_parameters">5.3.</a> +Service Provider Response Parameters<br> + <a href="#auth_header">5.4.</a> +OAuth HTTP Authorization Scheme<br> +<a href="#anchor9">6.</a> +Authenticating with OAuth<br> + <a href="#auth_step1">6.1.</a> +Obtaining an Unauthorized Request Token<br> + <a href="#auth_step2">6.2.</a> +Obtaining User Authorization<br> + <a href="#auth_step3">6.3.</a> +Obtaining an Access Token<br> +<a href="#anchor13">7.</a> +Accessing Protected Resources<br> +<a href="#nonce">8.</a> +Nonce and Timestamp<br> +<a href="#signing_process">9.</a> +Signing Requests<br> + <a href="#anchor14">9.1.</a> +Signature Base String<br> + <a href="#anchor16">9.2.</a> +HMAC-SHA1<br> + <a href="#anchor19">9.3.</a> +RSA-SHA1<br> + <a href="#anchor22">9.4.</a> +PLAINTEXT<br> +<a href="#http_codes">10.</a> +HTTP Response Codes<br> +<a href="#anchor25">Appendix A.</a> +Appendix A - Protocol Example<br> +<a href="#anchor26">Appendix A.1.</a> +Documentation and Registration<br> +<a href="#anchor27">Appendix A.2.</a> +Obtaining a Request Token<br> +<a href="#anchor28">Appendix A.3.</a> +Requesting User Authorization<br> +<a href="#anchor29">Appendix A.4.</a> +Obtaining an Access Token<br> +<a href="#anchor30">Appendix A.5.</a> +Accessing Protected Resources<br> +<a href="#anchor33">Appendix B.</a> +Security Considerations<br> +<a href="#anchor34">Appendix B.1.</a> +Credentials and Token Exchange<br> +<a href="#anchor35">Appendix B.2.</a> +PLAINTEXT Signature Method<br> +<a href="#anchor36">Appendix B.3.</a> +Confidentiality of Requests<br> +<a href="#anchor37">Appendix B.4.</a> +Spoofing by Counterfeit Servers<br> +<a href="#anchor38">Appendix B.5.</a> +Proxying and Caching of Authenticated Content<br> +<a href="#anchor39">Appendix B.6.</a> +Plaintext Storage of Credentials<br> +<a href="#anchor40">Appendix B.7.</a> +Secrecy of the Consumer Secret<br> +<a href="#anchor41">Appendix B.8.</a> +Phishing Attacks<br> +<a href="#anchor42">Appendix B.9.</a> +Scoping of Access Requests<br> +<a href="#anchor43">Appendix B.10.</a> +Entropy of Secrets<br> +<a href="#anchor44">Appendix B.11.</a> +Denial of Service / Resource Exhaustion Attacks<br> +<a href="#anchor45">Appendix B.12.</a> +Cryptographic Attacks<br> +<a href="#anchor46">Appendix B.13.</a> +Signature Base String Compatibility<br> +<a href="#rfc.references1">11.</a> +References<br> +<a href="#rfc.authors">§</a> +Author’s Address<br> +</p> + +<p><br clear="all"></p> + +<p><a name="anchor1"></a><br></p><hr> + +<p><a name="rfc.section.1"></a></p><h3>1. +Authors</h3> + +<ul> + <li><span class="vcard"><span class="fn">Mark Atwood</span> (<span class="email">me@mark.atwood.name</span>)</span></li> + <li><span class="vcard"><span class="fn">Richard M. Conlan</span> (<span class="email">zeveck@google.com</span>)</span></li> + <li><span class="vcard"><span class="fn">Blaine Cook</span> (<span class="email">blaine@twitter.com</span>)</span></li> + <li><span class="vcard"><span class="fn">Leah Culver</span> (<span class="email">leah@pownce.com</span>)</span></li> + <li><span class="vcard"><span class="fn">Kellan Elliott-McCrea</span> (<span class="email">kellan@flickr.com</span>)</span></li> + <li><span class="vcard"><span class="fn">Larry Halff</span> (<span class="email">larry@ma.gnolia.com</span>)</span></li> + <li><span class="vcard"><span class="fn">Eran Hammer-Lahav</span> (<span class="email">eran@hueniverse.com</span>)</span></li> + <li><span class="vcard"><span class="fn">Ben Laurie</span> (<span class="email">benl@google.com</span>)</span></li> + <li><span class="vcard"><span class="fn">Chris Messina</span> (<span class="email">chris@citizenagency.com</span>)</span></li> + <li><span class="vcard"><span class="fn">John Panzer</span> (<span class="email">jpanzer@acm.org</span>)</span></li> + <li><span class="vcard"><span class="fn">Sam Quigley</span> (<span class="email">quigley@emerose.com</span>)</span></li> + <li><span class="vcard"><span class="fn">David Recordon</span> (<span class="email">david@sixapart.com</span>)</span></li> + <li><span class="vcard"><span class="fn">Eran Sandler</span> (<span class="email">eran@yedda.com</span>)</span></li> + <li><span class="vcard"><span class="fn">Jonathan Sergent</span> (<span class="email">sergent@google.com</span>)</span></li> + <li><span class="vcard"><span class="fn">Todd Sieling</span> (<span class="email">todd@ma.gnolia.com</span>)</span></li> + <li><span class="vcard"><span class="fn">Brian Slesinsky</span> (<span class="email">brian-oauth@slesinsky.org</span>)</span></li> + <li><span class="vcard"><span class="fn">Andy Smith</span> (<span class="email">andy@jaiku.com</span>)</span></li> +</ul> + +<p><a name="anchor2"></a><br></p><hr> + +<p><a name="rfc.section.2"></a></p><h3>2. +Notation and Conventions</h3> + +<p> + 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 <a class="info" href="#RFC2119">[RFC2119]<span> (</span><span class="info">Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .</span><span>)</span></a>. + Domain name examples use <a class="info" href="#RFC2606">[RFC2606]<span> (</span><span class="info">Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” .</span><span>)</span></a>. + +</p> + +<p><a name="anchor3"></a><br></p><hr> + +<p><a name="rfc.section.3"></a></p><h3>3. +Definitions</h3> + +<p> + </p> +<blockquote class="text"><dl> +<dt>Service Provider:</dt> +<dd> + A web application that allows access via OAuth. + +</dd> +<dt>User:</dt> +<dd> + An individual who has an account with the Service Provider. + +</dd> +<dt>Consumer:</dt> +<dd> + A website or application that uses OAuth to access the Service + Provider on behalf of the User. + +</dd> +<dt>Protected Resource(s):</dt> +<dd> + Data controlled by the Service Provider, which the Consumer can + access through authentication. + +</dd> +<dt>Consumer Developer:</dt> +<dd> + An individual or organization that implements a Consumer. + +</dd> +<dt>Consumer Key:</dt> +<dd> + A value used by the Consumer to identify itself to the Service + Provider. + +</dd> +<dt>Consumer Secret:</dt> +<dd> + A secret used by the Consumer to establish ownership of the + Consumer Key. + +</dd> +<dt>Request Token:</dt> +<dd> + A value used by the Consumer to obtain authorization from the User, + and exchanged for an Access Token. + +</dd> +<dt>Access Token:</dt> +<dd> + 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. + +</dd> +<dt>Token Secret:</dt> +<dd> + A secret used by the Consumer to establish ownership of a given + Token. + +</dd> +<dt>OAuth Protocol Parameters:</dt> +<dd> + Parameters with names beginning with <tt>oauth_</tt>. + +</dd> +</dl></blockquote><p> + +</p> + +<p><a name="anchor4"></a><br></p><hr> + +<p><a name="rfc.section.4"></a></p><h3>4. +Documentation and Registration</h3> + +<p> + OAuth includes a Consumer Key and matching Consumer Secret that + together authenticate the Consumer (as opposed to the User) to the + Service Provider. Consumer-specific identification allows the Service + Provider to vary access levels to Consumers (such as un-throttled access + to resources). + +</p> + +<p> + 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). + +</p> + +<p><a name="request_urls"></a><br></p><hr> + +<p><a name="rfc.section.4.1"></a></p><h3>4.1. +Request URLs</h3> + +<p> + OAuth defines three request URLs: + + </p> +<blockquote class="text"><dl> +<dt>Request Token URL:</dt> +<dd> + The URL used to obtain an unauthorized Request Token, described + in <a class="info" href="#auth_step1">Section 6.1<span> (</span><span class="info">Obtaining an Unauthorized Request Token</span><span>)</span></a>. + +</dd> +<dt>User Authorization URL:</dt> +<dd> + The URL used to obtain User authorization for Consumer access, + described in <a class="info" href="#auth_step2">Section 6.2<span> (</span><span class="info">Obtaining User Authorization</span><span>)</span></a>. + +</dd> +<dt>Access Token URL:</dt> +<dd> + The URL used to exchange the User-authorized Request Token for + an Access Token, described in <a class="info" href="#auth_step3">Section 6.3<span> (</span><span class="info">Obtaining an Access Token</span><span>)</span></a>. + +</dd> +</dl></blockquote><p> + +</p> + +<p> + The three URLs MUST include scheme, authority, and path, and MAY + include query and fragment as defined by <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> + section 3. The request URL query MUST NOT contain any OAuth Protocol + Parameters. For example: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> http://sp.example.com/authorize +</pre></div><p> + + +</p> + +<p><a name="anchor5"></a><br></p><hr> + +<p><a name="rfc.section.4.2"></a></p><h3>4.2. +Service Providers</h3> + +<p> + 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. + +</p> + +<p> + The Service Provider’s documentation includes: + + </p> +<ol class="text"> +<li> + The <a class="info" href="#request_urls">URLs<span> (</span><span class="info">Request URLs</span><span>)</span></a> 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. + +</li> +<li> + Signature methods supported by the Service Provider. + +</li> +<li> + Any additional request parameters that the Service Provider + requires in order to obtain a Token. Service Provider specific + parameters MUST NOT begin with <tt>oauth_</tt>. + +</li> +</ol><p> + +</p> + +<p><a name="anchor6"></a><br></p><hr> + +<p><a name="rfc.section.4.3"></a></p><h3>4.3. +Consumers</h3> + +<p> + 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. + +</p> + +<p><a name="anchor7"></a><br></p><hr> + +<p><a name="rfc.section.5"></a></p><h3>5. +Parameters</h3> + +<p> + 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. + +</p> + +<p><a name="encoding_parameters"></a><br></p><hr> + +<p><a name="rfc.section.5.1"></a></p><h3>5.1. +Parameter Encoding</h3> + +<p> + All parameter names and values are escaped using the + <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> percent-encoding (%xx) mechanism. + Characters not in the unreserved character set + (<a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> section 2.3) MUST be encoded. Characters + in the unreserved character set MUST NOT be encoded. Hexadecimal + characters in encodings MUST be upper case. Text names and values + MUST be encoded as UTF-8 octets before percent-encoding them per + <a class="info" href="#RFC3629">[RFC3629]<span> (</span><span class="info">Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .</span><span>)</span></a>. + +</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> unreserved = ALPHA, DIGIT, '-', '.', '_', '~' +</pre></div> +<a name="consumer_req_param"></a><br><hr> + +<a name="rfc.section.5.2"></a><h3>5.2. +Consumer Request Parameters</h3> + +<p> + OAuth Protocol Parameters are sent from the Consumer to the Service + Provider in one of three methods, in order of decreasing preference: + </p> +<ol class="text"> +<li> + In the HTTP <tt>Authorization</tt> header as defined in + <a class="info" href="#auth_header">OAuth HTTP Authorization Scheme<span> (</span><span class="info">OAuth HTTP Authorization Scheme</span><span>)</span></a>. + +</li> +<li> + As the HTTP POST request body with a <tt> + content-type + </tt> of + <tt>application/x-www-form-urlencoded</tt>. + +</li> +<li> + Added to the URLs in the query part (as defined by + <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> section 3). + +</li> +</ol><p> + +</p> + +<p> + 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 + <a class="info" href="#auth_header">OAuth HTTP Authorization Scheme<span> (</span><span class="info">OAuth HTTP Authorization Scheme</span><span>)</span></a> header. + +</p> + +<p><a name="response_parameters"></a><br></p><hr> + +<p><a name="rfc.section.5.3"></a></p><h3>5.3. +Service Provider Response Parameters</h3> + +<p> + Response parameters are sent by the Service + Provider to return Tokens and other information to the Consumer in + the HTTP response body. The parameter names and values are first + encoded as per <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>, and concatenated with the ‘&’ character (ASCII code 38) + as defined in <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> Section 2.1. For example: + +</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b +</pre></div> +<a name="auth_header"></a><br><hr> + +<a name="rfc.section.5.4"></a><h3>5.4. +OAuth HTTP Authorization Scheme</h3> + +<p> + This section defines an <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks, +J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, +A., and L. Stewart, “HTTP Authentication: Basic and Digest Access +Authentication,” .</span><span>)</span></a> extension to + support OAuth. It uses the standard HTTP <tt>Authorization</tt> and + <tt>WWW-Authenticate</tt> headers to pass OAuth Protocol Parameters. + +</p> + +<p> + It is RECOMMENDED that Service Providers accept the HTTP + <tt>Authorization</tt> header. Consumers SHOULD be able to send OAuth + Protocol Parameters in the OAuth <tt>Authorization</tt> header. + +</p> + +<p> + The extension auth-scheme (as defined by + <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks, +J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, +A., and L. Stewart, “HTTP Authentication: Basic and Digest Access +Authentication,” .</span><span>)</span></a>) is <tt>OAuth</tt> and is case-insensitive. + +</p> + +<p><a name="auth_header_authorization"></a><br></p><hr> + +<p><a name="rfc.section.5.4.1"></a></p><h3>5.4.1. +Authorization Header</h3> + +<p> + The OAuth Protocol Parameters are sent in the <tt>Authorization</tt> + header the following way: + + </p> +<ol class="text"> +<li> + Parameter names and values are encoded per + <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>. + +</li> +<li> + 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). + +</li> +<li> + Parameters are separated by a comma character (ASCII code 44) + and OPTIONAL linear whitespace per <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks, +J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, +A., and L. Stewart, “HTTP Authentication: Basic and Digest Access +Authentication,” .</span><span>)</span></a>. + +</li> +<li> + The OPTIONAL <tt>realm</tt> parameter is added and interpreted per + <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks, +J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, +A., and L. Stewart, “HTTP Authentication: Basic and Digest Access +Authentication,” .</span><span>)</span></a>, section 1.2. + +</li> +</ol><p> + +</p> + +<p> + For example: + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> 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" +</pre></div><p> + + +</p> + +<p><a name="anchor8"></a><br></p><hr> + +<p><a name="rfc.section.5.4.2"></a></p><h3>5.4.2. +WWW-Authenticate Header</h3> + +<p> + Service Providers MAY indicate their support for the extension by + returning the OAuth HTTP <tt>WWW-Authenticate</tt> + header upon Consumer requests for Protected Resources. As per + <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks, +J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, +A., and L. Stewart, “HTTP Authentication: Basic and Digest Access +Authentication,” .</span><span>)</span></a> such a response MAY include additional + HTTP <tt>WWW-Authenticate</tt> headers: + +</p> + +<p> + For example: + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> WWW-Authenticate: OAuth realm="http://sp.example.com/" +</pre></div><p> + + +</p> + +<p> + The realm parameter defines a protection realm per + <a class="info" href="#RFC2617">[RFC2617]<span> (</span><span class="info">Franks, +J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, +A., and L. Stewart, “HTTP Authentication: Basic and Digest Access +Authentication,” .</span><span>)</span></a>, section 1.2. + +</p> + +<p><a name="anchor9"></a><br></p><hr> + +<p><a name="rfc.section.6"></a></p><h3>6. +Authenticating with OAuth</h3> + +<p> + 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: + + </p> +<blockquote class="text"><dl> +<dt>Request Token:</dt> +<dd> + 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. + +</dd> +<dt>Access Token:</dt> +<dd> + 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. + +</dd> +</dl></blockquote><p> + +</p> + +<p> + OAuth Authentication is done in three steps: + + </p> +<ol class="text"> +<li> + The Consumer obtains an unauthorized Request Token. + +</li> +<li> + The User authorizes the Request Token. + +</li> +<li> + The Consumer exchanges the Request Token for an Access Token. + +</li> +</ol><p> + +</p> + +<p><img src="OAuth%20Core%201.0_files/diagram.png" alt=""></p> +<a name="auth_step1"></a><br><hr> + +<a name="rfc.section.6.1"></a><h3>6.1. +Obtaining an Unauthorized Request Token</h3> + +<p> + 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: + +</p> + +<p><a name="obtain_request_token"></a><br></p><hr> + +<p><a name="rfc.section.6.1.1"></a></p><h3>6.1.1. +Consumer Obtains a Request Token</h3> + +<p> + 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: + + </p> +<blockquote class="text"><dl> +<dt>oauth_consumer_key:</dt> +<dd> + The Consumer Key. + +</dd> +<dt>oauth_signature_method:</dt> +<dd> + The signature method the Consumer used to sign the request. + +</dd> +<dt>oauth_signature:</dt> +<dd> + The signature as defined in + <a class="info" href="#signing_process">Signing Requests<span> (</span><span class="info">Signing Requests</span><span>)</span></a>. + +</dd> +<dt>oauth_timestamp:</dt> +<dd> + As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>. + +</dd> +<dt>oauth_nonce:</dt> +<dd> + As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>. + +</dd> +<dt>oauth_version:</dt> +<dd> + OPTIONAL. If present, value MUST be <tt> + 1.0 + </tt>. Service Providers + MUST assume the protocol version to be <tt>1.0</tt> if this parameter + is not present. Service Providers’ response to non-<tt>1.0</tt> value + is left undefined. + +</dd> +<dt>Additional parameters:</dt> +<dd> + Any additional parameters, as defined by the Service Provider. + +</dd> +</dl></blockquote><p> + +</p> + +<p><a name="request_grant"></a><br></p><hr> + +<p><a name="rfc.section.6.1.2"></a></p><h3>6.1.2. +Service Provider Issues an Unauthorized Request Token</h3> + +<p> + 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 <a class="info" href="#response_parameters">Service Provider Response Parameters<span> (</span><span class="info">Service Provider Response Parameters</span><span>)</span></a>. + The Service Provider MUST ensure the Request + Token cannot be exchanged for an Access Token until the User + successfully grants access in <a class="info" href="#auth_step2">Obtaining + User Authorization<span> (</span><span class="info">Obtaining User Authorization</span><span>)</span></a>. + +</p> + +<p> + The response contains the following parameters: + + </p> +<blockquote class="text"><dl> +<dt>oauth_token:</dt> +<dd> + The Request Token. + +</dd> +<dt>oauth_token_secret:</dt> +<dd> + The Token Secret. + +</dd> +<dt>Additional parameters:</dt> +<dd> + Any additional parameters, as defined by the Service Provider. + +</dd> +</dl></blockquote><p> + +</p> + +<p> + If the request fails verification or is rejected for other reasons, + the Service Provider SHOULD respond with the appropriate response + code as defined in <a class="info" href="#http_codes">HTTP Response Codes<span> (</span><span class="info">HTTP Response Codes</span><span>)</span></a>. + The Service Provider MAY include some further details about why the + request was rejected in the HTTP response body as defined in + <a class="info" href="#response_parameters">Service Provider Response Parameters<span> (</span><span class="info">Service Provider Response Parameters</span><span>)</span></a>. + +</p> + +<p><a name="auth_step2"></a><br></p><hr> + +<p><a name="rfc.section.6.2"></a></p><h3>6.2. +Obtaining User Authorization</h3> + +<p> + The Consumer cannot use the Request Token until it has been + authorized by the User. Obtaining User authorization includes + the following steps: + +</p> + +<p><a name="user_auth_redirected"></a><br></p><hr> + +<p><a name="rfc.section.6.2.1"></a></p><h3>6.2.1. +Consumer Directs the User to the Service Provider</h3> + +<p> + 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 Authorization URL with the following parameter: + + </p> +<blockquote class="text"><dl> +<dt>oauth_token:</dt> +<dd> + 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. + +</dd> +<dt>oauth_callback:</dt> +<dd> + OPTIONAL. The Consumer MAY specify a URL the Service Provider + will use to redirect the User back to the Consumer when + <a class="info" href="#auth_step2">Obtaining User Authorization<span> (</span><span class="info">Obtaining User Authorization</span><span>)</span></a> + is complete. + +</dd> +<dt>Additional parameters:</dt> +<dd> + Any additional parameters, as defined by the Service Provider. + +</dd> +</dl></blockquote><p> + +</p> + +<p> + 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. + +</p> + +<p> + 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. + +</p> + +<p><a name="anchor10"></a><br></p><hr> + +<p><a name="rfc.section.6.2.2"></a></p><h3>6.2.2. +Service Provider Authenticates the User and Obtains Consent</h3> + +<p> + 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: + + </p> +<ul class="text"> +<li> + 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. + +</li> +<li> + 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. + +</li> +<li> + 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. + +</li> +</ul><p> + +</p> + +<p> + When displaying any identifying information about the Consumer to + the 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. + +</p> + +<p><a name="anchor11"></a><br></p><hr> + +<p><a name="rfc.section.6.2.3"></a></p><h3>6.2.3. +Service Provider Directs the User Back to the Consumer</h3> + +<p> + 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. + +</p> + +<p> + If the Consumer provided a callback URL in <tt>oauth_callback</tt> (as + described in <a class="info" href="#user_auth_redirected">Consumer Directs the User to the Service Provider<span> (</span><span class="info">Consumer Directs the User to the Service Provider</span><span>)</span></a>), + the Service Provider constructs an HTTP GET request URL, and + redirects the User’s web browser to that URL with the following + parameters: + + </p> +<blockquote class="text"><dl> +<dt>oauth_token:</dt> +<dd> + The Request Token the User authorized or denied. + +</dd> +</dl></blockquote><p> + +</p> + +<p> + The callback URL MAY include Consumer provided query parameters. + The Service Provider MUST retain them unmodified and append the + <tt>oauth_token</tt> parameter to the existing query. + +</p> + +<p> + If no callback URL was provided, the Service Provider instructs + the User to manually inform the Consumer that authorization has + completed. + +</p> + +<p><a name="auth_step3"></a><br></p><hr> + +<p><a name="rfc.section.6.3"></a></p><h3>6.3. +Obtaining an Access Token</h3> + +<p> + The Consumer exchanges the Request Token for an Access Token capable + of accessing the Protected Resources. Obtaining an Access Token + includes the following steps: + +</p> + +<p><a name="anchor12"></a><br></p><hr> + +<p><a name="rfc.section.6.3.1"></a></p><h3>6.3.1. +Consumer Requests an Access Token</h3> + +<p> + The Request Token and Token Secret MUST be exchanged for an Access + Token and Token Secret. + +</p> + +<p> + 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 + <a class="info" href="#signing_process">Signing Requests<span> (</span><span class="info">Signing Requests</span><span>)</span></a>, + and contains the following parameters: + + </p> +<blockquote class="text"><dl> +<dt>oauth_consumer_key:</dt> +<dd> + The Consumer Key. + +</dd> +<dt>oauth_token:</dt> +<dd> + The Request Token obtained previously. + +</dd> +<dt>oauth_signature_method:</dt> +<dd> + The signature method the Consumer used to sign the request. + +</dd> +<dt>oauth_signature:</dt> +<dd> + The signature as defined in <a class="info" href="#signing_process">Signing Requests<span> (</span><span class="info">Signing Requests</span><span>)</span></a>. + +</dd> +<dt>oauth_timestamp:</dt> +<dd> + As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>. + +</dd> +<dt>oauth_nonce:</dt> +<dd> + As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>. + +</dd> +<dt>oauth_version:</dt> +<dd> + OPTIONAL. If present, value MUST be <tt> + 1.0 + </tt>. Service Providers + MUST assume the protocol version to be <tt>1.0</tt> if this parameter + is not present. Service Providers’ response to non-<tt>1.0</tt> value + is left undefined. + +</dd> +</dl></blockquote><p> + +</p> + +<p> + 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. + +</p> + +<p><a name="access_grant"></a><br></p><hr> + +<p><a name="rfc.section.6.3.2"></a></p><h3>6.3.2. +Service Provider Grants an Access Token</h3> + +<p> + The Service Provider MUST ensure that: + + </p> +<ul class="text"> +<li> + The request signature has been successfully verified. + +</li> +<li> + The Request Token has never been exchanged for an Access Token. + +</li> +<li> + The Request Token matches the Consumer Key. + +</li> +</ul><p> + +</p> + +<p> + If successful, the Service Provider generates an Access Token and + Token Secret and returns them in the HTTP response body as defined + in <a class="info" href="#response_parameters">Service Provider Response Parameters<span> (</span><span class="info">Service Provider Response Parameters</span><span>)</span></a>. + The Access Token and Token Secret are stored by the Consumer and + used when signing Protected Resources requests. The response + contains the following parameters: + + </p> +<blockquote class="text"><dl> +<dt>oauth_token:</dt> +<dd> + The Access Token. + +</dd> +<dt>oauth_token_secret:</dt> +<dd> + The Token Secret. + +</dd> +<dt>Additional parameters:</dt> +<dd> + Any additional parameters, as defined by the Service Provider. + +</dd> +</dl></blockquote><p> + +</p> + +<p> + If the request fails verification or is rejected for other reasons, + the Service Provider SHOULD respond with the appropriate response + code as defined in <a class="info" href="#http_codes">HTTP Response Codes<span> (</span><span class="info">HTTP Response Codes</span><span>)</span></a>. + The Service Provider MAY include some further details about why the + request was rejected in the HTTP response body as defined in + <a class="info" href="#response_parameters">Service Provider Response Parameters<span> (</span><span class="info">Service Provider Response Parameters</span><span>)</span></a>. + +</p> + +<p><a name="anchor13"></a><br></p><hr> + +<p><a name="rfc.section.7"></a></p><h3>7. +Accessing Protected Resources</h3> + +<p> + 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 + <a class="info" href="#signing_process">Signing Requests<span> (</span><span class="info">Signing Requests</span><span>)</span></a>, and + contains the following parameters: + + </p> +<blockquote class="text"><dl> +<dt>oauth_consumer_key:</dt> +<dd> + The Consumer Key. + +</dd> +<dt>oauth_token:</dt> +<dd> + The Access Token. + +</dd> +<dt>oauth_signature_method:</dt> +<dd> + The signature method the Consumer used to sign the request. + +</dd> +<dt>oauth_signature:</dt> +<dd> + The signature as defined in + <a class="info" href="#signing_process">Signing Requests<span> (</span><span class="info">Signing Requests</span><span>)</span></a>. + +</dd> +<dt>oauth_timestamp:</dt> +<dd> + As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>. + +</dd> +<dt>oauth_nonce:</dt> +<dd> + As defined in <a class="info" href="#nonce">Nonce and Timestamp<span> (</span><span class="info">Nonce and Timestamp</span><span>)</span></a>. + +</dd> +<dt>oauth_version:</dt> +<dd> + OPTIONAL. If present, value MUST be <tt>1.0</tt>. Service Providers + MUST assume the protocol version to be <tt>1.0</tt> if this parameter + is not present. Service Providers’ response to non-<tt>1.0</tt> value + is left undefined. + +</dd> +<dt>Additional parameters:</dt> +<dd> + Any additional parameters, as defined by the Service Provider. + +</dd> +</dl></blockquote><p> + +</p> + +<p><a name="nonce"></a><br></p><hr> + +<p><a name="rfc.section.8"></a></p><h3>8. +Nonce and Timestamp</h3> + +<p> + 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. + +</p> + +<p> + The Consumer SHALL then generate a Nonce value that is unique for all + requests with that timestamp. A nonce is a random string, uniquely + generated for each request. The nonce allows the Service Provider to + verify that a request has never been made before and helps prevent + replay attacks when requests are made over a non-secure channel + (such as HTTP). + +</p> + +<p><a name="signing_process"></a><br></p><hr> + +<p><a name="rfc.section.9"></a></p><h3>9. +Signing Requests</h3> + +<p> + 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. + +</p> + +<p> + OAuth does not mandate a particular signature method, as each + implementation can have its own unique requirements. The protocol + defines three signature methods: <tt>HMAC-SHA1</tt>, + <tt>RSA-SHA1</tt>, and + <tt>PLAINTEXT</tt>, but Service Providers + are free to implement and document their own methods. + Recommending any particular method is beyond the scope of this specification. + +</p> + +<p> + The Consumer declares a signature method in the <tt>oauth_signature_method</tt> + parameter, generates a signature, and stores it in the <tt>oauth_signature</tt> + 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. + +</p> + +<p> + The signature process MUST NOT change the request parameter names or + values, with the exception of the <tt>oauth_signature</tt> parameter. + +</p> + +<p><a name="anchor14"></a><br></p><hr> + +<p><a name="rfc.section.9.1"></a></p><h3>9.1. +Signature Base String</h3> + +<p> + 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 <tt>HMAC-SHA1</tt> signature + method provides both a standard and an example of using the Signature + Base String with a signing algorithm to generate signatures. All + the request parameters MUST be encoded as described in + <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a> prior to + constructing the Signature Base String. + +</p> + +<p><a name="sig_norm_param"></a><br></p><hr> + +<p><a name="rfc.section.9.1.1"></a></p><h3>9.1.1. +Normalize Request Parameters</h3> + +<p> + The request parameters are collected, sorted and concatenated into + a normalized string: + + </p> +<ul class="text"> +<li> + Parameters in the <a class="info" href="#auth_header_authorization">OAuth HTTP Authorization header<span> (</span><span class="info">Authorization Header</span><span>)</span></a> excluding the <tt>realm</tt> + parameter. + +</li> +<li> + Parameters in the HTTP POST request body (with a + <tt>content-type</tt> of + <tt>application/x-www-form-urlencoded</tt>). + +</li> +<li> + HTTP GET parameters added to the URLs in the query part (as defined by + <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> section 3). + +</li> +</ul><p> + +</p> + +<p> + The <tt>oauth_signature</tt> parameter MUST be + excluded. + +</p> + +<p> + The parameters are normalized into a single string as follows: + + </p> +<ol class="text"> +<li> + 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: + + <div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> a=1, c=hi%20there, f=25, f=50, f=a, z=p, z=t +</pre></div> + +</li> +<li> + 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: + + <div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> a=1&c=hi%20there&f=25&f=50&f=a&z=p&z=t +</pre></div> + +</li> +</ol><p> + +</p> + +<p><a name="sig_url"></a><br></p><hr> + +<p><a name="rfc.section.9.1.2"></a></p><h3>9.1.2. +Construct Request URL</h3> + +<p> + 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 <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> + section 3. + +</p> + +<p> + 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 <tt>Host</tt> + header, and the relative HTTP request URL. If the + <tt>Host</tt> header is not available, the Service + Provider SHOULD use the host name communicated to the Consumer in the + documentation or other means. + +</p> + +<p> + 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; <tt>http</tt> default + port 80 and <tt>https</tt> default port 443 MUST + be excluded. + +</p> + +<p> + For example, the request: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> HTTP://Example.com:80/resource?id=123 +</pre></div><p> + + + Is included in the Signature Base String as: + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> http://example.com/resource +</pre></div><p> + + +</p> + +<p><a name="anchor15"></a><br></p><hr> + +<p><a name="rfc.section.9.1.3"></a></p><h3>9.1.3. +Concatenate Request Elements</h3> + +<p> + The following items MUST be concatenated in order into a single + string. Each item is <a class="info" href="#encoding_parameters">encoded<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a> + and separated by an ‘&’ character (ASCII code 38), even if empty. + + </p> +<ol class="text"> +<li> + The HTTP request method used to send the request. Value MUST be + uppercase, for example: <tt>HEAD</tt>, <tt> + GET + </tt>, <tt>POST</tt>, etc. + +</li> +<li> + The request URL from <a class="info" href="#sig_url">Section 9.1.2<span> (</span><span class="info">Construct Request URL</span><span>)</span></a>. + +</li> +<li> + The normalized request parameters string from <a class="info" href="#sig_norm_param">Section 9.1.1<span> (</span><span class="info">Normalize Request Parameters</span><span>)</span></a>. + +</li> +</ol><p> + +</p> + +<p> + See Signature Base String example in <a class="info" href="#sig_base_example">Appendix A.5.1<span> (</span><span class="info">Generating Signature Base String</span><span>)</span></a>. + +</p> + +<p><a name="anchor16"></a><br></p><hr> + +<p><a name="rfc.section.9.2"></a></p><h3>9.2. +HMAC-SHA1</h3> + +<p> + The <tt>HMAC-SHA1</tt> signature method uses the HMAC-SHA1 signature + algorithm as defined in <a class="info" href="#RFC2104">[RFC2104]<span> (</span><span class="info">Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .</span><span>)</span></a> where the Signature + Base String is the <tt>text</tt> and the + <tt>key</tt> is the concatenated values + (each first encoded per <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>) + of the Consumer Secret and Token Secret, separated by an ‘&’ + character (ASCII code 38) even if empty. + +</p> + +<p><a name="anchor17"></a><br></p><hr> + +<p><a name="rfc.section.9.2.1"></a></p><h3>9.2.1. +Generating Signature</h3> + +<p> + <tt>oauth_signature</tt> is set + to the calculated <tt>digest</tt> octet string, first base64-encoded per + <a class="info" href="#RFC2045">[RFC2045]<span> (</span><span class="info">Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .</span><span>)</span></a> section 6.8, then URL-encoded per + <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>. + +</p> + +<p><a name="anchor18"></a><br></p><hr> + +<p><a name="rfc.section.9.2.2"></a></p><h3>9.2.2. +Verifying Signature</h3> + +<p> + 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 <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>, + then base64-decoded per <a class="info" href="#RFC2045">[RFC2045]<span> (</span><span class="info">Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .</span><span>)</span></a> 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. + +</p> + +<p><a name="anchor19"></a><br></p><hr> + +<p><a name="rfc.section.9.3"></a></p><h3>9.3. +RSA-SHA1</h3> + +<p> + The <tt>RSA-SHA1</tt> signature method uses the + RSASSA-PKCS1-v1_5 signature algorithm as defined in + <a class="info" href="#RFC3447">[RFC3447]<span> (</span><span class="info">Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .</span><span>)</span></a> 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. + +</p> + +<p><a name="anchor20"></a><br></p><hr> + +<p><a name="rfc.section.9.3.1"></a></p><h3>9.3.1. +Generating Signature</h3> + +<p> + The Signature Base String is signed using the Consumer’s RSA private + key per <a class="info" href="#RFC3447">[RFC3447]<span> (</span><span class="info">Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .</span><span>)</span></a> section 8.2.1, where <tt>K</tt> is the + Consumer’s RSA private key, <tt>M</tt> the Signature Base String, and <tt>S</tt> is + the result signature octet string: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> S = RSASSA-PKCS1-V1_5-SIGN (K, M) +</pre></div><p> + + +</p> + +<p> + <tt>oauth_signature</tt> is set to <tt>S</tt>, first base64-encoded per + <a class="info" href="#RFC2045">[RFC2045]<span> (</span><span class="info">Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .</span><span>)</span></a> section 6.8, then URL-encoded per + <a class="info" href="#encoding_parameters">Parameter Encoding<span> (</span><span class="info">Parameter Encoding</span><span>)</span></a>. + +</p> + +<p><a name="anchor21"></a><br></p><hr> + +<p><a name="rfc.section.9.3.2"></a></p><h3>9.3.2. +Verifying Signature</h3> + +<p> + The Service Provider verifies the signature per <a class="info" href="#RFC3447">[RFC3447]<span> (</span><span class="info">Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .</span><span>)</span></a> + section 8.2.2, where <tt> + (n, e) + </tt> is the Consumer’s RSA public key, <tt>M</tt> + is the Signature Base String, and <tt>S</tt> is the octet string + representation of the <tt>oauth_signature</tt> value: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S) +</pre></div><p> + + +</p> + +<p><a name="anchor22"></a><br></p><hr> + +<p><a name="rfc.section.9.4"></a></p><h3>9.4. +PLAINTEXT</h3> + +<p> + The <tt> + PLAINTEXT + </tt> 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. + +</p> + +<p><a name="anchor23"></a><br></p><hr> + +<p><a name="rfc.section.9.4.1"></a></p><h3>9.4.1. +Generating Signature</h3> + +<p> + <tt>oauth_signature</tt> 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. + +</p> + +<p> + These examples show the value of <tt>oauth_signature</tt> + for Consumer Secret <tt>djr9rjt0jd78jf88</tt> and + 3 different Token Secrets: + + </p> +<blockquote class="text"><dl> +<dt>jjd999tj88uiths3:</dt> +<dd> + <tt>oauth_signature</tt>=<tt>djr9rjt0jd78jf88%26jjd999tj88uiths3</tt> + +</dd> +<dt>jjd99$tj88uiths3:</dt> +<dd> + <tt>oauth_signature</tt>=<tt>djr9rjt0jd78jf88%26jjd99%2524tj88uiths3</tt> + +</dd> +<dt>Empty:</dt> +<dd> + <tt>oauth_signature</tt>=<tt>djr9rjt0jd78jf88%26</tt> + +</dd> +</dl></blockquote><p> + +</p> + +<p><a name="anchor24"></a><br></p><hr> + +<p><a name="rfc.section.9.4.2"></a></p><h3>9.4.2. +Verifying Signature</h3> + +<p> + 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. + +</p> + +<p><a name="http_codes"></a><br></p><hr> + +<p><a name="rfc.section.10"></a></p><h3>10. +HTTP Response Codes</h3> + +<p> + This section applies only to the Request Token and Access Token + requests. In general, the Service Provider SHOULD use the + response codes defined in <a class="info" href="#RFC2616">[RFC2616]<span> (</span><span class="info">Fielding, +R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. +Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .</span><span>)</span></a> Section 10. When + the Service Provider rejects a Consumer request, it SHOULD respond with + HTTP 400 Bad Request or HTTP 401 Unauthorized. + + </p> +<ul class="text"> +<li> + HTTP 400 Bad Request + +<ul class="text"> +<li> + Unsupported parameter + +</li> +<li> + Unsupported signature method + +</li> +<li> + Missing required parameter + +</li> +<li> + Duplicated OAuth Protocol Parameter + +</li> +</ul> + +</li> +<li> + HTTP 401 Unauthorized + +<ul class="text"> +<li> + Invalid Consumer Key + +</li> +<li> + Invalid / expired Token + +</li> +<li> + Invalid signature + +</li> +<li> + Invalid / used nonce + +</li> +</ul> + +</li> +</ul><p> + +</p> + +<p><a name="anchor25"></a><br></p><hr> + +<p><a name="rfc.section.A"></a></p><h3>Appendix A. +Appendix A - Protocol Example</h3> + +<p> + 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 <tt> + vacation.jpg + </tt> stored at photos.example.net. + +</p> + +<p> + When Jane signs-into photos.example.net using her username and + password, she can access the photo by going to the URL + <tt>http://photos.example.net/photo?file=vacation.jpg</tt>. Other Users + cannot access that photo, and Jane does not want to share her + username and password with printer.example.com. + +</p> + +<p> + 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. + +</p> + +<p><a name="anchor26"></a><br></p><hr> + +<p><a name="rfc.section.A.1"></a></p><h3>Appendix A.1. +Documentation and Registration</h3> + +<p> + The Service Provider documentation explains how to register for a + Consumer Key and Consumer Secret, and declares the following URLs: + + </p> +<blockquote class="text"><dl> +<dt>Request Token URL:</dt> +<dd> + https://photos.example.net/request_token, using HTTP POST + +</dd> +<dt>User Authorization URL:</dt> +<dd> + http://photos.example.net/authorize, using HTTP GET + +</dd> +<dt>Access Token URL:</dt> +<dd> + https://photos.example.net/access_token, using HTTP POST + +</dd> +<dt>Photo (Protected Resource) URL:</dt> +<dd> + http://photos.example.net/photo with required parameter + <tt>file</tt> and optional parameter <tt>size</tt> + +</dd> +</dl></blockquote><p> + +</p> + +<p> + The Service Provider declares support for the <tt> + HMAC-SHA1 + </tt> signature + method for all requests, and <tt>PLAINTEXT</tt> only for secure (HTTPS) + requests. + +</p> + +<p> + 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: + + </p> +<blockquote class="text"><dl> +<dt>Consumer Key:</dt> +<dd> + <tt> + dpf43f3p2l4k3l03 + </tt> + +</dd> +<dt>Consumer Secret:</dt> +<dd> + <tt>kd94hf93k423kf44</tt> + +</dd> +</dl></blockquote><p> + +</p> + +<p><a name="anchor27"></a><br></p><hr> + +<p><a name="rfc.section.A.2"></a></p><h3>Appendix A.2. +Obtaining a Request Token</h3> + +<p> + 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: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> WWW-Authenticate: OAuth realm="http://photos.example.net/" +</pre></div><p> + + +</p> + +<p> + The Consumer sends the following HTTP POST request to the Service + Provider: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> 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 +</pre></div><p> + + +</p> + +<p> + The Service Provider checks the signature and replies with an + unauthorized Request Token in the body of the HTTP response: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03 +</pre></div><p> + + +</p> + +<p><a name="anchor28"></a><br></p><hr> + +<p><a name="rfc.section.A.3"></a></p><h3>Appendix A.3. +Requesting User Authorization</h3> + +<p> + The Consumer redirects Jane’s browser to the Service Provider + User Authorization URL to obtain Jane’s approval for accessing + her private photos. + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> http://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola&oauth_callback=http%3A%2F%2Fprinter.example.com%2Frequest_token_ready +</pre></div><p> + + +</p> + +<p> + 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: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> http://printer.example.com/request_token_ready?oauth_token=hh5s93j4hdidpola +</pre></div><p> + + +</p> + +<p><a name="anchor29"></a><br></p><hr> + +<p><a name="rfc.section.A.4"></a></p><h3>Appendix A.4. +Obtaining an Access Token</h3> + +<p> + Now that the Consumer knows Jane approved the Request Token, it + asks the Service Provider to exchange it for an Access Token: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> 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 +</pre></div><p> + + +</p> + +<p> + The Service Provider checks the signature and replies with an + Access Token in the body of the HTTP response: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00 +</pre></div><p> + + +</p> + +<p><a name="anchor30"></a><br></p><hr> + +<p><a name="rfc.section.A.5"></a></p><h3>Appendix A.5. +Accessing Protected Resources</h3> + +<p> + The Consumer is now ready to request the private photo. Since the + photo URL is not secure (HTTP), it must use <tt>HMAC-SHA1</tt>. + +</p> + +<p><a name="sig_base_example"></a><br></p><hr> + +<p><a name="rfc.section.A.5.1"></a></p><h3>Appendix A.5.1. +Generating Signature Base String</h3> + +<p> + To generate the signature, it first needs to generate the Signature + Base String. The request contains the following parameters + (<tt>oauth_signature</tt> excluded) which are ordered and concatenated into + a normalized string: + + </p> +<blockquote class="text"><dl> +<dt>oauth_consumer_key:</dt> +<dd> + <tt>dpf43f3p2l4k3l03</tt> + +</dd> +<dt>oauth_token:</dt> +<dd> + <tt>nnch734d00sl2jdk</tt> + +</dd> +<dt>oauth_signature_method:</dt> +<dd> + <tt>HMAC-SHA1</tt> + +</dd> +<dt>oauth_timestamp:</dt> +<dd> + <tt>1191242096</tt> + +</dd> +<dt>oauth_nonce:</dt> +<dd> + <tt>kllo9940pd9333jh</tt> + +</dd> +<dt>oauth_version:</dt> +<dd> + <tt>1.0</tt> + +</dd> +<dt>file:</dt> +<dd> + <tt>vacation.jpg</tt> + +</dd> +<dt>size:</dt> +<dd> + <tt>original</tt> + +</dd> +</dl></blockquote><p> + +</p> + +<p> + The following inputs are used to generate the Signature Base String: + + </p> +<ol class="text"> +<li> + <tt>GET</tt> + +</li> +<li> + <tt>http://photos.example.net/photos</tt> + +</li> +<li> + <tt>file=vacation.jpg&oauth_consumer_key=dpf43f3p2l4k3l03&oauth_nonce=kllo9940pd9333jh&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1191242096&oauth_token=nnch734d00sl2jdk&oauth_version=1.0&size=original</tt> + +</li> +</ol><p> + +</p> + +<p> + The Signature Base String is: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal +</pre></div><p> + + +</p> + +<p><a name="anchor31"></a><br></p><hr> + +<p><a name="rfc.section.A.5.2"></a></p><h3>Appendix A.5.2. +Calculating Signature Value</h3> + +<p> + HMAC-SHA1 produces the following <tt>digest</tt> value as a base64-encoded + string (using the Signature Base String as <tt>text</tt> and + <tt> + kd94hf93k423kf44&pfkkdhi9sl3r4s00 + </tt> as <tt>key</tt>): + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> tR3+Ty81lMeYAr/Fid0kMTYa/WM= +</pre></div><p> + + +</p> + +<p><a name="anchor32"></a><br></p><hr> + +<p><a name="rfc.section.A.5.3"></a></p><h3>Appendix A.5.3. +Requesting Protected Resource</h3> + +<p> + All together, the Consumer request for the photo is: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> 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" +</pre></div><p> + + +</p> + +<p> + And if using query parameters: + + </p> +<div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre> 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 +</pre></div><p> + + +</p> + +<p> + photos.example.net checks the signature and responds with the + requested photo. + +</p> + +<p><a name="anchor33"></a><br></p><hr> + +<p><a name="rfc.section.B"></a></p><h3>Appendix B. +Security Considerations</h3> + +<p><a name="anchor34"></a><br></p><hr> + +<p><a name="rfc.section.B.1"></a></p><h3>Appendix B.1. +Credentials and Token Exchange</h3> + +<p> + 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 <a class="info" href="#request_grant">Section 6.1.2<span> (</span><span class="info">Service Provider Issues an Unauthorized Request Token</span><span>)</span></a> + and <a class="info" href="#access_grant">Section 6.3.2<span> (</span><span class="info">Service Provider Grants an Access Token</span><span>)</span></a>. Service Providers should ensure + that these transmissions are protected using transport-layer mechanisms + such as TLS or SSL. + +</p> + +<p><a name="anchor35"></a><br></p><hr> + +<p><a name="rfc.section.B.2"></a></p><h3>Appendix B.2. +PLAINTEXT Signature Method</h3> + +<p> + When used with <tt>PLAINTEXT</tt> signatures, the + OAuth protocol makes no attempts to protect User credentials from + eavesdroppers or man-in-the-middle attacks. + The <tt>PLAINTEXT</tt> 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 + <tt>PLAINTEXT</tt> signature method should not be + used. + +</p> + +<p><a name="anchor36"></a><br></p><hr> + +<p><a name="rfc.section.B.3"></a></p><h3>Appendix B.3. +Confidentiality of Requests</h3> + +<p> + 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. + +</p> + +<p><a name="anchor37"></a><br></p><hr> + +<p><a name="rfc.section.B.4"></a></p><h3>Appendix B.4. +Spoofing by Counterfeit Servers</h3> + +<p> + 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. + +</p> + +<p><a name="anchor38"></a><br></p><hr> + +<p><a name="rfc.section.B.5"></a></p><h3>Appendix B.5. +Proxying and Caching of Authenticated Content</h3> + +<p> + The <a class="info" href="#auth_header">HTTP Authorization scheme<span> (</span><span class="info">OAuth HTTP Authorization Scheme</span><span>)</span></a> is + optional. However, <a class="info" href="#RFC2616">[RFC2616]<span> (</span><span class="info">Fielding, +R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. +Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .</span><span>)</span></a> relies on the + <tt>Authorization</tt> and + <tt>WWW-Authenticate</tt> 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. + +</p> + +<p> + For example, private authenticated content may be stored in (and thus + retrievable from) publicly-accessible caches. Service Providers not + using the <a class="info" href="#auth_header">HTTP Authorization scheme<span> (</span><span class="info">OAuth HTTP Authorization Scheme</span><span>)</span></a> + should take care to use other mechanisms, such as the + <tt>Cache-Control</tt> header, to ensure that + authenticated content is protected. + +</p> + +<p><a name="anchor39"></a><br></p><hr> + +<p><a name="rfc.section.B.6"></a></p><h3>Appendix B.6. +Plaintext Storage of Credentials</h3> + +<p> + 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-<tt>PLAINTEXT</tt> + 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. + +</p> + +<p> + 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 + unauthorized access. + +</p> + +<p><a name="anchor40"></a><br></p><hr> + +<p><a name="rfc.section.B.7"></a></p><h3>Appendix B.7. +Secrecy of the Consumer Secret</h3> + +<p> + 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. + +</p> + +<p> + 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. + +</p> + +<p><a name="anchor41"></a><br></p><hr> + +<p><a name="rfc.section.B.8"></a></p><h3>Appendix B.8. +Phishing Attacks</h3> + +<p> + 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. + +</p> + +<p> + 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. + +</p> + +<p><a name="anchor42"></a><br></p><hr> + +<p><a name="rfc.section.B.9"></a></p><h3>Appendix B.9. +Scoping of Access Requests</h3> + +<p> + 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. + +</p> + +<p> + 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. + +</p> + +<p><a name="anchor43"></a><br></p><hr> + +<p><a name="rfc.section.B.10"></a></p><h3>Appendix B.10. +Entropy of Secrets</h3> + +<p> + Unless a transport-layer security protocol is used, eavesdroppers will + have full access to OAuth requests and signatures, and will thus 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. + +</p> + +<p> + 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. + +</p> + +<p> + 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. + +</p> + +<p><a name="anchor44"></a><br></p><hr> + +<p><a name="rfc.section.B.11"></a></p><h3>Appendix B.11. +Denial of Service / Resource Exhaustion Attacks</h3> + +<p> + 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. + +</p> + +<p> + 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. + +</p> + +<p> + 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. + +</p> + +<p><a name="anchor45"></a><br></p><hr> + +<p><a name="rfc.section.B.12"></a></p><h3>Appendix B.12. +Cryptographic Attacks</h3> + +<p> + SHA-1, the hash algorithm used in <tt>HMAC-SHA1</tt> + signatures, has been <a class="info" href="#SHA1">shown<span> (</span><span class="info">De Canniere, C. and C. Rechberger, “Finding SHA-1 Characteristics: General Results and Applications,” .</span><span>)</span></a> [SHA1] 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 <a class="info" href="#NIST">announced<span> (</span><span class="info">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,” .</span><span>)</span></a> [NIST] 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. + +</p> + +<p><a name="anchor46"></a><br></p><hr> + +<p><a name="rfc.section.B.13"></a></p><h3>Appendix B.13. +Signature Base String Compatibility</h3> + +<p> + 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. + +</p> + +<p> + 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. + +</p> + +<p><a name="rfc.references1"></a><br></p><hr> + +<h3>11. References</h3> + +<table border="0" width="99%"> +<tbody><tr><td class="author-text" valign="top"><a name="NIST">[NIST]</a></td> +<td class="author-text">National Institute of Standards and Technolog, NIST., “<a href="http://csrc.nist.gov/hash_standards_comments.pdf">NIST Brief Comments on Recent Cryptanalytic Attacks on Secure Hashing Functions and the Continued Security Provided by SHA-1</a>.”</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2045">[RFC2045]</a></td> +<td class="author-text">Freed, N. and N. Borenstein, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>,” RFC 2045.</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2104">[RFC2104]</a></td> +<td class="author-text">Krawczyk, H., Bellare, M., and R. Canetti, “<a href="http://tools.ietf.org/html/rfc2104">HMAC: Keyed-Hashing for Message Authentication</a>,” RFC 2104.</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td> +<td class="author-text">Bradner, B., “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” RFC 2119.</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2606">[RFC2606]</a></td> +<td class="author-text">Eastlake, D. and A. Panitz, “<a href="http://tools.ietf.org/html/rfc2606">Reserved Top Level DNS Names</a>,” RFC 2606.</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td> +<td class="author-text">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol – HTTP/1.1</a>,” RFC 2616.</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2617">[RFC2617]</a></td> +<td class="author-text">Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>,” RFC 2617.</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3447">[RFC3447]</a></td> +<td class="author-text">Jonsson, J. and B. Kaliski, “<a href="http://tools.ietf.org/html/rfc3447">Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1</a>,” RFC 3447.</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3629">[RFC3629]</a></td> +<td class="author-text">Yergeau, F., “<a href="http://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of Unicode and ISO 10646</a>,” RFC 3629.</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td> +<td class="author-text">Berners-Lee, T., “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifiers (URI): Generic Syntax</a>,” RFC 3986.</td></tr> +<tr><td class="author-text" valign="top"><a name="SHA1">[SHA1]</a></td> +<td class="author-text">De Canniere, C. and C. Rechberger, “<a href="http://dx.doi.org/10.1007/11935230_1">Finding SHA-1 Characteristics: General Results and Applications</a>.”</td></tr> +</tbody></table> + +<p><a name="rfc.authors"></a><br></p><hr> + +<h3>Author’s Address</h3> + +<table border="0" cellpadding="0" cellspacing="0" width="99%"> +<tbody><tr><td class="author-text"> </td> +<td class="author-text">OAuth Core Workgroup</td></tr> +<tr><td class="author" align="right">Email: </td> +<td class="author-text"><a href="mailto:spec@oauth.net">spec@oauth.net</a></td></tr> +</tbody></table> +<script type="text/javascript"> + var gaJsHost = (("https:" == document.location.protocol) ? + "https://ssl." : "http://www."); + document.write(unescape("%3Cscript src='" + gaJsHost + + "google-analytics.com/ga.js' +type='text/javascript'%3E%3C/script%3E")); +</script> +<script type="text/javascript"> + var pageTracker = _gat._getTracker("UA-31771-2"); + pageTracker._initData(); + pageTracker._trackPageview(); +</script> </body></html>
\ No newline at end of file |