Hi there,

At first glance I can't see what the difference is between OAuth and OAuth Common (http://drupal.org/project/oauth_common). A google search didn't bring up any good info either.

Thanks for taking a quick moment,

C

Comments

brmassa’s picture

Title: Difference between OAuth and OAuth Common » Difference between OAuth and OAuth Common modules
Project: OAuth 1.0 » OAuth Common (deprecated)
Version: 6.x-2.02 » 6.x-1.x-dev

flexvixon,

I dont know either. OAuth module is older and uses the same library OAuth Common module uses. The only difference i could notice is that OAuth module provides the WebServices and (as planned) Services modules integration, as well a testing module. OAuth Common is more concise, putting only the OAuth library.

Hugo, the new modules' maintainer might help you on that.

regards,

massa

voxpelli’s picture

OAuth Common is for example used by the "Services OAuth" module: http://drupal.org/project/services_oauth

Hugo who maintains this module can probably give you a detailed explanation here - might take a little longer now during summer though of course.

Hugo Wetterberg’s picture

Assigned: Unassigned » Hugo Wetterberg
Status: Active » Closed (fixed)

Hi flexvixon,
Brmassa is right about oauth_common being focused on just providing the oAuth library and infrastructure. But, to put it bluntly, the most important difference is that oauth_common gets it right, whereas oauth does not. The oauth module is tightly coupled with the webservices module (without having a dependency in the info-file). It doesn't leverage the object oriented nature of the oauth library (and does some outright outlandish stuff with class declarations [oauth.inc line 212]). The oauth_common module provides a clean separation of oAuth and services, and whatever things it needs to be integrated with, by not allowing any services-specific stuff. Integration with services is implemented in services_oauth instead.

It also seems that the oauth module started out with some misconceptions about how oAuth works. It is treated as a mongrel crossbreed of a API key and a username/password, as a system for authenticating rather than authorizing external applications. The maybe most glaring omission is that stuff like viewing or revoking authorizations is completely absent. A consumer and access token is automatically created for each user. And the consumer is seen as something that identifies the user, a reasoning which leads to strange stuff like: full access to all services if a user authorizes a application that uses the consumer linked to the users account; no possibility for a user to register any consumers, so a developer can't create a consumer entry for both "My super iPhone app" and "External web site", this also leads to strange side-effects like "Select which services you will allow mysuperiphoneapp://oauth/authorized use in your behalf" when the user is presented with a authorization form. As consumers aren't created for applications (with a name etc.), but for users, and the callback url then is used to represent the consumer that is authorized.

I would recommend anyone that doesn't depend on the webservices module to stay well clear of the 'oauth' module, as it more or less misses the mark on what a oAuth module should and shouldn't do.

Cheers,
/Hugo

voxpelli’s picture

OAuth Common has replaced OAuth.module - OAuth.module 3.x is the same as and the successor of OAuth Common 2.x.

This issue was about OAuth 2.x and OAuth Common 1.x and is therefor no longer a valid comparison between the two modules.

OAuth Common should no longer be used - instead OAuth 3.x should be used.