What is OAuth?

Quoted from http://oauth.net/core/1.0a/

The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication.

Terminology

• Service Provider - an application that allows access via OAuth
• User - an individual who has an account with the Service Provider
• Consumer - an application that uses OAuth to access the Service Provider on behalf of the User
• Protected Resource - data controlled by the Service Provider, which the Consumer can access through authenticatio

The Problem

The OAuth protocol describes the details of the communication between the Consumer and the Service Provider but does not define aspects related to the User nor it enforces the authentication protocol used by the Service Provider. The later is not a problem when the User is human but is a major issue for a Software User since there are no mechanisms to programatically determine what protocol is used. So bascially the Software User ends up tyring to use an API which is not known.

• The manual and programatic workflows are depicted bellow.
• Human User - a kid
• Software User - the kid's robot
• Service Provider - the kid's grandmother, in charge of the food cabinet
• Consumer - a high tech toaster able to charge itself
• Protected Resource - a loaf of bread
• Service produce - toasted bread

Manual workflow

The human operator knows it is presented with a login screen and identifies the components of the login form.

Programatic workflow

The software operator knows it needs to authenticate but has no idea how nor it has the means to "understand" what protocol is used. The authentication protocol used by the service provider can Basic Authentication, Form Authentication or any other protocol. At best, the Software Client can attempt to use a set of known protocols in the hope that one of them will match.

In addition some popular authentication protocols such as Form Authentication are not standardised.

Solving the problem

One way to solve this problem and allow the usage of OAuth in the context of Reporting is by having a well defined set of authentication protocols supportedfor the Service Provider. The list of the initial protocols could be:

• basic authentication
• digest authentication
• form based

2 Legged OAuth

The 2 legged OAuth is a protocol that is inspired from OAuth protocol but is not part of the OAuth standard

References:

http://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi

http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/1/spec.html

http://wiki.opensocial.org/index.php?title=OAuth_Use_Cases

Quote from http://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi

The OAuth term is most frequently used when referring to 3-legged OAuth. This was a standardized version of a protocol that many vendors like Yahoo, Google, AOL, etc. had deployed which involved an end-user going through a "dance" where they start on the OAuth consumer site, and are redirected to the OAuth provider site where they are asked to approve access by the consumer site to their data. If their approval is given, they are then bounced back to the OAuth consumer site. While this "dance" has enabled a whole net set of applications and data-interoperability, the user experience can be confusing for an end-user (sort of like ballroom dancing with two partners at the same time).

2-legged OAuth is a term that is used to refer to another variant of OAuth which does not require this dance. This variant is also called Signed Fetch or Phone Home, especially in the OpenSocial? community. In fact, the vast majority of actual REST API calls made on the Internet using OAuth are made using 2-legged OAuth, not 3-legged OAuth. The reason for that is that this is the feature that allows a gadget to make a connection back to the home server's of the developers who created the gadget. The following blog post contains an early description of this gadget feature

http://opensocialapis.blogspot.com/2007/11/improved-content-fetching-for.html]]

This Signed Fetch feature of OpenSocial? allows a gadget to "phone home" to its home servers. The reason the OAuth dance is avoided is because those home servers do not have any pre-existing information about the end-user, so there is no need for the end-user to give approval to access that non-existing data.

Using the 2legged OAuth

So while the 2 legged OAuth does solve the problem of the 3 legged OAuth it introduces a new one: all users will access the data using the same credentials hence they will access it having the same rights. Accessing the data with the same rights defeats the whole purpose of the access rights systems implemented by many applications.

To solve this problem each user would have to be associated to a distinct consumer token effectivelly doubling the number of users and the effort needed to maintain them.