Why Facebook doesn't implement OAuth today

From IIW

In this session, we (Luke Shepard and David Recordon from Facebook) talked about some of the technical reasons why Facebook hasn't implemented OAuth.

High level:

  • We generally respond to our customers. Some of them request open standards, but more important is that our API is fast and simple.
  • OAuth is more complex and less performant than our own native authentication mechanism
  • We (Facebook) really want to use OAuth but I can't justify deploying and maintaining a new system that will be slower and create more maintenance headaches for our customers
  • OAuth WRAP looks like it will solve most or all of these problems

Performance concerns

  • It takes only two HTTP requests to get a user session in Javascript and start making API calls. With vanilla OAuth, it takes four HTTP requests - two on the server, and two on the client.
  • URL length is a big deal. We try to keep ours terse. The full-URI-based approach of many open standards leads to ridiculously long URLs that have perf impacts.
  • We do some tricks to support client side caching and JS api calls, whereas existing protocols mostly assume server-side setups.

See the attached PDF for the diagram showing the difference between the two flows.

Response

There was active participation from Allen Tom, Joseph Smarr, Brian Eaton, Eric Sachs, and a few others.

  • Several people asked why we don't just support OAuth as an alternative - at least it would be open, right? My response was that if we use an open protocol, we would like to eventually use it exclusively. It is draining and expensive to support multiple authentication mechanisms, so why would we roll something out that wasn't a step in the direction we want to go?
  • Agreement from big companies. At Google and Yahoo, which have had OAuth endpoints for some time, they both report that their proprietary protocols (AuthSub and BBAuth) are still dominant. Why?
  • You can only roll out a standard that isn't in your strong business interest for so long. If internal proponents push for a company to launch something that isn't well adopted, then they lose credibility for the next attempt.
  • Why not OpenID/OAuth hybrid? Main concern is URL length and complexity of unifying two protocols in a library.
  • Standards are sometimes too quick to close security holes that proprietary protocols deem acceptable. For instance, Facebook passes the session back directly in the response, and even stores it in cookies, which means that a poorly-written endpoint could leak it to images or iframes that are included in the page. OAuth protects against this flaw, but BBAuth does not. So general question is if security risks are acceptable in proprietary protocols, then shouldn't they be possible in the standard?
  • Library support is often touted as a reason to adopt OAuth, but there was general agreement that library quality is overall pretty poor. I think many agreed that if we make the actual protocol much simpler, then we will get a lot more general library support.

Future

Brian Eaton showed that OAuth WRAP addresses many of these concerns- fewer HTTP requests, simpler libraries, easier to understand. It also supports multiple profiles.

A bunch of OAuth WRAP folks are planning to meet Tuesday Dec 7 at Facebook HQ to more specifically hammer out an OAuth WRAP profile optimized for JavaScript authentication. It's great to see forward momentum come out of this meeting.

Links

Retrieved from "https://iiw.idcommons.net/index.php?title=Why_Facebook_doesn%27t_implement_OAuth_today&oldid=1485"