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

Reply via email to