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

Sylvain Lecoy’s picture

Adding tag

voxpelli’s picture

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.

Sylvain Lecoy’s picture

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.

Damien Tournoud’s picture

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.

Sylvain Lecoy’s picture

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).

A plugin type is the grouping for all plugins that satisfy a particular purpose. All plugins are the members of exactly one plugin type and should be interchangeable with other plugin of the same type. The canonical example here is caching. "Cache storage system" is a plugin type. "Database cache", "Memcache cache", etc. are plugins that conform to that type. In the current architectural plan plugin types will be implemented as a PHP interface, plus additional metadata.

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.

Sylvain Lecoy’s picture

I am also quoting from Crell:

In fact, we should design it so that if you install the appropriate PECL module, nothing changes except that stuff gets faster. That's an approach we should be using throughout core a lot more: Model on a PECL. That provides a known, non-Drupal-specific API (easier for new people coming to Drupal) as well as a very easy way for Sites With Root(tm) to speed up their Drupal site.

That's what I had in mind while creating the OAuth wrapper and I think this is the right way to proceed.

skyredwang’s picture

We have to develop OAuth2 support, first! OAuth1 is not enough for mobile.

grendzy’s picture

+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.

cweagans’s picture

-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.

Sylvain Lecoy’s picture

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 !

cweagans’s picture

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.

neclimdul’s picture

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.

Sylvain Lecoy’s picture

It shouldn't be in core, and neither should OpenID.

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.

voxpelli’s picture

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.

skyredwang’s picture

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.

webchick’s picture

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

cweagans’s picture

I know they're not the same. They are related in my mind in that neither should be in core.

mariomaric’s picture

juampynr’s picture

Further discussion has been held at the OAuth module's issue queue at http://drupal.org/node/1591692

juampynr’s picture

Status: Active » Closed (won't fix)

So 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.

webchick’s picture

Version: 8.0.x-dev » 8.2.x-dev
Category: Task » Feature request
Priority: Normal » Major
Issue summary: View changes
Status: Closed (won't fix) » Active

Hm. 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.

Wim Leers’s picture

Component: other » rest.module

We have an authentication API in core, but apparently no component for it. So I'm changing it from other to rest.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.

juampynr’s picture

There is also Oauth for OAuth 1.0. However, it looks like simple_oauth is easier to implement.

dawehner’s picture

I 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.

e0ipso’s picture

@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.

Wim Leers’s picture

Great to have your tentative +1, e0ipso!

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

giorgio79’s picture

No need to reinvent the wheel :)
https://www.drupal.org/project/hybridauth

e0ipso’s picture

@giorgio79 can you elaborate on that? Isn't HybridAuth a PHP library that deals mainly with social media?

giorgio79’s picture

I 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? :)

cweagans’s picture

Title: Integrate OAuth to core » Add an oauth identity provider to core

Retitling to make the intent clearer.

Wim Leers’s picture

Component: rest.module » other

Oh. So that means what I wrote in #22 is totally wrong: And by now we have a great D8 contrib module that provides exactly this: https://www.drupal.org/project/simple_oauth..

In that case, this does not belong in the rest.module issue queue.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

niekheezemans’s picture

Hi 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!

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

edisch’s picture

Bump.

We talked about this today in the Drupal slack. Specifically @gabesullice mentioned:

We _would_ love to see OAuth become the defacto, standard auth case for doing decoupled Drupal projects though.

Authentication flows were also discussed, things like:

  • Resetting a password
  • Updating a user entity

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:

  • Are Bearer token's safe enough to provide access to change a password?
  • Maybe we'd want to only allow bearer tokens acquired via the password reset link to have permission to update a user?
  • Can another layer be added into a bearer token (via a claim / grant in the JWT) that allows elevated permissions?
edisch’s picture

There'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.

edisch’s picture

Status: Active » Closed (duplicate)