OAuth standard protocol
OAuth is an open standard protocol for authorization that provides simple method of secure data exchange between applications. More specifically, OAuth enables end-users to authorize third-party access to their server resources using user-agent redirections. At the same time there is no necessity for users to share their credentials (e.g. username and password) with third-party web applications.
OAuth provides safe way to establish contact between two services and to interact with protected data. It is important to understand that this protocol is complementary but different from both OpenID and OATH. OAuth is protocol for authorized access to third party API, while OpenID is protocol for quick and simplified registration. OpenID allows user to obtain account at some service, if this user is already registered on other service. At the same time OAuth can not be identified with OATH, that is a reference architecture for authentication, not a standard.
There are two versions of OAuth: Core 1.0 Revision A and 2.0. Both of them have some specific characteristics and for more detailed information they need to be revised separately.
The OAuth Core 1.0a Protocol
Originally OAuth was developed to solve the issue of delegated access to protected resources. There are several parties that take part in the authorization process and OAuth uses the following terms:
Client: service capable of making protected resource requests on behalf of the resource owner.
Server: server that hosts the protected resources and can accept/respond to OAuth-authenticated requests using access tokens.
Protected resource: personal and access-restricted data that can be obtained from the server using an OAuth-authenticated request.
Resource owner (usually end-user, if it is a person): an entity capable of granting access to a protected resource by using credentials to authenticate with the server.
Provider API: server API that allows to get protected data.
Token: a unique identifier issued by the server and applied by the client to associate authenticated requests with the resource owner.
OAuth adds a third party to the traditional client-server authentication model: the resource owner. In this new model the client is not the owner of resources hosted on the server and only acts on its behalf. In response to the OAuth-authenticated request server verifies not only the resource owner authorization, but also the identity of the client making the request.
Resource owner has to give permission to the client to access resources. Token is used as the means for this permission, thus there is no reason for the client to give its credentials to the HTTP client. The main advantages of token over the credentials are its specific scope, limited lifetime, and other access attributes.
The OAuth 2.0 Authorization Framework
OAuth 2.0 is the continuation of OAuth project and is not backwards compatible with OAuth 1.0. The two versions may co-exist on the network and services may choose to support both of them. OAuth 2.0 is more of a framework than it is a defined protocol. It enables a third-party services to get limited access to an HTTP service either on its own behalf, or on behalf of a resource owner (via approval interaction between the resource owner and the HTTP service). OAuth 2.0 has security drawbacks, e.g. doesn't have support for signature, encryption, client verification, or channel binding. It relies completely on SSL for some degree of confidentiality and server authentication.
Difference between OAuth 1.0a and 2.0
Though OAuth 1.0a and 2.0 are developed to solve almost the same basic set of authorization issues, they are two completely different protocols and have their own pros and cons.
OAuth 2.0 distinctly separates roles between the server responsible for handling OAuth requests and the server handling user authorization. OAuth 2.0 provides more choices in issuing access tokens (e.g. Bearer tokens, MAC tokens).
OAuth 2.0 better handles scaling, no longer requires client applications to have cryptography and signatures, that both improves user experience and simplifies programmers work. No more special parsing, sorting, or encoding, everything is based on SSL. When the token has been generated, OAuth 1.0a required that the client send two security tokens on every API call, and they both had to be used to generate the signature. In case of OAuth 2.0, it has only one security token, and no signature is required.
At the same time SSL is not very secure and not all APIs or devices want to support it either for performance, or for complexity reasons. Moreover, OAuth 2.0 access tokens are short-lived, while OAuth 1.0 access tokens can be stored for a year or more. Each web service can have one or both OAuth protocols, depending on its specifications.