compared with
Current by Gary Hockin
on Jun 01, 2012 13:09.

(show comment)
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (59)

View Page History
{toc}
<ac:macro ac:name="toc" />

h2. Overview
<h2>Overview</h2>

<p>OAuth 2.0 is the next evolution of the OAuth protocol which was originally created in late 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.</p>

A <p>A growing number of large API providers now use an implementation of OAuth 2.0 to authenticate access. Presently ZF 1 has an OAuth component but is limited to OAuth1 as OAuth2 breaks compatibility with OAuth1. This RFC describes the behavior of adding a new OAuth2 component that will:</p>
* Bring OAuth2 Client capabilities to ZF2
<ul>
<li>Bring OAuth2 Client capabilities to ZF2</li>
* Allow <li>Allow configuration for various OAuth2 draft specifications that are currently in use</li>
* Bring <li>Bring common options for the most common vendor use cases (e.g. Google &amp; Facebook)</li>
* For instance; some vendors call client_id different things.
* Bring OAuth2 Server capabilities to ZF2
<li>For instance; some vendors call client_id different things.</li>
<li>Bring OAuth2 Server capabilities to ZF2</li>
</ul>

h2. Proposal

<h2>Proposal</h2>

h3. Goals

* Implement OAuth2 client and server to OAuth specifications
* Allow configuration of OAuth2 client based on vendor implementations, as simply as possible
* Bring in most common vendor variations as options
<h3>Goals</h3>

<ul>
<li>Implement OAuth2 client and server to OAuth specifications</li>
<li>Allow configuration of OAuth2 client based on vendor implementations, as simply as possible</li>
<li>Bring in most common vendor variations as options</li>
</ul>

h3. Architecture


h4. OAuth2 Client
<h3>Architecture</h3>

The OAuth2 client will create a general encapsulation around the OAuth2 specification. &nbsp;The client will be configurable in what the keys are called to make it&nbsp;future&nbsp;proof against existing OAuth2 drafts as well as implementations. Specific vendor options *should* be available to allow the easiest possible way of consuming the service.

The way the client has been implemented can be seen presently at https://github.com/Spabby/ZendService-OAuth2. Please note, the naming convention is simply for development, and is entirely what this RFC should be looking to solidify. The basic premise is that the client should work with a number of popular vendors out-of-the-box, and that configuring for your specific vendor should be very easy. With the current code, to start using the Google API you simply would need the access token gain by:
<h4>OAuth2 Client</h4>

<p>The OAuth2 client will create a general encapsulation around the OAuth2 specification. &nbsp;The client will be configurable in what the keys are called to make it&nbsp;future&nbsp;proof against existing OAuth2 drafts as well as implementations. Specific vendor options <strong>should</strong> be available to allow the easiest possible way of consuming the service. </p>
{code}
<p>The way the client has been implemented can be seen presently at <a class="external-link" href="https://github.com/Spabby/ZendService-OAuth2">https://github.com/Spabby/ZendService-OAuth2</a>. Please note, the naming convention is simply for development, and is entirely what this RFC should be looking to solidify. The basic premise is that the client should work with a number of popular vendors out-of-the-box, and that configuring for your specific vendor should be very easy. With the current code, to start using the Google API you simply would need the access token gain by:</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$OAuth2 = new OAuth2(new Options\Vendor\GoogleOptions());
$accessToken = $OAuth2->getAccessToken();
{code}
]]></ac:plain-text-body></ac:macro>

<p>This means that the component would ship with a number of vendor option files, which may be subject to change if a vendor changes their implementation details.</p>

h4. OAuth2 Server
<h4>OAuth2 Server</h4>

<p>TBC</p>

h4. Where?
<h4>Where?</h4>

<p>The debate has been raised as to where the Client and Server implementations of OAuth2 should be within the framework. At this point, it is worth noting that the Client will have hard dependencies on Zend\Loader, Zend\Config, Zend\Session, Zend\Json, Zend\Http\PhpEnvironment\Request, Zend\Http\PhpEnvironment\Response and Zend\Http\Client.</p>

h5. 1. Inside the core Framework as Zend\OAuth2\Client or similar
<h5>1. Inside the core Framework as Zend\OAuth2\Client or similar</h5>
<p>This is pretty self-explanatory, and the preferred option. The Client and server have their own namespaces under Zend\OAuth2.</p>

Pros
* Easy to find
* Gains credibility as part of core
* Hard dependencies are not a problem

Cons <p>Pros</p>
* Stuck to ZF2 release cycles, even for minor alterations to options files
<ul>
<li>Easy to find</li>
<li>Gains credibility as part of core</li>
<li>Hard dependencies are not a problem</li>
</ul>

h5. 2. As a core component as Zend\OAuth2\Client or similar, but with vendor option files stored in ZfcService components
The core component will be housed as above, however, the OAuth2 options will be housed in their own ZfcService repositories. In some cases this will be part of a larger implementation including API access components etc. In other cases, this will be an empty repository aside from the options files. This repository would be the starting point for any service integration into ZF2.

Pros <p>Cons</p>
* Easy to find
* Gains credibility as part of core
* Hard dependencies are not a problem
* Option updates can be released independent of ZF2 release cycle
<ul>
<li>Stuck to ZF2 release cycles, even for minor alterations to options files</li>
</ul>

Cons
* Lots of nearly-empty ZfcService modules that may be confusing for people expecting fuller implementations

h5. 3. As ZfcService module ZFcService\OAuth2\Client or similar
The whole thing could be moved outside the Framework into a ZfcService module, options files included. This would allow the entire module to be released outside of the ZF2 release cycle.
<h5>2. As a core component as Zend\OAuth2\Client or similar, but with vendor option files stored in ZfcService components</h5>
<p>The core component will be housed as above, however, the OAuth2 options will be housed in their own ZfcService repositories. In some cases this will be part of a larger implementation including API access components etc. In other cases, this will be an empty repository aside from the options files. This repository would be the starting point for any service integration into ZF2.</p>

<p>Pros</p>
* Easier contribution and management
* Options and client updates can be released when required
* Fits well as a non-core installable package
<ul>
<li>Easy to find</li>
<li>Gains credibility as part of core</li>
<li>Hard dependencies are not a problem</li>
<li>Option updates can be released independent of ZF2 release cycle</li>
</ul>

Cons
<p>Cons</p>
<ul>
<li>Lots of nearly-empty ZfcService modules that may be confusing for people expecting fuller implementations</li>
</ul>


<h5>3. As ZfcService module ZFcService\OAuth2\Client or similar</h5>
<p>The whole thing could be moved outside the Framework into a ZfcService module, options files included. This would allow the entire module to be released outside of the ZF2 release cycle.</p>

<p>Pros</p>
<ul>
<li>Easier contribution and management</li>
<li>Options and client updates can be released when required</li>
<li>Fits well as a non-core installable package</li>
</ul>


<p>Cons</p>
<ul>
* Not <li>Not packaged with core, so may be tricky to find</li>
* Hard <li>Hard dependencies on ZF2 may be problematic (although probably not with composer)</li>
* May feel "bolted on", instinct is that is should be core feature as other service modules will have dependency on this
<li>May feel &quot;bolted on&quot;, instinct is that is should be core feature as other service modules will have dependency on this</li>
</ul>