I am wondering when we will have time to open a new branch to implement OAuth 2.0? http://tools.ietf.org/html/draft-ietf-oauth-v2-04


Hugo Wetterberg’s picture

Project: OAuth Common (deprecated) » OAuth
Hugo Wetterberg’s picture

Version: 6.x-2.x-dev » 6.x-3.0-beta1
skyredwang’s picture

Priority: Normal » Critical

update the protocol reference to latest version http://tools.ietf.org/html/draft-ietf-oauth-v2-08

skyredwang’s picture

voxpelli’s picture

Assigned: Unassigned » voxpelli
Category: support » feature
Priority: Critical » Normal

This link will always point to the latest version of OAuth 2: http://tools.ietf.org/html/draft-ietf-oauth-v2

I don't think this is a critical feature request. The module work fine as is - but we certainly should look into supporting OAuth 2 one way or another.

Since OAuth 2 might differ quite a bit from OAuth 1 it's not obvious how to add support for it - might be that it have to be as part of a new major version.

voxpelli’s picture

Version: 6.x-3.0-beta1 » 6.x-3.x-dev
Status: Active » Postponed

I will postpone this for now. There's still some uncertainty around which state OAuth 2 will end up in and what parts of it that we should support. We also don't have a stable module yet. First priority is to get a stable version of 3.x out for D6 and D7 and when that's complete I will revisit this and make it part of either a minor 3.x release or an upcoming 4.x.

voxpelli’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
Assigned: voxpelli » SimmeLj
Status: Postponed » Active

Me and SimmeLj has been sketching on some plans for this. I'm assigning this to him for now and setting it to active again. We will probably focus on client functionality first and do the development on D7 and then backport it to D6. It should support both Bearer tokens and MAC tokens.

Alan Evans’s picture

I'd be very interested in seeing oauth 2 implemented - anything I can do to help? Do you have your sketched plans anywhere I can take a look?

voxpelli’s picture

Assigned: SimmeLj » Unassigned

No plans written down and looks like none of us will have time to do this.

If you want to implement OAuth 2 as a co-maintainer/maintainer then that would be much appreciated.

bojanz’s picture

I've started work on an OAuth2 server implementation in this sandbox.
It is pretty close to being fully functional and tested.
The library it uses is solid and allows the module to stay quite thin.

Despite the fact that my module is pretty close architecturally to this module (OAuth), I'm not sure it makes sense to have it in this project.
Why? This module is both a client and a server, while my module is a server only (OAuth2 has less of a need for a client side, and the implementations across the web differ too much to support them with the same codebase).
And while people can choose between OAuth and OAuth 2 for the server, they will probably need both for the client (OAuth Connector is a good example of this, since it supports both OAuth and OAuth 2 providers), in which case they would need both modules. Since you can't install two branches of the same module, I was thinking of taking the OAuth 2 namespace (contacting the maintainers and getting a 2.x branch there). What do you think?

Of course, any kind of feedback is appreciated. I would be more than glad to discuss plans, features, etc on this thread or via alternative channels.

sun’s picture

I can get behind the general idea and the reasoning you stated.

But frankly, the situation and Druplication with regard to OAuth integration modules is one of the worst even without that additional module at this point already.

There does not seem to be a community-agreed-on main approach/solution, and plenty of people are doctoring around individual + independent modules and libraries. This is the most concerning part to me, since a major aspect of OAuth is about security.

If I'd start a new project needing OAuth functionality today, it would take me a few days to analyze, test, code- and security-review all the available modules, in order to make a well-informed decision. Needless to say, due to the fragmentation, the maintenance of the individual projects is "suboptimal", too.

I'd love to see more collaboration and joined forces in the space of OAuth integration modules. I'd prefer to see everyone who's familiar with OAuth working on one project (potentially leveraging sub-modules), so as to ensure that Drupal is able to provide a 1) mature, 2) secure, 3) deeply integrated, and 4) battle-tested solution.

There is a very strong need for that, as we continue to see one-off integration modules like http://drupal.org/project/twitter, http://drupal.org/project/fboauth as well as plethora of OAuth API + UI modules, and none of them really works with the others, which means that developer as well as the final end-user experience suffers big time.

sun’s picture

Forgot to amend:

I had to implement a simple and custom 2-legged OAuth v1 algorithm for the Mollom module, instead of adding a dependency on another module, exactly because of the extremely poor state of OAuth API/integration modules:
#1361538: Move Mollom Moderation integration into optional sub-module depending on OAuth module

Getting that implementation right did cost me a couple of days of full-time engineering work, but was the only viable option. I do not think that the situation has dramatically changed or improved in the meantime.

And so that's yet another one-off implementation that should not only be unnecessary, but is also a potential source of bugs and perhaps even security vulnerabilities.

The OAuth protocol(s) are an essential part of today's web. We badly need to provide solid + secure APIs that other Drupal developers can leverage. And that's only going to be possible if everyone of us joins forces and is willing to collaborate and also make compromises.

bojanz’s picture

I agree that the Druplication is problematic.
It seems concentrated on the consumer side of the things.

I still have the feeling that the server and the consumer side of the code should be in separate modules.
Ideally, we'd have three main modules:
- OAuth1 Server (that's already this module)
- OAuth2 Server (that's my sandbox, under the oauth2 namespace perhaps?)
- an OAuth Client module that abstracts out different server implementations. http://drupal.org/project/oauth_api seems the closest for that.
The abstraction is something that is vital for OAuth2 consumers to work, since OAuth2 implementations vary a lot (usually because they implemented different drafts. This article illustrates some of that).

The question is how to persuade people to integrate with an "OAuth Client" module instead of writing their own (which usually consistes of copy-pasted code samples given by the API provider). Better documentation is certainly one (I've seen confusion around how users should use the OAuth module. We need docs for people who haven't read the official spec, twice).

skyredwang’s picture

If you guys haven't read "OAuth 2.0 and the Road to Hell", http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

So, let's NOT implement OAuth anymore?

bojanz’s picture

I've read that article, plus others about potential vulnerabilities, plus the spec and the "security considerations" spec. The spec itself gives you enough rope to hang yourself, but the PHP library does a good job with avoiding the basic attacks, and sane assumptions / configuration on the module part (requiring "state", etc) allow the user / server to stay safe.

I need OAuth2 in any case, you're free to use it or not :)

sun’s picture

I assume that everyone who's working in the OAuth space knows about that post, yes. However, there's no alternative yet, and the author himself recommends to keep going with v1 - or if you really need to, bite the bullet of complexity of v2, which isn't really OAuth anymore, but rather Vendor-specific Authentication (VESA) [*SCNR*].

Well, at minimum I'd suggest to clearly name it after what it contains; i.e., oauth2_server. :)

(That said, to properly test an oauth2 server, you need an oauth2 client implementation, at minimum in a testing module, at which point we're circling back... :P)

I can certainly imagine that you do not want to get blocked on a "contrib merging/refactoring" discussion, and obviously no one can prevent you from moving forward with that. However, I'd at least recommend to keep the idea of a potential later project merging in the DNA of that new project?

bojanz’s picture

Small update:
The OAuth2 project maintainer has refused co-operation, I've spent 3 weeks trying to get in touch with him over the issue queue, email, skype, his only response gave me the impression that he doesn't want me to open a new branch in his project, nor is he willing to work together.

If nothing changes until monday, I will create an oauth2_server namespace.

juampynr’s picture

Status: Active » Fixed

As @sun said, yes I am aware about the opinions from the main leader (now gone) of the OAuth project at http://hueniverse.com/. It cleared my doubts about whether I should work on supporting OAuth or not. Seeing that there is not agreement in the implementation of OAuth 2 (Facebook does it his own way, while I am not aware about other platforms), I discouraged the idea. Besides, the current implementation that this module holds is used by a good amount of sites.

@bojanz, you are welcome to create a different project to hold an OAuth 2 implementation whenever you want.

bojanz’s picture

Of course I am, my point was that I tried to get the "oauth2" namespace (which is currently dead) to prevent druplication, but it seems I will have to go with my own (oauth2_server).

I believe it is possible to abstract-out the differences in implementations and build an OAuth2 Client module, but it is not a place where my interests lie at the moment.

I am supportive of this module staying OAuth 1.0a only.

bojanz’s picture

Here we go: http://drupal.org/project/oauth2_server
We have fairly extensive tests, and a good set of initial docs.
Comments and reviews welcome.

sun’s picture

And it happened again. :(

@bojanz: Thanks a lot for holding off the new project and trying hard to collaborate and join forces. Highly appreciated, +1,000 reputation update. I'm very sad to see that your extensive efforts did not work out. :(

I honestly don't get what happened, and why this happened again.

It looks like Drupal has completely lost its original spirit and paradigms; namely, collaborating and joining forces on solutions for the world at glance, instead of developing one-off modules and scratching your own itch in your corner. The former is the spirit that made Drupal overly successful as a community and platform since ~2005, the latter is not.

I'm sad, very sad. I don't know what else to say. This technology/topic ranks top #10 for Drupal's long-term success and future. In case you're interpreting this project as a simple module, then I can only recommend to take a very big step back, take a deep breath, and have a look at overall web technology and web service trends, consumer electronics, and the web and universe at large.

Our inability to collaborate and join forces on delivering working solutions in this area will shift Drupal into the quadrant of irrelevance, the longer we don't get our act together.

A joint effort in this space should aim for no less than Drupal core inclusion for Drupal 9. (which is 6+ years too late.)

If there's anything I can do to help, please let me know.

In case a skype conf call between all parties would help, let's do that. Whatever is necessary.


bojanz’s picture

I would be happy to discuss collaboration with anyone, anytime, but it seems to me I'm the only one working on OAuth2 in Drupal right now.
The OAuth2 project maintainer refused my offers only to return to non-activity.
Of course, there are still people implementing one-off OAuth2 client solutions, but I am unsure of their general level of understanding of OAuth2 as a technology, as well as the feasibility of tackling generic OAuth2 clients (I just don't have a clear use case in my head, funny as it sounds).
I've spent a lot of time understanding and implementing OAuth2 and would love to pass along some of that knowledge (I've created extensive docs pages as a start).

The server effort marches on, as we get closer to at least deploying it on staging internally (which would allow me to tag a first RC).
I've also been successful in getting a few more pull requests merged into the library, though my todo list still has a few more.

skyredwang’s picture

@bojanz are you refer to @voxpelli or @heyrocker as OAuth maintainer? I was wondering what their opinion was, and if possible I hope they could share some thoughts on the related discussion.

bojanz’s picture

I was referring to the "OAuth2" project maintainer, not "OAuth".
I've been in contact with voxpelli over OAuth Connector (I have commit access to it now, yay bugfixes!), but we didn't discuss this issue.

My goal was never to try and merge into this module because of reasons stated in #10.
(Plus, I've been wary of trying to rewrite a popular module, again, and then having to take care of every feature that was lost, etc).
I believe it makes little sense to try and support both OAauth and OAuth2 servers with the same codebase.
Supporting OAuth and OAuth2 clients with the same codebase would be great, but I am still unsure where it should live.
Maybe we just need to extend the oauth_api module to support oauth2.
I am open to other people's crazy ideas, as you've seen I've been pretty conservative so far and focused mostly on the server side.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

1kenthomas’s picture

Issue summary: View changes

Bump. Is this still on the roadmap for this project, or is it best covered by 2.0 modules (server and client)? Thanks.

colan’s picture

Component: Code » Documentation
Category: Feature request » Task
Status: Closed (fixed) » Active

As this initiative appears to be dead, let's put links to the OAuth2 client and server modules on the project page.

DamienMcKenna’s picture

And there's also the http_client module which supports OAuth2.

juampynr’s picture

Status: Active » Closed (won't fix)

There are many alternatives for OAuth 2, and I don't think that OAuth module should encourage any of them in the project page. Therefore, I have removed the existing links that existed pointing ot OAuthConnector and SimpleOAuth.

colan’s picture

In that case, I'd recommend changing the human-readable project name to "OAuth1" or "OAuth 1" so new feature requests for 2 don't keep popping up in the queue.