Page Comparison

OAuth 1.0 emerged from the large social providers like Facebook, Yahoo!, AOL, and Google. Each had developed its own alternative to the password anti-pattern. OAuth 1.0 reflected their agreement on a single community standard. As a result of security upgrades, OAuth 1.0a  was released as the revised specification that offered upgraded security to users. In 2009, recognizing the value of more formalized standardization, that community contributed OAuth 1.0 to the IETF. It was within the IETF Working Group that the original OAuth 1.0 was reworked and clarified to become the Informative RFC 5849.

After more standardization, in 2010, Microsoft, Yahoo!, and Google created the Web Resource Authentication Protocol (WRAP), which was soon submitted into the IETF WG as input for OAuth 2.0. WRAP proposed significant reworking of the OAuth 1.0a model. Among the changes were the deprecation of message signatures in favor of SSL, and a formal separation between the roles of ‘token issuance’ and ‘token reliance.’

...

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

...

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.

In case of 2-legged OAuth, the client becomes the resource owner.

We can at At a very high-level, it is possible to break the full OAuth flow into two parts.

1. Get a token from the authorization server.
2. Use the token to access the resource server.

...

1. .

OAuth 2.0 defines a concept called "authorization grant" which is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. This specification defines the following four grant types:

...

Client Credentials is the grant type which goes closely with 2-legged OAuth. With the Client Credentials grant type, the client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control. Once the client makes this request to the authorization server - it will return back an access token to access the protected resource. The access token returned back to the client could be either of type bearer of MAC. The "mac" token type defined in ietf-oauth-v2-http-mac is utilized by issuing a MAC key together with the access token which is used to sign certain components of the HTTP requests by the client when accessing the protected resource. The MAC scheme requires the establishment of a shared symmetric key between the client and the server. This is often accomplished through a manual process such as client registration.

The OAuth 2.0 specification offers two methods for issuing a set of MAC credentials to the client using ..the following:

1. OAuth 2.0 in the form of a MAC-type access token, using any supported OAuth grant type. [This is what we discussed above - an access token with 'MAC' type]
2. The HTTP "Set-Cookie" response header field via an extension attribute.

When using MAC type access tokens with 2-legged OAuth - , the request to the protected resource looks like the following:

Code Block
GET /resource/1?b=1&a=2 HTTP/1.1 Host: example.com Authorization: MAC id="h480djs93hd8", nonce="264095:dj83hs9s", mac="SLDJd4mg43cjQfElUs3Qub4L6xE="

Bearer type is defined here. It is a security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).

When using Bearer type access tokens with 2-legged OAuth - , the request to the protected resource looks like the following.

...

Also - the issued access token from the Authorization Server to the client, has an 'scope' attribute. [ 

Info
title Note
2-legged OAuth with OAuth 1.

...

0 does not have this scope attribute as well as access token concept - so the resource server has to perform authorization separately based on the resource the client is going to access

...

.

 

The client should request access tokens with the minimal scope and lifetime necessary. The authorization server will take takes the client identity into account when choosing how to honor the requested scope and lifetime, and may issue an access token with a less rights than requested.

When securing APIs with OAuth - this 'scope' attribute can be bound to different APIs. So , the authorization server can decide whether to let the client access this API or not.