Network Working Group B. de hOra Internet-Draft Expires: April 30, 2009 S. Farrell NewBay Software October 27, 2008 OAuth Access Tokens using credentials draft-dehora-farrell-oauth-accesstoken-creds-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 30, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). de hOra & Farrell Expires April 30, 2009 [Page 1] Internet-Draft OAuth Access Tokens using credentials October 2008 Abstract OAuth Access Tokens using credentials is a technique for allowing user agents to obtain an OAuth access token on behalf of a user without requiring user intervention or HTTP redirection to a browser. OAuth itself is documented in the OAuth Core 1.0 Specification. de hOra & Farrell Expires April 30, 2009 [Page 2] Internet-Draft OAuth Access Tokens using credentials October 2008 Editorial Note To provide feedback on this Internet-Draft, email the authors. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Client request to obtain an Access token . . . . . . . . . . . 7 4.1. Authentication Request . . . . . . . . . . . . . . . . . . 7 4.2. Authentication Response . . . . . . . . . . . . . . . . . 7 4.3. Accessing Protected Resources . . . . . . . . . . . . . . 8 5. Securing Requests . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 de hOra & Farrell Expires April 30, 2009 [Page 3] Internet-Draft OAuth Access Tokens using credentials October 2008 1. Introduction The [OAUTH] Specification is a protocol that enables websites or applications to access protected web resources via an API, without requiring users to disclose their credentials. This draft defines a technique for allowing a user to provide their crendentials in cases where HTTP redirection to a browser is unavailable or unsuitable, such as intermediary aggregators and mobile or settop devices. de hOra & Farrell Expires April 30, 2009 [Page 4] Internet-Draft OAuth Access Tokens using credentials October 2008 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. de hOra & Farrell Expires April 30, 2009 [Page 5] Internet-Draft OAuth Access Tokens using credentials October 2008 3. Terminology o Access Token - As defined by [OAUTH], 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. o Service Provider -As defined by [OAUTH], a web application that allows access via OAuth. o User - As defined by [OAUTH], an individual who has an account with the Service Provider. o Consumer - As defined by [OAUTH], a website or application that uses OAuth to access the Service Provider on behalf of the User. o Protected Resource(s) - As defined by [OAUTH], data controlled by the Service Provider, which the Consumer can access through authentication . o Consumer Key - As defined by [OAUTH], a value used by the Consumer to identify itself to the Service Provider. o Consumer Secret -As defined by [OAUTH], a secret used by the Consumer to establish ownership of the Consumer Key. o Request Token -As defined by [OAUTH], a value used by the Consumer to obtain authorization from the User, and exchanged for an Access Token. o Token Secret - A secret used by the Consumer to establish ownership of a given Token. o OAuth Protocol Parameters - Parameters with names beginning with oauth. de hOra & Farrell Expires April 30, 2009 [Page 6] Internet-Draft OAuth Access Tokens using credentials October 2008 4. Client request to obtain an Access token 4.1. Authentication Request To request an Access Token in this model, the Consumer makes an HTTP request to the Service Provider's Access Token URL. The authentication request contains the following parameters: o x_auth_username - the login credential of the User the client is obtaining a token on behalf of. o x_auth_password - the pass credential of the User the client is obtaining a token on behalf of. o x_auth_mode - this value must "client_auth" (referring to the process described here) o oauth_consumer_key - as defined by [OAUTH]. o oauth_signature_method - as defined by [OAUTH]. o oauth_signature - as defined by [OAUTH] o oauth_timestamp - as defined by [OAUTH] o oauth_nonce - as defined by [OAUTH] o oauth_version - the client MAY send this parameter. If present, value MUST be 1.0 . Service Providers MUST assume the protocol version to be 1.0 if this parameter is not present. The above parameters are contained in the HTTP Authorisation header or as URL parameters. Parameter names and values must be "percent- encoded" to handle characters in different character sets. The request SHOULD be performed using TLS, and SHOULD use HTTP POST. 4.2. Authentication Response To grant an access token, the Service Provider MUST ensure that: o The request signature has been successfully verified as per [OAUTH]. o A request with the supplied timestamp and nonce has never been received before. o The supplied username and password match a User's credentials. de hOra & Farrell Expires April 30, 2009 [Page 7] Internet-Draft OAuth Access Tokens using credentials October 2008 If successful, the Service Provider generates an Access Token and Token Secret using a 200 Ok response and returns them in the HTTP response body. The response contains the following parameters: o oauth_token - The Access Token. o oauth_token_secret - The Token Secret. o x_auth_expires - a timestamp, in seconds since 1970-01-01T00:00, at which the Access Token expires, or 0 if no expiry is specified. o Additional parameters- Any additional parameters, as defined by the Service Provider. 4.3. Accessing Protected Resources After successfully receiving the Access Token and Token Secret, the Consumer is able to access the Protected Resources on behalf of the User as per section 7 of [OAUTH]. In other words the Access Token obtained here is no different in capability to the Access Token specified by [OAUTH]. Once authenticated using the above process, the Consumer will sign all subsequent requests for the User's Protected Resources using the returned Token Secret. de hOra & Farrell Expires April 30, 2009 [Page 8] Internet-Draft OAuth Access Tokens using credentials October 2008 5. Securing Requests To support this technique, at a minimum, Consumer and Service Provider implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a connection made with TLS 1.0 [RFC2246] or a subsequent standards-track version of TLS (such as [RFC4346]), supporting the conventions for using HTTP over TLS described in [RFC2818]. Server Providers are advised to respond to unauthorized or unauthenticated requests using an appropriate 4xx HTTP response code (e.g., 401 "Unauthorized" or 403 "Forbidden") in accordance with [RFC2617]. de hOra & Farrell Expires April 30, 2009 [Page 9] Internet-Draft OAuth Access Tokens using credentials October 2008 6. Security Considerations The authentication technique described here is based on HTTP and thus subject to the security considerations found in Section 15 of [RFC2616]. Sending a user name and password pair is contrary to the idea in [OAUTH] that a Consumer will not know the User's credentials. However without some way to transmit the credentials, there is no way to utilise [OAUTH] in scenarios where redirects to the Service Provider cannot be performed dynamically. de hOra & Farrell Expires April 30, 2009 [Page 10] Internet-Draft OAuth Access Tokens using credentials October 2008 7. IANA Considerations No IANA actions are required by this document. de hOra & Farrell Expires April 30, 2009 [Page 11] Internet-Draft OAuth Access Tokens using credentials October 2008 8. Normative References [OAUTH] Atwood, M., Conlan, R., Cook, B., Elliott-McCrea, K., Halff, L., Hammer-Lahav, E., Laurie, B., Messina, C., Panzer, J., Quigley, S., Recordon, D., Sandler, E., Sergent, J., Sieling, T., Slesinsky, B., and A. Smith, "OAuth Core 1.0", December 2007, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. de hOra & Farrell Expires April 30, 2009 [Page 12] Internet-Draft OAuth Access Tokens using credentials October 2008 Appendix A. Revision History Rev draft-ietf-client-oauth-credentials-00: initial draft. de hOra & Farrell Expires April 30, 2009 [Page 13] Internet-Draft OAuth Access Tokens using credentials October 2008 Authors' Addresses Bill de hOra Email: bill@dehora.net URI: http://dehora.net/ Stephen Farrell NewBay Software Email: sfarrell@newbay.com URI: http://www.newbay.com de hOra & Farrell Expires April 30, 2009 [Page 14] Internet-Draft OAuth Access Tokens using credentials October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). de hOra & Farrell Expires April 30, 2009 [Page 15]