You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Richard Snowden <ri...@gmail.com> on 2014/07/17 12:47:55 UTC

OAuth 2.0 support for server side

Do we have support for OAuth 2.0 in CXF for the server side? I mean for a
custom Authorization Server?

It's nice to use Google or Facebook for some examples, but in real world
scenarios I assume we mostly need to authenticate/authorize via custom
Identity Management Systems.

Re: OAuth 2.0 support for server side

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
On 23/07/14 10:55, Richard Snowden wrote:
> The idea is that a developer focuses only on persisting the token and grant
>> details. Check "CXF OAUth2" in Google, you will get a link to the demo
>> shipped with Talend distro. We have plans to ship few more demos directly
>> in CXF in time.
>>
>
>
> Thank you Sergey. I found the Talend demo. It helps understanding the
> principles of OAuth 2.0. But, from what I can see, most of the demo is
> hand-coded.
>
> I had hoped for a little bit more frameworky stuff, like for example in the
> Spring Security OAuth2 Module.
>
I'm interested to hear what do you think can be pushed down to the 
framework level to get the demo question even more minimized as far as 
the OAuth2 related code the user has to do is concerned.
The demo shows that the only thing the user has to do is to ship a 
custom OAuth data provider and the only thing the provider does it 
persists the data (in memory), the real providers would still want to do 
some extra validation in addition to what the framework does but the 
idea is the providers do not deal with OAuth2 flow specifics unless 
really really needed.

So, what do you think may need to be optimized ?

> Are there plans to improve OAuth 2.0 support in CXF?
>
Yes. IMHO it represents the main open development space for the secure 
CXF JAX-RS services going forward, so yes.
Short-term enhancement plans:
- support OpendConnect SP for CXF endpoints interact with OpendidConnect 
IDPs. CXF won't implement OpenidConnect IDP, Fediz will hopefully will, 
and we will interoperate with KeyCloak, Google/etc
- introduce boilerplate JAX-RS services for managing client 
registrations and the existing tokens (for the end user to directly 
revoke them if needed).
- Ship default OAuthDataProviders (Ehcache, encryption, etc)

Sergey

Re: OAuth 2.0 support for server side

Posted by Richard Snowden <ri...@gmail.com>.
The idea is that a developer focuses only on persisting the token and grant
> details. Check "CXF OAUth2" in Google, you will get a link to the demo
> shipped with Talend distro. We have plans to ship few more demos directly
> in CXF in time.
>


Thank you Sergey. I found the Talend demo. It helps understanding the
principles of OAuth 2.0. But, from what I can see, most of the demo is
hand-coded.

I had hoped for a little bit more frameworky stuff, like for example in the
Spring Security OAuth2 Module.

Are there plans to improve OAuth 2.0 support in CXF?

Re: OAuth 2.0 support for server side

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 17/07/14 11:47, Richard Snowden wrote:
> Do we have support for OAuth 2.0 in CXF for the server side? I mean for a
> custom Authorization Server?
>
Yes, see http://cxf.apache.org/docs/jax-rs-oauth2.html.

The idea is that a developer focuses only on persisting the token and 
grant details. Check "CXF OAUth2" in Google, you will get a link to the 
demo shipped with Talend distro. We have plans to ship few more demos 
directly in CXF in time.

For a more framework neutral approach I recommend trying Apache Oltu.
> It's nice to use Google or Facebook for some examples, but in real world
> scenarios I assume we mostly need to authenticate/authorize via custom
> Identity Management Systems.
>
The "authentication" is a rather ambiguous term when we talk about 
OAuth2. A user authorizing the 3rd party client application needs to 
authenticate (against Authorization Service(AS)). We can use a 3rd party 
IDP to manage SSO for user to log in with the same credentials into AS 
as well into the actual resource application. And we can also use 
Google/etc account ids to sign in, thus effectively depending on 
Google/etc (the work for supporting it in CXF will start shortly), but 
in itself it is orthogonal to the work of AS.

Thanks, Sergey