Closed (fixed)
Project:
OAuth Common (deprecated)
Version:
6.x-1.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Support request
Assigned:
Reporter:
Created:
28 Jun 2009 at 17:52 UTC
Updated:
7 Apr 2011 at 05:53 UTC
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
Comment #1
brmassa commentedflexvixon,
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
Comment #2
voxpelli commentedOAuth 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.
Comment #3
Hugo Wetterberg commentedHi 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
Comment #4
voxpelli commentedOAuth 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.