Fundamental Authorization Problem
With the growth of web and ever increasing usage of web services and cloud computing , has lead to different applications interacting with each other. As most of the interaction requires server to authorize and suthenticate the client request, which in turn involves an exchange of usernames and passwords. Like a photo lab printing your Flickr photos, a social networking app using your Google address book to look for friends
The problem is, in order for these applications to access user data on other sites, they ask for usernames and passwords. Not only does this require exposing user passwords to someone else – often the same passwords used for online banking and other sites – it also provides these application unlimited access to do as they wish. They can do anything, including changing the passwords and lock users out.
Traditional Client-Server Authentication Model
In the traditionl client-server authentication model, the client requests an access to a restricted resource ( protected resource ) on the server using resource owner's credentials. In order to provide the third party access to the restricted resources, the resource's owner shares its authentication credentials with the third party. This creates several problems and limitations :
Third party applications are required to store the resource owner's credentials for future use, typically a password in clear-text.
Third party applications gain complete overly broad access to the resources owned by the owner, leaving resource owner without any control over, either limiting the time period of access or limiting the subset of protected resources that can be accessed by the third party. In a way, the third party applications gains complete access control over the restricted resources.
Resource owner cannot revoke access to third party applications without changing the authentication password to the restricted resources. Changing password to revoke access to a particular third party , also revokes access to all the third parties, which again may not be the desirable to the resource owner.So the resource owner has no control over 'selective' revokation to access to is protected resource.
Risk of password leak or misuse by third party applications
OAuth addresses this issues by introducing an authorization layer and thus separating role of the client from that of the resource owner.In OAuth , the client uses a different set of credentials other than resource owner's credentials.
The client, instead of using resource owner's credentials, uses rather something called 'access tokens'. An access token is a string that denotes some access attributes like access scope, access time period. Access tokens are issued to the third party applications with the approval of the resource owner. These tokens are then used by the third party applications to gain access to the resource owner's protected resources.
For example, an end-user ( resource owner ) can grant a third party Facebook application ( client ) a valid access to his Gtalk Friend's List ( protected resource ), without sharing his google account ( server ) username and password with the third party Facebook application. Instead he authenicates his google account credentials with trusted authentication server, which then issues access tokens to the facebook application.