Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of sberyozkin@gmail.com
 designates 74.125.82.169 as permitted sender)
Received-SPF: pass (google.com: domain of sberyozkin@gmail.com designates
 10.180.99.7 as permitted sender) client-ip=10.180.99.7;
Message-ID: <4F452AF0.8040300@gmail.com>
Date: Wed, 22 Feb 2012 17:50:40 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: CXF Dev <dev@cxf.apache.org>
Subject: Re: Initial OAuth 2.0 support for CXF 2.6.0
References: <4F428876.6090104@gmail.com>
In-Reply-To: <4F428876.6090104@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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