Why Facebook doesn't implement OAuth today
In this session, we (Luke Shepard and David Recordon from Facebook) talked about some of the technical reasons why Facebook hasn't implemented OAuth.
- 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
- 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.
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.
Brian Eaton showed that OAuth WRAP addresses many of these concerns- fewer HTTP requests, simpler libraries, easier to understand. It also supports multiple profiles.
- Whiteboard image from the talk: http://iiw.idcommons.net/images/c/c2/Oauth_fbconnect_comparison.pdf
- OAuth WRAP: http://wiki.oauth.net/OAuth%20WRAP
- Facebook Connect auth implementation: http://github.com/facebook/connect-js/blob/master/src/core/auth.js#L211