Initial OAuth 2.0 support for CXF 2.6.0

[Sergey Beryozkin <sb...@gmail.com>]

Hi

I've started working on the initial OAuth 2.0 support to be available in 
CXF 2.6.0 [1].

We already provide OAuth 1.0 support starting from CXF 2.5.0 [2] - this 
has been continuously enhanced during the last few months and I think it 
is capable enough for users seeking to write OAuth 1.0 applications with 
CXF to be able to rely upon it.

However OAuth 2.0 [3], is really going to hit the mainstream IMHO soon 
enough and we are already seeing some demand for the OAuth 2.0 support.
Thus I've started prototyping the initial code to do with supporting the 
OAuth 2.0 Authorization Code Grant [3] and the simple bearer token [4]; 
this combination is the closest to the OAuth 1.0 3-leg flow, further 
optimized by dropping the requirement to get a request token round trip.

I'd like to keep the OAuth 1.0 code in 2.6.0 - there are quite a few 
OAuth 1.0 deployments out there and it would not surprise me if some 
users wanted to start with OAuth 1.0 gievn that it's well understood.
Besides, despite OAuth 2.0 offering arguably a simpler alternative to 
the complete OAuth 1.0 flow, IMHO it is much more complex 
specification-wise. So I think we can see OAuth 1.0 being around for 
some time...

The other thing I'd like to mention is the possibility of relying on the 
other OAuth 2.0 libraries such as Amber[5]. At the moment Amber has not 
been released yet. Personally I'll be open to reusing some of Amber's 
code or who knows even contributing back to the project, but at the 
moment I think it is simpler to prototype some base support within the 
CXF as opposed to trying to build it from the get go on the project code 
that has not been released yet. What is also important is that as far as 
CXF OAuth is concerned it is all about providing utility JAX-RS OAuth 
services with some additional utility support. The main complexity over 
time will come from the optional support for MAC or JWT tokens or say 
OpenId-Connect profiles. This is where we'd likely need some 'help' from 
the 3rd-party libraries.


So for now I'm prototyping some code and hope to make the initial bits 
contributed in a week or so, may be earlier...

Comments are welcome

Sergey


[1] https://issues.apache.org/jira/browse/CXF-4112
[2] http://cxf.apache.org/docs/jax-rs-oauth.html
[3] http://tools.ietf.org/html/draft-ietf-oauth-v2-23
[4] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17
[5] http://incubator.apache.org/amber/

Re: Initial OAuth 2.0 support for CXF 2.6.0

[Sergey Beryozkin <sb...@gmail.com>]

Here is what we have at the moment:
- support for the authorization code and implicit flows, the former is 
tested in a demo (to be highlighted later on), the latter is not yet - 
but it's very closely related to the former, it's redirection based so 
should be quite close to being supported well...
- client_credentials,

Things to do for 2.6.0:
- fix java docs
- documentation on the wiki
- refresh token flow support - should be really simple, it's not really 
a flow, just a request to refresh, not a problem if postponed till later 
2.6.x versions
- few other minor fixes

After 2.6.0 a go at the saml2 grants would need to be taken, we have a 
lot of supporting code in place already, but the challenge is to see how 
the OAuth2 data provider interface copes with such complex grant 
processors, I think once we do it then JWT, etc will be just supported 
really easy.
The other enhancement which may be considered is support for 
OpenId-Connect - which is mostly about supporting so called code+token 
flows, OpenId itself will be managed by the 3rd party lib, and the 
support in CXF would be mostly about redirecting to the right endpoints :-)



Sergey



On 28/02/12 17:47, Sergey Beryozkin wrote:
> I've changed the package segment from "oauth" to "oauth2"
> in the OAuth20 module to avoid the collision with the classes in OAuth
> 1.0 one, I was a bit nervous about "2" in oauth2 but at the then I
> thought it would be quite a few years (5-10 ?) before we start talking
> about OAuth 3.0 :-) so hopefully it will go okay...The other thing is
> that OAuth 2.0 is a new protocol completely though some similarities
> with OAuth 1.0 do remain, thus the scope for sharing the 'oauth' segment
> is pretty limited, possibly to very few support classes only
>
> Cheers, Sergey
>
> On 22/02/12 17:50, Sergey Beryozkin wrote:
>> Hi,
>>
>> I added some initial code here:
>> http://svn.apache.org/viewvc?rev=1292416&view=rev
>>
>> now, the actual refactoring will start next :-). I think this code is
>> not optimal mildly speaking :-), but I think we will tune it pretty
>> quickly by building an authorization code flow demo against it...
>>
>> Cheers, Sergey
>>
>> On 20/02/12 17:52, Sergey Beryozkin wrote:
>>> Hi
>>>
>>> I've started working on the initial OAuth 2.0 support to be available in
>>> CXF 2.6.0 [1].
>>>
>>> We already provide OAuth 1.0 support starting from CXF 2.5.0 [2] - this
>>> has been continuously enhanced during the last few months and I think it
>>> is capable enough for users seeking to write OAuth 1.0 applications with
>>> CXF to be able to rely upon it.
>>>
>>> However OAuth 2.0 [3], is really going to hit the mainstream IMHO soon
>>> enough and we are already seeing some demand for the OAuth 2.0 support.
>>> Thus I've started prototyping the initial code to do with supporting the
>>> OAuth 2.0 Authorization Code Grant [3] and the simple bearer token [4];
>>> this combination is the closest to the OAuth 1.0 3-leg flow, further
>>> optimized by dropping the requirement to get a request token round trip.
>>>
>>> I'd like to keep the OAuth 1.0 code in 2.6.0 - there are quite a few
>>> OAuth 1.0 deployments out there and it would not surprise me if some
>>> users wanted to start with OAuth 1.0 gievn that it's well understood.
>>> Besides, despite OAuth 2.0 offering arguably a simpler alternative to
>>> the complete OAuth 1.0 flow, IMHO it is much more complex
>>> specification-wise. So I think we can see OAuth 1.0 being around for
>>> some time...
>>>
>>> The other thing I'd like to mention is the possibility of relying on the
>>> other OAuth 2.0 libraries such as Amber[5]. At the moment Amber has not
>>> been released yet. Personally I'll be open to reusing some of Amber's
>>> code or who knows even contributing back to the project, but at the
>>> moment I think it is simpler to prototype some base support within the
>>> CXF as opposed to trying to build it from the get go on the project code
>>> that has not been released yet. What is also important is that as far as
>>> CXF OAuth is concerned it is all about providing utility JAX-RS OAuth
>>> services with some additional utility support. The main complexity over
>>> time will come from the optional support for MAC or JWT tokens or say
>>> OpenId-Connect profiles. This is where we'd likely need some 'help' from
>>> the 3rd-party libraries.
>>>
>>>
>>> So for now I'm prototyping some code and hope to make the initial bits
>>> contributed in a week or so, may be earlier...
>>>
>>> Comments are welcome
>>>
>>> Sergey
>>>
>>>
>>> [1] https://issues.apache.org/jira/browse/CXF-4112
>>> [2] http://cxf.apache.org/docs/jax-rs-oauth.html
>>> [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-23
>>> [4] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17
>>> [5] http://incubator.apache.org/amber/
>>
>>

Re: Initial OAuth 2.0 support for CXF 2.6.0

[Sergey Beryozkin <sb...@gmail.com>]

I've changed the package segment from "oauth" to "oauth2"
in the OAuth20 module to avoid the collision with the classes in OAuth 
1.0 one, I was a bit nervous about "2" in oauth2 but at the then I 
thought it would be quite a few years (5-10 ?) before we start talking 
about OAuth 3.0 :-) so hopefully it will go okay...The other thing is 
that OAuth 2.0 is a new protocol completely though some similarities 
with OAuth 1.0 do remain, thus the scope for sharing the 'oauth' segment 
is pretty limited, possibly to very few support classes only

Cheers, Sergey

On 22/02/12 17:50, Sergey Beryozkin wrote:
> Hi,
>
> I added some initial code here:
> http://svn.apache.org/viewvc?rev=1292416&view=rev
>
> now, the actual refactoring will start next :-). I think this code is
> not optimal mildly speaking :-), but I think we will tune it pretty
> quickly by building an authorization code flow demo against it...
>
> Cheers, Sergey
>
> On 20/02/12 17:52, Sergey Beryozkin wrote:
>> Hi
>>
>> I've started working on the initial OAuth 2.0 support to be available in
>> CXF 2.6.0 [1].
>>
>> We already provide OAuth 1.0 support starting from CXF 2.5.0 [2] - this
>> has been continuously enhanced during the last few months and I think it
>> is capable enough for users seeking to write OAuth 1.0 applications with
>> CXF to be able to rely upon it.
>>
>> However OAuth 2.0 [3], is really going to hit the mainstream IMHO soon
>> enough and we are already seeing some demand for the OAuth 2.0 support.
>> Thus I've started prototyping the initial code to do with supporting the
>> OAuth 2.0 Authorization Code Grant [3] and the simple bearer token [4];
>> this combination is the closest to the OAuth 1.0 3-leg flow, further
>> optimized by dropping the requirement to get a request token round trip.
>>
>> I'd like to keep the OAuth 1.0 code in 2.6.0 - there are quite a few
>> OAuth 1.0 deployments out there and it would not surprise me if some
>> users wanted to start with OAuth 1.0 gievn that it's well understood.
>> Besides, despite OAuth 2.0 offering arguably a simpler alternative to
>> the complete OAuth 1.0 flow, IMHO it is much more complex
>> specification-wise. So I think we can see OAuth 1.0 being around for
>> some time...
>>
>> The other thing I'd like to mention is the possibility of relying on the
>> other OAuth 2.0 libraries such as Amber[5]. At the moment Amber has not
>> been released yet. Personally I'll be open to reusing some of Amber's
>> code or who knows even contributing back to the project, but at the
>> moment I think it is simpler to prototype some base support within the
>> CXF as opposed to trying to build it from the get go on the project code
>> that has not been released yet. What is also important is that as far as
>> CXF OAuth is concerned it is all about providing utility JAX-RS OAuth
>> services with some additional utility support. The main complexity over
>> time will come from the optional support for MAC or JWT tokens or say
>> OpenId-Connect profiles. This is where we'd likely need some 'help' from
>> the 3rd-party libraries.
>>
>>
>> So for now I'm prototyping some code and hope to make the initial bits
>> contributed in a week or so, may be earlier...
>>
>> Comments are welcome
>>
>> Sergey
>>
>>
>> [1] https://issues.apache.org/jira/browse/CXF-4112
>> [2] http://cxf.apache.org/docs/jax-rs-oauth.html
>> [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-23
>> [4] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17
>> [5] http://incubator.apache.org/amber/
>
>

Re: Initial OAuth 2.0 support for CXF 2.6.0

[Sergey Beryozkin <sb...@gmail.com>]

Hi,

I added some initial code here:
http://svn.apache.org/viewvc?rev=1292416&view=rev

now, the actual refactoring will start next :-). I think this code is 
not optimal mildly speaking :-), but I think we will tune it pretty 
quickly by building an authorization code flow demo against it...

Cheers, Sergey

On 20/02/12 17:52, Sergey Beryozkin wrote:
> Hi
>
> I've started working on the initial OAuth 2.0 support to be available in
> CXF 2.6.0 [1].
>
> We already provide OAuth 1.0 support starting from CXF 2.5.0 [2] - this
> has been continuously enhanced during the last few months and I think it
> is capable enough for users seeking to write OAuth 1.0 applications with
> CXF to be able to rely upon it.
>
> However OAuth 2.0 [3], is really going to hit the mainstream IMHO soon
> enough and we are already seeing some demand for the OAuth 2.0 support.
> Thus I've started prototyping the initial code to do with supporting the
> OAuth 2.0 Authorization Code Grant [3] and the simple bearer token [4];
> this combination is the closest to the OAuth 1.0 3-leg flow, further
> optimized by dropping the requirement to get a request token round trip.
>
> I'd like to keep the OAuth 1.0 code in 2.6.0 - there are quite a few
> OAuth 1.0 deployments out there and it would not surprise me if some
> users wanted to start with OAuth 1.0 gievn that it's well understood.
> Besides, despite OAuth 2.0 offering arguably a simpler alternative to
> the complete OAuth 1.0 flow, IMHO it is much more complex
> specification-wise. So I think we can see OAuth 1.0 being around for
> some time...
>
> The other thing I'd like to mention is the possibility of relying on the
> other OAuth 2.0 libraries such as Amber[5]. At the moment Amber has not
> been released yet. Personally I'll be open to reusing some of Amber's
> code or who knows even contributing back to the project, but at the
> moment I think it is simpler to prototype some base support within the
> CXF as opposed to trying to build it from the get go on the project code
> that has not been released yet. What is also important is that as far as
> CXF OAuth is concerned it is all about providing utility JAX-RS OAuth
> services with some additional utility support. The main complexity over
> time will come from the optional support for MAC or JWT tokens or say
> OpenId-Connect profiles. This is where we'd likely need some 'help' from
> the 3rd-party libraries.
>
>
> So for now I'm prototyping some code and hope to make the initial bits
> contributed in a week or so, may be earlier...
>
> Comments are welcome
>
> Sergey
>
>
> [1] https://issues.apache.org/jira/browse/CXF-4112
> [2] http://cxf.apache.org/docs/jax-rs-oauth.html
> [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-23
> [4] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17
> [5] http://incubator.apache.org/amber/


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com