Posted by Sylvain Lecoy on May 6, 2011 at 11:22am
12 followers
Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | other |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | External Identities Initiative |
Issue Summary
Taken from http://drupal.org/node/556380#comment-4420232, create an OAuth quality API for the Drupal community to build upon.
I started work here: http://drupal.org/sandbox/SylvainLecoy/1127118 where you can follow the evolution and add features as the module is still in its incubation phase.
Comments
#1
Adding tag
#2
For reference - the http://drupal.org/project/oauth module is also a good candidate for core inclusion. It's a pretty established module with a D7 port in progress. I see no need to further fragment the OAuth initiatives.
#3
The lack of extensibility, binding the implementation to only one library. OAuth project is more a product itself than a framework, it also depends on ctools and provides end-users features. The idea is to provides a build in platform, not a product.
If you read carefully the purpose of the sandboxed module is not to fragment OAuth, but provide a quality API for OAuth to implements upon it. That is allowing modules like Twitter, Facebook relying on this, and OAuth adding more complete functionalities such as exporting with ctools, a end user UI, server (provider) capabilities, etc.
#4
We definitely want to settle on a single oauth library. I see no need to build an abstraction over an abstraction here. Integrating with Drupal, yes, abstracting a library, no.
#5
And what if we are not happy with the php library ?
If we work on servers that have buildin OAuth PECL why should we use a php library ?
We did it for database, for cache system, we did it for Drupal Commerce, Ubercart, and e-Commerce, we did it for MIMEMail and HTMLMail... why it should be different in that case ? Having a php library as a default is nice, but let people extends it by implementing with their own. This is the initiative for Drupal 8 it seems (with plugin in core: Web Services and Context Core Initiative), so why redo the previous Drupal mistakes if we want to make it a better framework ?
PECL OAuth is a standard, I advocate using it. But I know people can't - or don't want to - use dedicated server. So providing an DrupalOAuthConsumer interface is the idea, letting people providing Adapters. Its not about abstracting a library, but adapt a particular implementation to something that the client expect (see the mapping definition in the WSCCI Group for a more Drupal friendly explanation).
Its like having a rar library, if you need it as a casual admin, its ok to have a php implementation, but if you need it as your killer feature for you webapp, you'll need a solid C++ implementation. If you don't abstract the implementation and bind it to a php lib, the developers will rewrite code or move away from Drupal, because of the lack of extensibility.
#6
I am also quoting from Crell:
That's what I had in mind while creating the OAuth wrapper and I think this is the right way to proceed.
#7
We have to develop OAuth2 support, first! OAuth1 is not enough for mobile.
#8
+1 to oauth in core. For me, a simple consumer library is a higher priority then provider support.
If the plug-in system #363787: Plugins: Swappable subsystems for core makes it into D8, then oauth should use it. If not, I don't think it makes any sense to develop yet another abstraction abstraction.
#9
-1
oAuth, as a standard, can change. oAuth.module in core cannot change for a number of years. We don't want to lock our users into an implementation of standard that could no longer be relevant in three years. This should be left to contrib.
#10
I think #9 is right, using standard is never a good idea. Also, we should remove html5 initiative for not locking our users into an implementation that is not relevent now, and will be deprecated in ten years. Same remark for css3 by the way.
Clearly, locking people into standards are the worst thing to do. Drupal is a good example, no standards, work fine !
#11
The sarcasm isn't necessary. html/css are not likely to change that much for Drupal 8's lifetime. oauth looks like it's evolving rather quickly. If it's locked into core, the oauth implementation won't be able to keep pace with the spec. See here:
June 24, 2009: http://oauth.net/core/1.0a/
April 2010: http://tools.ietf.org/html/rfc5849
July 25, 2011: http://tools.ietf.org/html/draft-ietf-oauth-v2-20
It shouldn't be in core, and neither should OpenID.
#12
There's plenty of discussion about what should be in core going on at #1255674: [Meta] Make core maintainable and probably else where. I don't think discussing it here is actually going to be useful until those guidelines have been sorted out.
#13
I agree that the two are related, if OpenID reside in core, there is no reason for not embed OAuth as well. However, if you think OAuth should not resides in core, then there is no reason to keep OpenID.
#14
In response to #9 and #11: OAuth 1 is one standard which is very good. OAuth 2 is another standard (in fact not a single standard though but rather the OAuth 2 core standard packaged together with at least one token standard, often the bearer token standard).
Point is: OAuth 1 has with the single exception of a security issue never received any breaking changes - not even when it became an IETF - and it will stay a valid standard for years to come.
OAuth 2 will likewise stay a stable standard with no changes except for the addition of new token standards which if they become popular would have to be supported.
Also: Comparing OpenID and OAuth is very wrong. OpenID is used to log in to stuff - OAuth is purely a way to authorize access to HTTP resources. There's a use case for OpenID - there isn't really one for OAuth. The only relation between the two is that if Drupal core wants to expose authenticated web services then OpenID users wouldn't have the username and password to authenticate themselves and thus they would need OAuth for that. Unless Drupal core wants to expose authenticated web services there's no need for OAuth in core.
So - is there any use case for OAuth in Drupal core? if not - then it shouldn't be there.
#15
I have contributed to Services, and have been actively using Services. In my opinion, if Services in Core, then OAuth2 has to be in Core. My reasoning is below:
1.) In most use cases, at least for now, websites want to expose their User, Content, Taxonomy ... resources in API fashion. If these websites do not need authentication for the resources, then Views Datasource (+Views) is a much more useful, easy and robust solution than Services module. People come to Services, one of the biggest reasons is that Services support authentication. Now Services is going to core, and we need to have an authentication layer for web services.
2.) OAuth is becoming the standard for web services authentication. Instead of home-brewing Drupal Services auth process with Drupal sessions, OAuth should be our choice.
3.) OAuth1 vs. OAuth2. OAuth1 a.) has terrible mobile support, b.) it's much harder than OAuth2 c.) will be obsoleted once OAuth2 comes out (The 3 reasons can be found on http://oauth.net/2/ related pages). Therefore, if we go with OAuth, then it must be OAuth2.
#16
Can everyone who's -1ing in this discussion please read http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-yo... ? Just because OAuth and OpenID start with the same letter doesn't mean they are remotely the same thing. :P
#17
I know they're not the same. They are related in my mind in that neither should be in core.