Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment #1
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedAdding tag
Comment #2
voxpelli CreditAttribution: voxpelli commentedFor 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.
Comment #3
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedThe 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.
Comment #4
Damien Tournoud CreditAttribution: Damien Tournoud commentedWe 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.
Comment #5
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedAnd 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.
Comment #6
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedI 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.
Comment #7
skyredwangWe have to develop OAuth2 support, first! OAuth1 is not enough for mobile.
Comment #8
grendzy CreditAttribution: grendzy commented+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.
Comment #9
cweagans-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.
Comment #10
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedI 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 !
Comment #11
cweagansThe 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.
Comment #12
neclimdulThere'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.
Comment #13
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedI 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.
Comment #14
voxpelli CreditAttribution: voxpelli commentedIn 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.
Comment #15
skyredwangI 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.
Comment #16
webchickCan 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
Comment #17
cweagansI know they're not the same. They are related in my mind in that neither should be in core.
Comment #18
mariomaric CreditAttribution: mariomaric commentedJFTR: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
Comment #19
juampynr CreditAttribution: juampynr commentedFurther discussion has been held at the OAuth module's issue queue at http://drupal.org/node/1591692
Comment #20
juampynr CreditAttribution: juampynr commentedSo far OAuth has a stable version to authenticate requests. https://drupal.org/node/2110825
Currently there is no intention in getting this module into core.
Closing.
Comment #21
webchickHm. Whether the module itself goes into core doesn't necessarily mean we shouldn't aim for this feature set in core. This would be a huge win for web services.
Comment #22
Wim LeersWe have an authentication API in core, but apparently no component for it. So I'm changing it from
torest.module
to improve discoverability.And by now we have a great D8 contrib module that provides exactly this: https://www.drupal.org/project/simple_oauth.
Comment #23
juampynr CreditAttribution: juampynr at Lullabot commentedThere is also Oauth for OAuth 1.0. However, it looks like simple_oauth is easier to implement.
Comment #24
dawehnerI think what we should focus on is what are standards people use out there in the wild. At least from a user point of view oauth2 is the most common standard. People certainly trust clicking a button more than having to insert the password on a second website (which can potentially be needed on basic_auth).
I'm wondering whether we could have a more simplified simple_oauth, aka. one with no configuration UI, as we, simiilar to REST in core.
Comment #25
e0ipso@dawehner the UI is only a form for the configuration entities, it can certainly go away. I have in my backlog adding a couple of refactors to the module, but I like the feature set.
One interesting thing that I'm not sure that is very well communicated is the customizable scopes. OAuth2 bearer tokens are like cash, once stolen you can do little about it. That's why the spec recommends very short expiration times and limiting the user privileges to the absolute bare minimum. In simple_oauth I the access checks are done against the role *and* the scope so you can restrict the access even further.
I only say this because I see how the custom scopes are the next thing in line to remove in this hypothetical future :-P
I'm up to rethink the contrib to make it more attractive to the wider audience.
Comment #26
Wim LeersGreat to have your tentative +1, e0ipso!
Comment #28
giorgio79 CreditAttribution: giorgio79 commentedNo need to reinvent the wheel :)
https://www.drupal.org/project/hybridauth
Comment #29
e0ipso@giorgio79 can you elaborate on that? Isn't HybridAuth a PHP library that deals mainly with social media?
Comment #30
giorgio79 CreditAttribution: giorgio79 commentedI will let their github page elaborate on that :) https://github.com/hybridauth/hybridauth
Hybridauth integrates with most of the big identity providers out there. Not sure if you want to let Drupal become an identity provider with oauth in core, or integrate with others. But if the latter, hybridauth is the way to go.
As I understand from history, the Drupal OpenID module failed. Identity has been conquered by the biggies, so what is left for the rest is tools like Hybridauth... :)
PS IMHO Oauth login / reg integrations should be part of core as well. Who fills out registration and login forms these days? :)
Comment #31
cweagansRetitling to make the intent clearer.
Comment #32
Wim LeersOh. So that means what I wrote in #22 is totally wrong:
.In that case, this does not belong in the
rest.module
issue queue.Comment #34
niekheezemans CreditAttribution: niekheezemans commentedHi guys,
I just made this issue post earlier today: https://www.drupal.org/node/2874418
I am trying to integrate simple_oauth module with views rest export (drupal 8.3.1.) but unfortunately it doesn't work (yet).
Have you guys been able to get this up and running yet where you can set the simple oauth as the authentication provider for a rest export? I suggested a fix for the calculateDependencies() since it was throwing an error for simple oauth but also for user/cookie because it is using the array_values of the $authenticy_provider instead of the array_keys.
But I am still getting an error403 when i try to call the rest-export API on the given API path: { "message": "The used authentication method is not allowed on this route."}
Thnx in advance!
Comment #39
edischBump.
We talked about this today in the Drupal slack. Specifically @gabesullice mentioned:
Authentication flows were also discussed, things like:
These are not possible at the moment without a password. Even when authenticated with a provider (JWT, Simple OAuth, etc), the current password must be sent in the request in order to make changes to the user entity.
There's some security related points to consider:
Comment #40
edischThere's been a lot of further discussion about this in: https://www.drupal.org/project/ideas/issues/2834718
At this point this is a duplicate ticket.
Comment #41
edisch