Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using your regular key to unlock everything.
Everyday new website offer services which tie together functionality from other sites. A photo lab printing your online photos, a social network using your address book to look for friends, and APIs to build your own desktop application version of a popular site. These are all great services – what is not so great about some of the implementations available today is their request for your username and password to the other site. When you agree to share your secret credentials, not only you expose your password to someone else (yes, that same password you also use for online banking), you also give them full access to do as they wish. They can do anything they wanted – even change your password and lock you out.
OAuth allows the you, the User, to grant access to your private resources on third party site (which is called the Service Provider), to another site (called Consumer, not to be confused with you, the User), without sharing their access permissions or the full extent of their data. Each token grants access to a specific site (e.g. a video editing site) for specific resources (e.g. just videos from a specific album) and for a defined duration (e.g. the next 2 hours).
The promoted/used by Twitter, Digg & even biggies like Google & Yahoo.
[Refer:- http://oauth.net/about/]
Twitter provides ‘Sign-in with Twitter’, the ability to use Twitter as a delegated sign-in provider for third-party websites. This feature asks third party site for their Twitter username and password, and then use these credentials to make an authenticated API call. If the call is successful, they know the user is really who they claim to be and let them use the service. The sites will no longer need to handle Twitter passwords, store them, protect them, and deal with the legal consequences.
If you are extending an existing service, implementing a specific API and building a site that has great dependencies on another service, OAuth gives you everything you need, for very little extra work. Glossary :
- Service Provider – the Service Provider controls all aspects of the OAuth implementation. The Service Provider is the term used to describe the website or web-service where the restricted resources are located. It can be a photo sharing site where users keep albums, an online bank service, a microblogging site, or any other service where ‘user’s private stuff’ is kept. OAuth does not mandate that the Service Provider will also be the identity provider which means the Service Provider can use its own usernames and passwords to authenticate users, or use other systems such as OpenID.
- User – the user is why OAuth exists and without users, there is no need for OAuth. The users have ‘stuff’ they don’t want to make public on the Service Provider, but they do want to share it with another site. In OAuth, the protocol stops without manual interaction with the user at least once to receive permission to grant access.
- Consumer – this is a fancy name for an application trying to access the User’s resources. This can be a website, a desktop program, a mobile device, a set-top box, or anything else connected to the web. The Consumer is the one getting permission to access resources and the Consumer is where the useful part of OAuth happens. OAuth defines ‘Consumer Developer’ as the entity writing code to interact with the Service Provider.
- ‘Consumer Key’ and ‘Consumer Secret’/'Shared Secret '- obtained by Consumer on registering with SP
- Request Token: received by Consumer when the CK & CS are send to SP for access request. This is send along with the redirection of the user to the authorization page of SP.
- OAuth Verifier: Send back by SP when user authorizes Consumer thru SP's page (post login in SP's site)
- Access Token (OAuth token) & Token Secret: send by SP when Consumer sends it's Verifier, CK & CS for access to Consumer authorized resource at SP's site
- Protected Resources: the ‘stuff’ OAuth protects and allow access to. This can be data (photos, documents, contacts), activities (posting blog item, transferring funds) or any URL with a need for access restrictions.
- Tokens – are used instead of User credentials to access resources. A Token is generally a random string of letters and numbers (but not limited to) that is unique, hard to guess, and paired with a Secret to protect the Token from being abused. OAuth defines two different types of Tokens: Request and Access.
http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-ii-protocol-workflow/
Security Process Concepts:
http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iii-security-architecture/
Visualizing the Security handshake between SP & Consumer:
http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/
Official Site:
http://oauth.net/
Getting Started:
http://oauth.net/documentation/getting-started/
http://hueniverse.com/oauth/
The Guide:
http://hueniverse.com/oauth/guide/
Discussion Group:
http://groups.google.com/group/oauth?pli=1
Spec:
OAuth Core 1.0 was released December 4, 2007.
OAuth Core 1.0 Revision A was released June 24, 2009.
No comments:
Post a Comment