cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Initial OAuth 2.0 support for CXF 2.6.0
Date Tue, 28 Feb 2012 17:47:01 GMT
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/
>
>

Mime
View raw message