What does OAuth really mean?
Well, lets break the above description down into some key phrases and the pieces should come together.
A "Protocol" is a standardized method for the communication of two computers. For instance HTTP is the standardized way of a webserver communicating with your computer when you browse a website.
"Open” comes from the fact that this protocol is open source and can be viewed, downloaded, and maintained by anyone who is willing to take up the torch.
“Secure API authorization” is the functionality that OAuth.net gives to its stakeholders - the ability for a developer to download OAuth.net and secure their API access without having to write a unique (and possibly bug filled) authentication!
The key tenet of these schemes and of OAuth is that users should be able to share their data with third-party applications without sharing their passwords.
OAuth allows you to share your private resources (photos, videos, contact list, bank accounts) stored on one site with another site without having to hand out your username and password. There are many reasons why one should not share their private credentials. Giving your email account password to a social network site so they can look up your friends is the same thing as going to dinner and giving your ATM card and PIN code to the waiter when it’s time to pay. Any restaurant asking for your PIN code will go out of business, but when it comes to the web, users put themselves at risk sharing the same private information. OAuth to the rescue.
Both the valet key and ATM cards are good metaphors for OAuth from a user perspective. Instead of giving your ATM card and PIN code, the card can double as a credit card with a signature authorization. Just like your username and password provide full access to your resources, your ATM card and PIN code provide you with great control over your bank accounts – much more than just charging goods. But when you replace the PIN code with your signature, the card becomes very limited and can only be used for limited access.
Users don’t care about protocols and standards – they care about better experience with enhanced privacy and security. This is exactly what OAuth sets to achieve. With web services on the rise, people expect their services to work together in order to accomplish something new. Instead of using a single site for all their online needs, users use one site for their photos, another for videos, another for email, and so on. No one site can do everything better. In order to enable this kind of integration, sites need to access the user resources from other sites, and those are many times protects (private family photos, work documents, bank records). They need a key to get in.
The key used by users is usually a combination of username and password. This can be an OpenID or any other login credential. But this key is too powerful and unrestrictive to share around. It also cannot be unshared once handed out except for changing it which will void access to every site, not just the one the user intends to block. OAuth addresses that by allowing users to hand out tokens instead. Each token grants access to a specific site (a video editing site) for specific resources (just videos from last weekend) and for a defined duration (the next 2 hours).
Unlike OpenID where users must do something first - get an OpenID identity they can use to sign-into sites – OAuth is completely transparent to the users. In many cases (if done right), the end-user will not know anything about OAuth, what it is or how it works. The user experience will be specific to the implementation of both the site requesting access and the one storing the resources, and adjusted to the device being used (web browser, mobile phone, PDA, set-top box).
A typical example is when a user wants to print a photo stored on another site. The interaction goes something like this: the user signs into the printer website and place an order for prints. The printer website asks which photos to print and the user chooses the name of the site where her photos are stored (from the list of sites supported by the printer). The printer website sends the user to the photo site to grant access. At the photo site the user signs into her account and is asked if she really wants to share her photos with the printer. If she agrees, she is sent back to the printer site which can now access the photos. At no point did the user share her username and password with the printer site.
Some Definitions
Service Provider: A web application that allows access via OAuth.
User: An individual who has an account with the Service Provider.
Consumer: A website or application that uses OAuth to access the Service Provider on behalf of the User.
Protected Resource(s): Data controlled by the Service Provider, which the Consumer can access through authentication.
Consumer Developer: An individual or organization that implements a Consumer.
Consumer Key: A value used by the Consumer to identify itself to the Service Provider.
Consumer Secret: A secret used by the Consumer to establish ownership of the Consumer Key. Request Token: A value used by the Consumer to obtain authorization from the User, and exchanged for an Access Token.
Access Token: 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.
Token Secret: A secret used by the Consumer to establish ownership of a given Token.
OAuth Protocol Parameters: Parameters with names beginning with oauth_.
There are some libraries develolped for implementing OAUTH. I recommennd DNOA (DontNetOpenAuth) written by Andrw Arnott. You can even get the Full source code of this including Mock tests as it is Open Source.
I have implemented OAuth and OpenID in one of my project using this DotNetOpenAuth library. To get it please write to me at cybertechie.india@gmail.com
No comments:
Post a Comment