| Network Working Group | B. de hOra |
| Internet-Draft | S. Farrell |
| Intended status: Standards Track | NewBay Software |
| Expires: August 26, 2010 | February 24, 2010 |
OAuth Access Tokens using credentials
draft-dehora-farrell-oauth-accesstoken-creds-02.txt
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.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
To provide feedback on this Internet-Draft, email the authors.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 26, 2010.
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 Simplified BSD License.
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.
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].
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.
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:
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.
To grant an access token, the Service Provider MUST ensure that:
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:
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.
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].
No IANA actions are required by this document.
version-00: initial draft.
version-01: added applicability statement and increased level of security required