Current version:

This library has little support. The aim is to replace it by


juampynr’s picture

Work should be done at branch 7.x-4.x. I have made an initial commit there with an updated README, but the version select field does not yet show the 7.x-4.x branch.

sun’s picture

Let's do an extensive research for possibly existing PHP libraries first in order to not re-invent the wheel.

Also, just found this: ;)

If we're going to port/write the PHP library from scratch, this should ideally be done outside of Drupal and this module (e.g., github), using a more permissive non-GPL license (e.g., MIT), be based on latest PHP 5.3 features and also adhere to the PSR-0 standard.

I'm highly interested in this, might even consider to lead that effort (in case it is needed).

voxpelli’s picture

I think the focus in a switch like this should be to better support multiple versions of OAuth - have a unified system that can get tokens through both the OAuth 1 way and the OAuth 2 way and which can at least handle OAuth 1 access tokens and OAuth 2 bearer tokens but also be pluggable to support more or less any kind of OAuth 2 token - like eg. mac tokens ( and completely custom tokens.

I have yet though to see a good library that does both OAuth 1 and OAuth 2 - and I think I haven't seen a single one that supports OAuth 1 and 2 for both servers and clients like the currently used library does for OAuth 1.

I think the best idea, if the current library should be switched out, is to build an entirely new one.

Beware though - some (most) of the current libraries - like the one we are using and tmhOAuth and such has some quirks that's not entirely documented. If I remember correctly variables like "foo[]" or "foo[bar]" is dealt with in a rather weird way - something that an OAuth 1 client and server needs to be able to deal with to stay compatible with existing libraries.

Also beware that the current library is patched to support a few OAuth 1 extensions, like and I think - these should imho be supported in a new library as well as they make OAuth 1 much more useful and since without them some sites might find themselves stuck with the older version.

Lastly: Also be aware that at least in Drupal 6 many other modules are using this module to include the OAuth library file and not because they actually use the module itself - it will be hard to provide a good upgrade path for them. Hopefully this isn't true for Drupal 7 though.

juampynr’s picture

Title: Replace current OAuth library by the PECL package » Replace current OAuth library
Priority: Normal » Major

Changed issue title.

Branch 7.x-4.x is ready. Now it is time for people to chime in and give their opinion about what is better. Possible chances we have seen so far are:

  • Improve our current library, which is now on Github and it can gather attention from developers outside Drupal.
  • Use the PECL package
  • Write a completely new one that supports OAuth 1 and 2 client and server implementations and make extensive use of PHP 5.3.

Are there any other libraries? What is the current library missing? Why building a new one?

sun’s picture

I thought the current library is ?

juampynr’s picture

It is based on, but @voxpelli did a couple of fixes on it. That is why I have moved it out to Github.

Sylvain Lecoy’s picture

Hi there, I was contacted today by juampy. I have a working module of OAuth for drupal 7 based on PECL, you may have a look here:

Juampy asked me why I did on my own and you may interrested to following the discussion. That's the email I answered:

About my thoughts on OAuth, I don't really like the ctool dependency, while I understand the needing, I prefere to make use of drupal system itself and not introduce an extra dependency. I am using the concept of application (which is a drupal entity) which can be instanciated by submodules such as Twitter, Facebook, etc. The application type, like node type, creates a bundle, and you can then take advantage of the entity and fields API. For instance, I have a twitter module which implements the OAuth API, using a field of type oauth_consumer. You can for instance use a field of type oauth2_client for an application type facebook.

To takes advantage of this approach, I reimplemented the authmap, with a minor but essential change: the ability to have a unique key on the oid (OAuth application ID), and a authname. This allow multiple accounts by unique providers (Assuming a provider is represented by an application).

Last point, and this arrives in drupal 8, I like the idea to provides plugins. Modeling on PECL is the basic idea (better for non-drupal dev to understand) and then provides adapters wrapped in the form of plugins for other library such as custom PHP lib, Zend implementation, and so on. If you look at the, you'll see that the adapter for the PECL extention is very straightforward.

However, my module is not complete. I do not support OAuth provider, its just a client library. I do not support either OAuth2, as PECL is not implementing it.

I would be very interrested in joining forces, and I'll fully support you if you are taking the direction of modeling around a PECL. Here is a quoting from Crell that I like (

Also, please note that I submitted the idea in september 2010 and it was rejected #926368: PECL::OAuth.

Sylvain Lecoy’s picture

I would also add that the PECL OAuth has very good support.

I have a couple of email with John Jawed one of the current maintainer asking for feature request (such as making non-final the OAuth class) to allow extensibility and he answered very positively. Here is the discussion for instance:

Sylvain Lecoy’s picture

What about working together then ?

I could work on making the 'application' entity system integrate better with drupal. We could decide on a set of quality API interfaces that we agreed on for any OAuth objects used by the module. On your side you can also create your own library to be switched in case there is no PECL available... Just tell me ! I would be very excited to collaborate.


Sylvain Lecoy

juampynr’s picture

The main author of the OAuth protocol leaves the team because of lack of consensus and direction on the OAuth 2 project. This may make us think twice if we really want to support OAuth 2.

Have a look at

RobKoberg’s picture

At least for now, any chance of checking for an existing OAuthException? If you install the pecl oauth extension there is a conflict.

// vim: foldmethod=marker

/* Generic exception class
if (!class_exists('OAuthException')) {
  class OAuthException extends Exception {
    // pass

class OAuthConsumer {
pwolanin’s picture

Wow, I was on the emil list for Oauth2, but stopped reading it regularly since I didn't think the MAC protocol discussion was going to be very fruitful.

Based on the post at I'd agree it might be better to simply stay focused on OAuth 1.0a

juampynr’s picture

This leaves us with the pending task to review if the PECL library implements OAuth 1 or 2, and if it also implements both server and client protocol. Has anybody have had a look at it?

For the moment, we can still keep with our library, which is hosted at

sun’s picture

MD3’s picture

This kind of goes along more of the lines about our current implementation, but what is different about our library from the googlecode version? I created an issue here on the Github repo so that developers outside the Drupal community can see it as well:

juampynr’s picture

@MD3, see #3 for differences in our Library against the Googlecode one.

I would have to go through the log to view changes on the library, as they were mostly done by previous maintainers. Not sure if I can find time for that at the moment.

MD3’s picture

Thanks @juampy! I guess I missed that when I was reading the thread. That explains pretty well what he added:
-Better 2-legged support, it looks like?
-support for parsing formats other than x-www-form-urlencoded

I've gone ahead and quoted @voxpelli in the Github issue for future reference and closed it!

Sylvain Lecoy’s picture

Sorry for the late answer,

PECL OAuth implements OAuth 1.0a, as well as both client and server protocol.

The team is reactive and responsive, also very open-minded. The two leads are Rasmus Lerdorf and John Jawed. Since 1.1.0 the project has been pretty stable and no major API changes has been committed since, which is a good indicator for project maturity.

bojanz’s picture

As I said in #795994: Implement OAuth 2.0 protocol, I don't think it's necessary for this module to try and support OAuth2 at all.
So the library can be OAuth 1 only.