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,
<http://oauth.net/core/1.0>.
[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
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]