web developer & system programmer

coder . cl

ramblings and thoughts on programming...


understanding oauth

published: 20-04-2011 / updated: 20-04-2011
posted in: algorithms, development, programming, projects, tips
by Daniel Molina Wegener

“An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications”. The basis of OAuth protocol, is to allow applications to share its user resources or data among third party applications without sharing the user credentials. It is done using authentication tokens, allowing certain applications to expose its API to other desktop applications and web based applications. The protocol was created with the purpose to solve the problem of enabling delegated access to protected resources.

The basic behavior of this Authentication Protocol, is made through HTTPS requests. Initial, the consumer requests a temporary token — for example gravatar.com accessing your facebook.com account data is a consumer —, called request token. With the request token, the oauth_callback parameter is sent, which holds the callback URL that will be triggered once the user or resource owner authorizes the consumer to access its resources.

OAuth User

OAuth User

The Consumer never has real user credentials, it only has temporary Authentication Tokens to be used to access the User or Resource Owner resources.

OAuth Consumer

OAuth Consumer

A classic example, is Twitter allowed third party applications. To take a look on which applications are accessing to your Twitter account, you must go to the Settings section, and click on the Connections panel. You will see some applications like Twitpic, Gravatar and Twitcam.com.

OAuth Behavior

OAuth Behavior

The first step, is to build and send the Request Token from the Consumer to the Service Provider. This is made using a simple HTTPS request with the OAuth authentication mechanism enabled on the application.

 POST /initiate HTTP/1.1
 Host: some.service.com
 Authorization: OAuth realm="SomeService",
    oauth_consumer_key="dpf43f3p2l4k3l03",
    oauth_signature_method="HMAC-SHA1",
    oauth_timestamp="137131200",
    oauth_nonce="wIjqoS",
    oauth_callback="http%3A%2F%2Fsome.service.com%2Fready",
    oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"

The initial parameters on the Request Token are the consumer key, an unique identifier of the consumer, that should be stored on the Service Provider application to identify its authorized consumers, for example Twitpic.com on Twitter has its own consumer key. The signature method should be HMAC-SHA1 [ref. RFC2104] or RSA-SHA1 [ref. RFC3447, Sec 8.2], where the first one uses a simple cryptographic hash algorithm and second one requires the PKI RSA standard. You can use PLAINTEXT, but it is not recommended and not commonly recognized. The timestamp holds the request timestamp — on those timestamp friendly days where here in Chile we were playing with timezones the wrong timestamp was generating some problems on certain applications. The oauth_nonce is:

A nonce is a random string, uniquely generated by the client to allow the server to verify that a request has never been made before and helps prevent replay attacks when requests are made over a non-secure channel.

The oauth_callback argument is the callback URL that will be triggered once the user authorizes the consumer to access its resources, and the oauth_signature is the algorithm described by the signature_method argument applied to the URL base string, which is made concatenating the request method (or HTTP verb) and the full URL encoded with all OAuth arguments, except the oauth_signature argument.

Once the Request Token HTTPS request is made, the server returns the oauth_token, oauth_token_secret and oauth_callback_confirmed parameters to the consumer with the form of application/x-www-form-urlencoded content type. Where the consumer must handle those arguments and build the local object containing the OAuth Request Token, then with that token, the consumer request the Authorization URL on the Service Provider endpoint, and it should be triggered by the User — from a standard browser or his desktop application — and then the User or Resource Owner authorizes the consumer application to use its resources.

Once the Consumer is authorized by the User or Resource Owner, is triggered the Consumer provided callback URL on the oauth_callback argument, but it is triggered from the Service Provider application with the oauth_token and the oauth_verifier to construct the subsequent Resource Requests.

This protocol is very simple and useful, and it is having a wide adoption between a lot of web sites. It is not an official standard yet, but is becoming a new authentication standard for many web based applications.


references


No coments yet.

post a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>