This link has been bookmarked by 71 people . It was first bookmarked on 06 Dec 2007, by Terry Jones.
-
02 Dec 11
-
- Parameter names and values are encoded per Parameter Encoding (Parameter Encoding).
- 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).
- Parameters are separated by a comma character (ASCII code 44) and OPTIONAL linear whitespace per [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .).
- The OPTIONAL realm parameter is added and interpreted per [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .), section 1.2.
5.4.1. Authorization Header
The OAuth Protocol Parameters are sent in the Authorization header the following way:
For example:
Authorization: OAuth realm="http://sp.example.com/", oauth_consumer_key="0685bd9184jfhq22", oauth_token="ad180jjd733klru7", oauth_signature_method="HMAC-SHA1", oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D", oauth_timestamp="137131200", oauth_nonce="4572616e48616d6d65724c61686176", oauth_version="1.0"
-
-
12 Jun 11
-
08 Apr 11
-
06 Apr 11
-
18 Jan 11
-
27 Oct 10
-
15 Oct 10
-
27 May 10
-
07 Apr 10
-
21 Jan 10
-
07 Sep 09
-
23 Aug 09
-
11 Jun 09
-
15 Apr 09
-
05 Apr 09
s_bergmannThe 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
-
15 Mar 09
-
11 Mar 09
-
- The Consumer obtains an unauthorized Request Token.
- The User authorizes the Request Token.
- The Consumer exchanges the Request Token for an Access Token.
-
-
6.2.1. Consumer Directs the User to the Service Provider
In order for the Consumer to be able to exchange the Request Token for an Access Token, the Consumer MUST obtain approval from the User by directing the User to the Service Provider. The Consumer constructs an HTTP GET request to the Service Provider’s User Authorization URL with the following parameter:
- oauth_token:
- OPTIONAL. The Request Token obtained in the previous step. The Service Provider MAY declare this parameter as REQUIRED, or accept requests to the User Authorization URL without it, in which case it will prompt the User to enter it manually.
- oauth_callback:
- OPTIONAL. The Consumer MAY specify a URL the Service Provider will use to redirect the User back to the Consumer when Obtaining User Authorization (Obtaining User Authorization) is complete.
- Additional parameters:
- Any additional parameters, as defined by the Service Provider.
Once the request URL has been constructed the Consumer redirects the User to the URL via the User’s web browser. If the Consumer is incapable of automatic HTTP redirection, the Consumer SHALL notify the User how to manually go to the constructed request URL.
-
- 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.
- 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.
- 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.
-
To request an Access Token, the Consumer makes an HTTP request to the Service Provider’s Access Token URL. The Service Provider documentation specifies the HTTP method for this request, and HTTP POST is RECOMMENDED. The request MUST be signed per Signing Requests (Signing Requests), and contains the following parameters:
-
If successful, the Service Provider generates an Access Token and Token Secret and returns them in the HTTP response body as defined in Service Provider Response Parameters (Service Provider Response Parameters). The Access Token and Token Secret are stored by the Consumer and used when signing Protected Resources requests. The response contains the following parameters:
- oauth_token:
- The Access Token.
- oauth_token_secret:
- The Token Secret.
-
After successfully receiving the Access Token and Token Secret, the Consumer is able to access the Protected Resources on behalf of the User. The request MUST be signed per Signing Requests (Signing Requests), and contains the following parameters:
- oauth_consumer_key:
- The Consumer Key.
- oauth_token:
- The Access Token.
- oauth_signature_method:
- The signature method the Consumer used to sign the request.
- oauth_signature:
- The signature as defined in Signing Requests (Signing Requests).
- oauth_timestamp:
- As defined in Nonce and Timestamp (Nonce and Timestamp).
- oauth_nonce:
- As defined in Nonce and Timestamp (Nonce and Timestamp).
- oauth_version:
- OPTIONAL. If present, value MUST be 1.0. Service Providers MUST assume the protocol version to be 1.0 if this parameter is not present. Service Providers’ response to non-1.0 value is left undefined.
-
The HMAC-SHA1 signature method uses the HMAC-SHA1 signature algorithm as defined in [RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .) where the Signature Base String is the text and the key is the concatenated values (each first encoded per Parameter Encoding (Parameter Encoding)) of the Consumer Secret and Token Secret, separated by an ‘&’ character (ASCII code 38) even if empty.
-
Appendix B.1. Credentials and Token Exchange
The OAuth specification does not describe any mechanism for protecting Tokens and secrets from eavesdroppers when they are transmitted from the Service Provider to the Consumer in Section 6.1.2 (Service Provider Issues an Unauthorized Request Token) and Section 6.3.2 (Service Provider Grants an Access Token). Service Providers should ensure that these transmissions are protected using transport-layer mechanisms such as TLS or SSL.
-
Appendix B.4. Spoofing by Counterfeit Servers
OAuth makes no attempt to verify the authenticity of the Service Provider. A hostile party could take advantage of this by intercepting the Consumer’s requests and returning misleading or otherwise incorrect responses. Service providers should consider such attacks when developing services based on OAuth, and should require transport-layer security for any requests where the authenticity of the Service Provider or of request responses is an issue.
-
Appendix B.5. Proxying and Caching of Authenticated Content
The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is optional. However, [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .) relies on the Authorization and WWW-Authenticate headers to distinguish authenticated content so that it can be protected. Proxies and caches, in particular, may fail to adequately protect requests not using these headers.
For example, private authenticated content may be stored in (and thus retrievable from) publicly-accessible caches. Service Providers not using the HTTP Authorization scheme (OAuth HTTP Authorization Scheme) should take care to use other mechanisms, such as the Cache-Control header, to ensure that authenticated content is protected.
-
Appendix B.9. Scoping of Access Requests
By itself, OAuth does not provide any method for scoping the access rights granted to a Consumer. A Consumer either has access to Protected Resources or it doesn’t. Many applications will, however, require greater granularity of access rights. For example, Service Providers may wish to make it possible to grant access to some Protected Resources but not others, or to grant only limited access (such as read-only access) to those Protected Resources.
When implementing OAuth, Service Providers should consider the types of access Users may wish to grant Consumers, and should provide mechanisms to do so. Service Providers should also take care to ensure that Users understand the access they are granting, as well as any risks that may be involved.
-
-
10 Mar 09
-
09 Feb 09
-
09 Jan 09
-
13 Nov 08
-
03 Nov 08
Niko SchmuckSpecification of the oAuth Protocol as new authentication framework (with sample code for many languages available).
reference documentation security webservices design architecture authentication api identity specification
-
Hugo ZondaSpecification of the oAuth Protocol as new authentication framework (with sample code for many languages available).
reference documentation security webservices design architecture authentication api identity specification
-
08 Oct 08
-
23 Sep 08
lgsiigoThe 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
-
19 Sep 08
-
15 Sep 08
-
07 Sep 08
-
The protocol defines three signature methods: HMAC-SHA1, RSA-SHA1, and PLAINTEXT, but Service Providers are free to implement and document their own methods.
-
The URL used in the Signature Base String MUST include the scheme, authority, and path, and MUST exclude the query and fragment as defined by [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) section 3.
-
Unless specified, URL scheme and authority MUST be lowercase and include the port number; http default port 80 and https default port 443 MUST be excluded.
-
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.
-
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
-
SHA-1, the hash algorithm used in HMAC-SHA1 signatures, has been shown (De Canniere, C. and C. Rechberger, “Finding SHA-1 Characteristics: General Results and Applications,” .) [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 announced (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,” .) [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
-
-
27 Aug 08
-
25 Jul 08
-
29 Jun 08
-
03 Jun 08
-
14 May 08
Mike KossOAuth spec. OAuth is used within FriendConnect to transfer permissions to access data on one site, while visiting another. Quoted: The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service
-
29 Apr 08
-
22 Mar 08
-
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.
-
-
jeremiah hesterOAuth creates a freely-implementable and generic methodology for API authentication
-
21 Feb 08
-
14 Feb 08
-
14 Jan 08
-
07 Jan 08
-
03 Jan 08
-
06 Dec 07
-
05 Dec 07
-
Ludovico MagnocavalloThe 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
-
Daniel AndrlikFinal spec for OAuth. I like a lot of what I see, and I'm looking forward to seeing this getting used widely as an alternative to consumers storing login credentials.
-
04 Dec 07
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.