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.
Tuesday, January 19, 2010 at 12:15AM 