Hi
I've already chatted to some of my colleagues about the status of the
OAuth2 modules in CXF, why are they there and what is next for them.
Given that the fact there are actually many concurrent OAuth2 projects
around, such as Apache Oltu, Spring Security OAuth2, plus many other
projects (including our friendly RestEasy project :-)) which do
something around OAuth2, I thought it would make sense to clarify where
do we stand with respect to the OAuth2 work and discuss few things.
A bit of history. I worked on getting OAuth2 supported in CXF mainly for
the following reason : get the CXF Security story enhanced, we have a
lot of WS security service-level support in CXF or sub-projects (Fediz),
and it seemed logical to me to do something around OAuth2 too. Most of
OAuth2 code is actually a service-level code, example, we have 3-5
OAuth2 JAX-RS service coded which gets most of the OAuth2 work done.
Coupled with the fact we had some internal requirements open ata time
and that permanent wish to do it 'myself' :-) we now get OAuth2 support
in place.
I think it is actually complete (as far as the support for the core
spec, grants and tokens are concerned), quite to the spec letter, with
most of various variations covered, we have the evidence users use it,
and IMHO it would be right to continue tuning it and adding some core
extensions around it , example, I added a support for the client-driven
token revocation [1] recently, and I can imagine adding another JAX-RS
service for the dynamic client registration support.
Where I reckon it may make sense to work with other projects is the
support for Json Web Token (JWT) and possibly OpenIdConnect.
JWT can be used within OpenIdConnect (which in itself is an OAuth2-aware
complex flow_ but also as a standalone grant. The latter presents an
immediate interest.
For example, we have some requirement to get a server application
connected to a Google Big Query server, with a JWT assertion acting as a
grant. Google offers a client side library however I wonder if we can
get a general support for these kind of interactions in CXF.
Note we have a support for SAML Bearer OAuth2 assertion grants,
something I'm planning to validate against a provider like Salesforce.
Support for JWT assertions would be done similarly, CXF AccessTokenGrant
wrapping a JWT so that the clients can use JWT grants.
Now, similarly to say OpenSaml which offers a SAML Token model and
signature facilities, it may make sense to work with a similar project
with respect to support for JWT assertions. This is what I'd like to
think about. Apache Oltu team does something about JWT - I'd like to see
more into that, and then this project is also very specific about it:
https://code.google.com/p/jsoncrypto/
I'm not sure exactly what path to take at the moment, as far as the
support for JWT is concerned. If JsonCrypto is good enough for getting a
JSON sequence signed, should we just add a basic JWT bean, pass it via
JSONProvider and get it signed (and encrypted if needed) ? Do we even
need an external library given that ultimately this is just about
signing and possibly encrypting a (JSONProvider output) *string* ? I
wonder what Colm would think about the crypto and signature support in
JsonCrypto, I guess we may be have most of those utilities somewhere in
WS code :-)...
Re OpenIdConnect: I think we may want to consider enhancing Fediz in
time to support it, with CXF itself offering a basic filter for users to
be able to get CXF connected to OpenIdConnect flows.
Thanks, Sergey
[1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-10
