OAuth 2.0 Protocol
With the increasing use of distributed web services and cloud computing, third-party applications require access to server-hosted resources. These resources are usually protected and require authentication using the resource owner’s credentials (typically a username and password).
In the traditional client-server authentication model, the client accesses a protected resource on the server by authenticating with the server using the resource owner’s credentials. In order to provide third-party applications access to protected resources, the resource owner shares its 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-
- Servers are required to support password (symmetric) authentication, despite the security weaknesses created by
- Third-party applications gain overly broad access to the resource-owner’s protected resources, leaving resource owners without any ability to restrict access to a limited subset of resources, to limit access duration, or to limit access to the methods supported by these resources.
- Resource owners cannot revoke access to an individual third-party without revoking access to all third-parties, and must do so by changing their password.
OAuth address these issues by separating the role of the client from that of the resource owner. In OAuth, the client (which is usually not the resource owner, but is acting on the resource owner’s behalf) requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.
Instead of using the resource owner’s credentials to access protected resources, clients obtain an access token (a string which denotes a specific scope, duration, and other attributes).
Please see the original IETF Internet Draft to get more information.