]>

bill@dehora.net http://dehora.net/

NewBay Software

sfarrell@newbay.com http://www.newbay.com

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. To provide feedback on this Internet-Draft, email the authors.

The 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 . Access Token - As defined by , 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. Service Provider -As defined by , a web application that allows access via OAuth. User - As defined by , an individual who has an account with the Service Provider. Consumer - As defined by , a website or application that uses OAuth to access the Service Provider on behalf of the User. Protected Resource(s) - As defined by , data controlled by the Service Provider, which the Consumer can access through authentication . Consumer Key - As defined by , a value used by the Consumer to identify itself to the Service Provider. Consumer Secret -As defined by , a secret used by the Consumer to establish ownership of the Consumer Key. Request Token -As defined by , a value used by the Consumer to obtain authorization from the User, and exchanged for an Access Token. Token Secret - A secret used by the Consumer to establish ownership of a given Token. OAuth Protocol Parameters - Parameters with names beginning with oauth.

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: x_auth_username - the login credential of the User the client is obtaining a token on behalf of. x_auth_password - the pass credential of the User the client is obtaining a token on behalf of. x_auth_mode - this value must "client_auth" (referring to the process described here) oauth_consumer_key - as defined by . oauth_signature_method - as defined by . oauth_signature - as defined by oauth_timestamp - as defined by oauth_nonce - as defined by 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.

To grant an access token, the Service Provider MUST ensure that: The request signature has been successfully verified as per . A request with the supplied timestamp and nonce has never been received before. The supplied username and password match a User's credentials. 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: oauth_token - The Access Token. oauth_token_secret - The Token Secret. 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. Additional parameters- Any additional parameters, as defined by the Service Provider.

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 . In other words the Access Token obtained here is no different in capability to the Access Token specified by . 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 . Sending a user name and password pair is contrary to the idea in that a Consumer will not know the User's credentials. However without some way to transmit the credentials, there is no way to utilise 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) or an equivalent lower layer virtual private network (VPN), for example a tunnel-mode VPN based on IPsec. When HTTP is used over TLS, the conventions in 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 .

No IANA actions are required by this document.

&rfc2119; &rfc2616; &rfc2617; &rfc2818; &RFC4301; &RFC5246;

version-00: initial draft. version-01: added applicability statement and increased level of security required