OAuth Primer: Part 1

You might not have heard of it. But, you have probably used it. If you have used Facebook’s friend finder or attached your twitter account to an application that sends tweets for you — then you have used it. Not too long ago, when you used Facebook’s friend finder you would have to enter your username & password for your gmail account. This was pretty much the state of the art for web mashups — hand your username & password off to the applications you wanted to integrate.

Although this works, there were some serious problems with this approach. For one thing, how do you know that Facebook was just going to read your contacts and not start sending email?

You didn’t, you just had to trust them.

How did you know they weren’t going to take that username & password and try to log into other services you might use?

You didn’t, you just had to trust them.

Well things have changed and that change is due to OAuth 2.0.

Although the final specification is still in draft, several vendors have plowed right ahead. Including the likes of: Facebook, Twitter, Salesforce, and Google.

The goal of OAuth 2.0 is really three fold:

  1. Make it easier for people to use distributed, cloud based applications together
  2. Make it safer for people to use applications together
  3. Remove the assumption that authentication is performed via username & password

Let’s look at each of these in the context of OAuth.

The first — make it easier. How is this done? Well, here is a good example — again let’s go back to the Facebook example. Let’s say you want to use friend finder.
You click on friend finder and if you are logged into gmail then google will simply ask you to allow Facebook to read your contacts.
In the typical flow, you are already logged into gmail — no need to enter your username & password again. This gives you a very seamless integration.

The second — make it safer. Let’s look at the previous example, I didn’t have to give Facebook my username & password. Also, Facebook is required to tell google what
it is going to do on my behalf. Facebook says it is only going to read my contacts — not send email on my behalf. If I approve, Facebook is constrained to only reading contacts.

The third — remove the username & password assumption. Let’s come back to our handy-dandy Facebook example. Let’s say gmail offered a more sophisticated option for authentication.
Let’s say they introduced a two-phase authentication system, one in which I installed a PKI certificate. Using this certificate & a password, I could log into my gmail account.
Both mechanisms are required. Facebook would never be aware that I use a stronger form of security. You could imagine scenarios like this for more enterprise solutions.

A more compelling example of the above would be using Microsoft’s Active Directory in your business as a single sign on provider for SalesForce.
You could then use applications that integrate with SalesForce via OAuth by simply logging into your Windows desktop. This is the huge promise of OAuth.

One of the challenges of cloud adoption, is many businesses have well established authentication & authorization services. They want to take advantage of the awesome capabilities of cloud applications without giving up control. This is the raging battle between the enterprise and the cloud. OAuth can help.

What does this have to do with SmartVault? Well, as part of our SDK initiative we are currently developing OAuth support into SmartVault.

More to come on this topic in Part 2.