Auth to See the Wizard

(or, I wrote an OAuth Replacement)



It’s me again.

The fuck OAuth guy.

Before that I was the guy who wrote this and then this (and then I took my name off it).

I wrote a replacement protocol and thought you might want to check it out.

Well, sort of. I didn’t write a protocol. I wrote a JavaScript module providing a full authentication and authorization solution for building web applications. I am done with protocols and specifications. At the end of the day, I needed a working solution I could deploy and trust. The problem with security protocols is that they are useless without an equally solid implementation. The only point in a protocol is interoperability and I don’t care about interoperability. I just want to build great products.

I actually wrote three modules.

Iron is a simple way to take a JavaScript object and turn it into a verifiable encoded blob. Hawk is a client-server authentication protocol providing a rich set of features for a wide range of security needs. Oz combines Iron and Hawk into an authorization solution. Together these three modules provide a comprehensive and powerful solution.

I’ll take some questions now.

How is Oz different from OAuth?

OAuth, especially 1.0, is based on solid, well established security best practices. There is no reason to invent something new. OAuth 2.0 added the foundation for building highly scalable solutions. Any new protocol should be based directly on this existing body of work and Oz does just that. It throws out all the silly wire protocol parts because they add no value. Oz makes a lot of highly opinionated decisions about how to implement the things that actually matter. If you understand OAuth well, you should be able to pick up Oz and Hawk pretty quickly.

What so cool about it?

Oz provides a complete solution with full support for access scopes, delegation, credential refresh, stateless server scalability, self-expiring credentials, secret rotation, and a really solid authentication foundation. Some would say Oz goes a bit overboard in layering security but I don’t think there is ever enough of that. The implementation is broken up into small utilities which can be composed together to build other solutions with different properties. And by braking it into three modules, you get to use just the bits you want.

Does it require client-side cryptography?

Yes. Building a solution without security layers is irresponsible and stupid. Don’t do that. Bearer tokens are a bad idea. That said, Hawk, the layer providing the authentication component is trivial to implement. It’s a simple HMAC over a few strings. No sorting and encoding and all that nonsense.

Who should use it?

Me, mostly. I wrote this for myself because OAuth 1.0 is based on obsolete requirements, and I rather stick pencils in my eyes than use OAuth 2.0. If you are a happy OAuth user (regardless of the version), I say stick with it. But if you don’t like it or looking for an alternative (and are using JavaScript), to the best of my knowledge, Oz is the only other option. It is particularly smooth experience when also using hapi.

Is it done?

Yes and no. The core protocol is done and is in great shape. It has been stable for over two years. You can expect the same quality engineering I’ve put into hapi. The code is lean, clean, and it goes out of its way to protect against developer mistakes. What’s not done are the workflows such as the OAuth 2.0 implicit grant. Right now Oz provides an OAuth 1.0-like workflow, but more workflows (especially for mobile) will be added soon. Oz is in active development and will be the core security component of my new project. Expect it to get better as I continue to use it myself.

Is there going to be a specification?

Not if I had to write it. Honestly, I think a specification is a waste of time. I don’t care about Oz on platforms other than JavaScript. While Hawk and Iron have already been ported to other platforms, I am not aware of Oz ports yet.

What the background behind Oz?

Oz was initially an OAuth 2.0 higher-level protocol developed for the Yahoo Sled project (now open sourced as Postmile). In fact, Postmile turned out to be the beginning of a lot of cool stuff including the entire hapi ecosystem. However, it turned out, the OAuth bits were adding no value and compliance just made development slower and more complicated. My initial focus was on the authentication bits which resulted in Hawk. Hawk is actually widely used already and was the foundation of the Mozilla identity API. Iron followed providing the token format needed to send self-encoded information securely (and is heavily used by hapi users). I then got stuck on Oz for about three years because I didn’t have a use case for it. I left it alone for a while until it was time to put the final touches on it.

Got more questions?

Just open an issue and I’ll do my best to answer.