Feeling Hawkish about OAuth2 ?

You all know the recent OAuth history of course, Eran Hammer, the author of  popular OAuth1 specification, leaving the OAuth2 work group, with OAuth2 not getting much of a praise from Eran afterwards.
 
Eran has started several projects afterwards, Hawk and Oz in particular.  The former is the evolution of the MAC draft Eran and others authored as part of the OAuth2 work, the latter is the alternative to OAuth2.

Now, I do like the OAuth2 model, I think it's very flexible and allows for all sort of flows, grants and tokens being supported. I think it is next to impossible to write a perfect specification where the security risks can be ignored or forgotten about as such. I'll be happy to see Oz evolving, good luck to it, I guess it will be very healthy if it also gets the momentum, but for now OAuth2 is what I'm interested in mostly.

That said, I really liked that draft. May be because I could read it without feeling like I needed to become a security pro and even implement it in a couple of days (with the major help from Sasi. M) ? IMHO the draft was the closest to the original OAuth1 text describing how the temporary request token affects the signature, the details differ, but the idea is very similar, where the request token acquisition step is replaced by AS returning a Mac key to the client who becomes the holder of the key. I thought that draft was paving a direct path for OAuth1 users migrating to OAuth2.

As it happens, the OAuth2 group has initiated a new MAC token draft effort. This is a good news in itself but it just takes a different approach toward getting the MAC mechanism supported. I think it is fair to say the text is much more involved; it is written by the top experts who I happen to learn a lot from by hanging at the OAuth2 list, but the truth is, without going into the detailed analysis, is that the CXF MacAccessToken implementing the draft written by Eran and others has become lost in the translation. The draft is abandoned, the OAuth2 MAC effort  will require a completely different implementation.

Throwing the CXF MacAccessToken code away to avoid getting into the 'conflict' with the OAuth2 MAC approach has not been an option, IMHO it's still useful as a custom token mechanism and custom tokens and authentication schemes are proper OAuth2 citizens. And as I said, I do like the simplicity of the original text, as well as the fact that a distribution of the symmetric key is left unspecified, recommending TLS, etc, and what can be simpler to a key exchange over a 2-way TLS ? 


So I've looked at Hawk in more detail. It is indeed the evolution of the draft. But the core of it did stay, the simplicity of it is there. So what I just did, rather than throwing the CXF MacAccessToken code away, I simply replaced 'Mac' with 'Hawk' in the class and package names and the name of the HTTP scheme they understand, this is all I did. For example, this code implements the Hawk scheme without me changing anything (well, I added one extra space to indicate the extension data is missing in the normalization function which was required by the draft) from the original CXF code.

The Hawk documentation goes at some length clarifying it is nothing to do with OAuth. I think it is a bit off-topic given that Hawk is a proper HTTP authentication scheme, and as such it is kind of immaterial which HTTP servers rely on it to secure its resources. I guess some of its extensions are better utilized as part of Oz, but I see no problems in getting a custom OAuth2 token supporting the clients authorizing via Hawk, the new HTTP scheme.

So I'm happy that the draft has not died after all and got resurrected in the form of Hawk. Please check the documentation and contribute to the Hawk project.
And in meantime we will keep an eye on the OAuth2 MAC effort too, we can have Hawk and OAuth2 Mac tokens coexisting happily.

Enjoy. 





  

You're gonna be a star with CXF !

I've happened to listen to one of my favorite songs, All the Way to Reno from R.E.M, just recently, which probably shows me being not exactly very young :-).

Apparently the text has a lot of subtle meanings but one really can't beat its gentle rhythm leading to the listener having a kind of 'life is good' feeling, being optimistic.

"You're gonna be a star", you really can and you will...Feeling the excitement has gone out of the web services development work a bit ? You know what you need to do...
   

Use OAuth2 tokens to protect CXF SOAP endpoints

So you are a happy Apache CXF developer working with its second-to-none WS SOAP front-end, creating SOAP endpoints protected by WS-Security. Your friends from the other team have deployed few CXF JAX-RS endpoints protected by the OAuth2 filter validating the incoming OAuth2 tokens with the remote OAuth2 server.

Now, you really, really, really want to get your SOAP client code use OAuth2 tokens too, the same tokens non-SOAP RS clients use to access RS endpoints,  because it is something new to try.

So how complex can it be ? The answer: it is a child's play with Apache CXF. Follow these steps:

- Get CXF WS client code use WS-Security Binary Token mechanism as a transport for passing OAuth2 Bearer tokens to the server - easy
- If you work with WS-Policy, add one more WS-Policy alternative allowing for WS-Security Binary Tokens, in addition to the existing security alternatives, no code changes
- Add a basic OAuthRequestInterceptor extension immediately after CXF WSS4JInInterceptor which will make the extracted binary token available on the current message. All this custom interceptor will do is get the token from the message and pass it over to the super-class as suggested in the commented code.
- Make sure your OAuthRequestInterceptor does not interfere with other WS-Security authentication mechanisms if they are supported - if it is non a binary token then simply let the request continue

"Now you are talking", I can hear you saying. Give it a try please, and tell your friends from the other team how easy it was for you to join the OAuth2 game.

Stateless OAuth2 providers in CXF 3.0.0

Writing a proper OAuth2 data provider typically involves persisting the data such as access token, refresh token and transient authorization code representations in the storage of some sort (relational database, etc).

It is also a well-known fact that major OAuth2 providers often have the access token state encrypted - the clients effectively keep the token state, the server does not need to worry about persisting and looking up the tokens. It is assumed the cost of the encryption and decryption work is smaller, especially when a lot of clients are stressing the OAuth2 server.

CXF 3.0.0-milestone2, to be released shortly, introduces the dedicated utility classes to help users experimenting with encrypting and decrypting the token state.

Please check this introduction and proceed from there. Get your stateless OAuth2 server up and running in no time.

The feedback will be highly appreciated,
Enjoy.