Search
Tweets
Blogroll
Powered by Squarespace
« #hashtags #QLF? Charlie Foxtrot | Main | GarageBand '09: not bad at all »
Thursday
Dec312009

Simpler than OAuth WRAP

OAuth WRAP sprouted up because some of the original OAuth authors and initial implementors thought there were usability issues with OAuth. For example, David Recordon, one of the original OAuth authors commented that Facebook is “hearing strongly from other major implementors that OAuth has not been widely adopted by their developer communities because it is too difficult to correctly implement”.

Even though WRAP seems a step in the right direction. It’s good to make things simpler. But it still doesn’t address the common basic problems with protocols like OAuth:

It still seems too difficult. A cursory glance at the WRAP protocol shows it roughly the same length as the OAuth 1.0a spec. Granted, both protocols are in draft status, and this may be a silly comparison. I had expected a simpler version to be shorter than what it replaces.

The browser redirect anti pattern is still in full swing. WRAP fails to address this huge usability and security problem. We often talk about the password anti pattern, which boils down to: stop conditioning people to give out their passwords. Yes, this is pure evil. We need to stop this, and OAuth helps tremendously here.

The browser redirect anti pattern is scary. Like any anti pattern, this one conditions us to accept that the browser bounces us back and forth between sites. It conditions us to accept that the browser goes where it wants to, and that we are no longer the driver, but the passenger, of our web browsing.

This is dangerous and opens up phishing opportunities. The session fixation attack of the original Oauth 1.0 protocol could hardly been successful without this anti pattern.

So there has to be something simpler. At a meeting at Facebook December 8, 2009, people discussed the Netflix authorization flow, used to connect devices such as TV:s to a Netflix customer’s account. When connected, the TV can play the movies the customer adds to their queue. I think the people gathered missed that this flow can be used for all authorization, not just devices, but any web app.

The Netflix flow can be explained in a few sentences. Because the user is not connecting the TV to Netflix via the browser, a redirect less scheme was invented: The TV displays a short memorable text code to the customer, who enters this code at the Netflix website to give the device access. That’s it. Nothing more, nothing less.

The underlying protocol? Dead simple. In essence, the TV makes one call to Netflix to get a code, which it then displays to the user. Then it polls Netflix, say every 10 seconds, to see whether the code has been authorized, and if so, gets back some key to use for all future operations for that customers. If the key stops working, the customer has revoked authorization. 

This key can be used as secret tokens are used in WRAP: signature-less in the HTTP protocol header on top of SSL. Yes, the devil is in the details, but it seems this fits nicely into existing OAuth-enabled services with very little change. 

 

Reader Comments (5)

There are some issues with a client poll approach, but I agree that they're addressable.

There also needs to be a way to have publicly showing key elements so that JS apps can be published, but i've got a few ideas that may work along with this.
December 31, 2009 | Unregistered Commenterjr
In some respects, the Netflix model sounds like Bluetooth pairing: the device shows a number which the user enters on the other device. Done.
January 1, 2010 | Unregistered CommenterDGentry
We've talked a little about including a Netflix style flow in WRAP since we all like it quite a lot! It's much easier to use on devices since you don't need to type anything in on silly remote controls. Want to take a stab at writing a profile for it?
January 1, 2010 | Unregistered CommenterDavid Recordon
It's worth noting that the Netflix-style flow works in OAuth today (it was one of the original design considerations, and is based on Flickr's mobile flow).
January 2, 2010 | Unregistered CommenterBlaine Cook
@JR: Let's talk about these issues over boxed lunch the coming week
@Denny: Bluetooth pairing is a very good pointer I hadn't thought of. I'll look into what the usability and security issues are there.
@Dave: that profile is useful. I still want to see if there is a way to avoid some protocol complexity + getting rid of the 302 anti pattern. I'll write up some better design + code the next few days.
@Blaine: thanks. Good info. Flickr gave birth to many good ideas!
January 2, 2010 | Registered CommenterHans

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.