Page Comparison

...

OAuth was created to solve the problem of sharing two-legged credentials in three-legged situations. However, within the OAuth context, Consumers consumers might still need to communicate with the Service Provider using requests that are Consumerconsumer-specific. Since the Consumers consumers already established a Consumer Key and Consumer Secret, there is value in being able to use them for requests where the Consumer consumer identity is being verified.

OAuth 1.0

This specification defines how 2-legged OAuth works with OAuth 1.0. But However it never became an IETF RFC.

With OAuth 1.0 - , 2-legged OAuth includes two parties. The , i.e., the consumer and the service provider. Basically in this case the consumer also becomes the resource owner. Consumer The consumer first needs to register a consumer_key and consumer_secret with the service provider. To access a Protected Resource, the Consumer consumer sends an HTTP(S) request to the Service Provider's resource endpoint URI. The request MUST be signed as defined in OAuth Core 1.0 section 9 with an empty Token Secret.

All the requests to the Protected Resources MUST be signed by the Consumer consumer and verified by the Service Provider. The purpose of signing requests is to prevent unauthorized parties from using the Consumer Key when making Protected Resources requests. The signature process encodes the Consumer Secret into a verifiable value which is included with the request.

OAuth does not mandate a particular signature method, as each implementation can have its own unique requirements. The protocol defines three signature methods: HMAC-SHA1, RSA-SHA1, and PLAINTEXT, but Service Providers are free to implement and document their own methods.

The Consumer consumer declares a signature method in the oauth_signature_method parameter, generates a signature, and stores it in the oauth_signature parameter. The Service Provider verifies the signature as specified in each method. When verifying a Consumer consumer signature, the Service Provider SHOULD check the request nonce to ensure it has not been used in a previous Consumer consumer request.

The signature process MUST NOT change the request parameter names or values, with the exception of the oauth_signature parameter.

In 2-legged OAuth with OAuth 1.0 - , the request to the protected resource looks like the following:

http://provider.example.net/profile  
            Authorization: OAuth realm="http://provider.example.net/",  
            oauth_consumer_key="dpf43f3p2l4k3l03",  
            oauth_signature_method="HMAC-SHA1",  
            oauth_signature="IxyYZfG2BaKh8JyEGuHCOin%2F4bA%3D",  
            oauth_timestamp="1191242096",  
            oauth_token="",  
            oauth_nonce="kllo9940pd9333jh",  
            oauth_version="1.0" 

See here to know how to use 2-legged OAuth with OAuth 1.0 to secure a RESTful service.Now, let's look at OAuth 2.0 - still at the stage of a draft specification. This doesn't talk about 2-legged OAuth. But - it can be implemented with different approaches suggested in

OAuth 2.0

...

OAuth 2.0 defines four roles:

1. Resource owner: An entity capable of granting access to a protected resource (e.g. end-user).
2. Resource server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
3. Client: An application making protected resource requests on behalf of the resource owner and with its authorization.
4. Authorization server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

...