Internet DRAFT - draft-dehora-farrell-oauth-accesstoken-creds
draft-dehora-farrell-oauth-accesstoken-creds
Network Working Group B. de hOra
Internet-Draft
Intended status: Standards Track S. Farrell
Expires: August 28, 2010 NewBay Software
February 24, 2010
OAuth Access Tokens using credentials
draft-dehora-farrell-oauth-accesstoken-creds-02.txt
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 August 28, 2010 [Page 1]
Internet-Draft OAuth Access Tokens using credentials February 2010
Editorial Note
To provide feedback on this Internet-Draft, email the authors.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 28, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
de hOra & Farrell Expires August 28, 2010 [Page 2]
Internet-Draft OAuth Access Tokens using credentials February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Client request to obtain an Access token . . . . . . . . . . . 7
4.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Accessing Protected Resources . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
de hOra & Farrell Expires August 28, 2010 [Page 3]
Internet-Draft OAuth Access Tokens using credentials February 2010
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 August 28, 2010 [Page 4]
Internet-Draft OAuth Access Tokens using credentials February 2010
2. Terminology
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].
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 August 28, 2010 [Page 5]
Internet-Draft OAuth Access Tokens using credentials February 2010
3. Applicability
This scheme is intended for use where one or both of the following
situations apply:
- the User is using a device that cannot play the HTTP re-direct game
normally played in the "3-legged" OAuth model
- the Consumer is an aggregator that will in any case, be presented
with the credentials of the end-user
If neither of the above apply, then this specification SHOULD NOT be
used.
In addition, the security considerations below MUST be followed, in
particular the requirement that communications between the Consumer
and Service Provider that contain the user's credentials MUST be sent
via a confidential and mutually authenticated channel. That channel
can be provided either via mutally-authenticated transport layer
security or a virtual private network providing equivalent security
functionality. See the security considerations section below for
details.
Once the Access Token has been acquired by the Consumer, then the
security requirements of standard OAuth apply.
de hOra & Farrell Expires August 28, 2010 [Page 6]
Internet-Draft OAuth Access Tokens using credentials February 2010
4. Client request to obtain an Access token
4.1. 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 use HTTP POST.
4.2. 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 August 28, 2010 [Page 7]
Internet-Draft OAuth Access Tokens using credentials February 2010
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 August 28, 2010 [Page 8]
Internet-Draft OAuth Access Tokens using credentials February 2010
5. 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.
When acquiring an Access Token via this scheme, the relevant
communications between the Consumer and Service Provider MUST be
strongly protected via a mutually authenticated and confidential
channel. Such a channel can be provided via the use of mutually
authenticated Transport Layer Security (TLS) [RFC5246] or an
equivalent lower layer virtual private network (VPN), for example a
tunnel-mode VPN based on IPsec. [RFC4301]
When HTTP is used over TLS, the conventions in [RFC2818] MUST be
followed.
Service 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 August 28, 2010 [Page 9]
Internet-Draft OAuth Access Tokens using credentials February 2010
6. IANA Considerations
No IANA actions are required by this document.
de hOra & Farrell Expires August 28, 2010 [Page 10]
Internet-Draft OAuth Access Tokens using credentials February 2010
7. 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.
[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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
de hOra & Farrell Expires August 28, 2010 [Page 11]
Internet-Draft OAuth Access Tokens using credentials February 2010
Appendix A. Revision History
version-00: initial draft.
version-01: added applicability statement and increased level of
security required
de hOra & Farrell Expires August 28, 2010 [Page 12]
Internet-Draft OAuth Access Tokens using credentials February 2010
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 August 28, 2010 [Page 13]
