Implement OAuth, OAuth2 and OpenID consumers

[resurtm]

How about implementing OAuth, OAuth2 and OpenID consumers as officially supported extension(-s)? What do core developers and community members think about it? Are there any non-specific ideas and wishes?

Proposal from the 1.1 issue tracker: yiisoft/yii#306

Notable extensions:

• https://github.com/Nodge/yii-eauth
• http://www.yiiframework.com/extension/loid
• http://www.yiiframework.com/extension/eoauth

Resources:

• http://oauth.net/
• http://oauth.net/2/
• http://openid.net/

[qiangxue]

I think we better not include them as official extensions. Yes, they're useful, but then there are already many existing solutions which won't take developers too much trouble to use them in a Yii-based application.

[PrplHaz4]

As a relative newbie to this framework, I'd just like to say that the sheer volume of extensions addressing this feature make it a bit of a crapshoot to navigate (and seem to show an obvious need). You could spend months reviewing the code for all such extensions trying to find one that fits the quality standards required (thereby eliminating the benefit of using an extension over writing it yourself).

The feature itself seems to be akin to providing the Web Services modules in Yii 1.1 core (admittedly, I don't know where that falls in Yii2) - which obviously required the core team to look at existing trends to try and understand what problems were worth giving a certain amount of effort to.

It would have definitely been a relief to see at least some core dev support of such an extension (or, even just an endorsement of quality - some indicator that it wouldn't be a bad decision to use a given extension - ok, maybe this is an extension problem in general, not an oauth problem ;)

I just think it's a potential pitfall to think that "there are many existing solutions" meaning the community is happy with the way it is working.

[qiangxue]

@PrplHaz4 You're right about the similarity of oauth support and the Web services in 1.1. My biggest concern is that these features require significant amount of efforts to reach good quality and maintain in future. Just take a look how much code they take. On the other hand, these features are very self-contained and there are indeed good solutions around (e.g. zend framework by which you can trust with its quality.)

We have to make a tradeoff between the quality of the core framework and the amount of useful yet unnecessary features that we want to support since our resource and energy is limited.

[yjeroen]

@qiangxue, just a curiosity question. If a community member (outside of the team) forks and pushes a new feature like this.. Would you guys look at the quality of the code to decide if something like this would be accepted in the framework? Or would you still decide against implementing this in the core?

Something like this can easily be it's own extension; Im just wondering at which point would the Yii team decide to include it into the core. :)

[samdark]

I think it fits extension better regardless of the code quality.

[psihius]

From my point of view these should be official Yii2 extensions. So that people still contribute to the central point and not splat their efforts all over the place and be left with a crapton of medium to bad extensions.
This also fits a lot of different areas, where a central official repository, still maintained by users, would consoledate the efforts and will have the ability to enforce code guidelines, code review and other stuff that will provide additional benefits.

Take me for example, I don't have enough time to do that many work on Yii, so that I get into core team, but in my line of work I deal with a lot of OAuth2, auth extensions (highly hacked srbac at this time), YiiExt and so on. And I actually have the ability to improve and provide push requests to such extensions and modules, to keep our own code base heathy. So do many others.

In this regard I like the ownership system PECL has on php.net - there are a few maintainers that develop the extension and people contrebute. If owner/owners disappear - via voting a new owner/owners are selected, if anyone is interested.

[qiangxue]

This also fits a lot of different areas, where a central official repository, still maintained by users, would consoledate the efforts and will have the ability to enforce code guidelines, code review and other stuff that will provide additional benefits.

This sounds convincing to me. @yiisoft/core-developers what do you think? Perhaps we should maintain a list of the so-called "commonly used official extensions" which are still maintained by users?

[samdark]

I'm for it. These could be yiisoft/something repos with permissions given to interested users.

[mdomba]

Can't agree more 👍

[lucianobaraglia]

Something like Officially supported extensions 👍

[nsanden]

Love this idea but seems lot of work just managing it all. Unless there could be some sort of voting on deciding which extensions get added / removed from official as well as the voting on managers of repos.

[klimov-paul]

Sure we need to have a list of official extensions for some most common tasks. But I do not know if there should be separated repository with different access rules for this.
GitHub provides “pull request” feature, which allows anyone to join the working on Yii project. Just look at @creocoder: his contribution to Yii2 is tremendous, while he is not an official member of @yiisoft.

As for OpenAuth / OpenId extension – it definitely should be in the core. Nowadays, almost all web application use these protocols to interact with external services, mostly with social networks. Yii should have both OAuth consumer and provider solutions.

[psihius]

As I was mentioning already, see PECL - they have suitable model working pretty well.

I'm not goot with git, but as far as I know each extension/module has to have it's own owners, issue tracker and pull-requests. Is this possible with sub-repos or other mechanic? Or these should be repos listed on an official page and conforming to a set of rules. What are the options here?

[tonydspaniard]

That sounds a good idea but a couple of questions comes to my mind:

• what would be the criteria for adopting an extension as official
• would other contributions left aside just because they are not officially supported?
• who is going to accept them as official extension? managing is certainly a lot of work as proven on Yii 1. ext.
• why not writing some guidelines for an extension to be officially listed to get rid of badly written extensions?

About OpenAuth / OpenId agree with @klimov-paul for consumer and provider (to interact with social networks anybody can use something like http://hybridauth.sourceforge.net/userguide.html)

[PrplHaz4]

I beleive the "official extension" discussion warrants its own issue, but will post my thoughts here for now.

Criteria for what makes it eligible to be "official":

• Matching license
• Needs code review from core team member (or by someone qualified*) - sponsor perhaps?
• Fulfills common or popular pattern missing from core framework
• Follows conventions used in yii blog (assumes yii-blog, or whatever new de-facto tutorial follows "best" practice)
• 2+ active committers to prevent stagnation/keep current with framework updates
• Decently vetted README - what it's for, example usage, alternatives, pros + cons, changelog

Contributions should not be left aside, as good ones should be considered for official status or will meet more niche standards

Accepted by community or core-team vote (when all criteria are present). Community vote will only be relevant if community is active and can not accept every addition without consideration. Management should be more involved for each extension, but proliferation of extensions should be reduced if there are official options - more attention is paid to fewer items.

Guidelines - yes please!

[klimov-paul]

What should be a name for such extension?

• externalauth
• authexternal
• authconsumer
• authclient

opinions?

[samdark]

Out of proposed variants I think authclient is the best variant. Second place goes to authconsumer.

[nineinchnick]

+1 to authconsumer, consumer better fits with OAuth terminology, auth and client are such common words

[psihius]

My vote goes to authclient, as it represents exactly what it is.