In the discussions around the OAuth WRAP spec, one of the questions often asked is, "why use SSL exclusively?" Several of us have done a lot of thinking on it and I wanted to articulate my understanding of the pros and cons of the approach for discussion. The use case I primarily have in mind is that of a web service, like Facebook, Twitter, or Google services. Our service is primarily authenticated via the Web, but we have a use for all of the WRAP profiles (web app, client app, desktop, mobile).
Overall, I think that the simplicity of using SSL outweighs all the associated costs for most developers. However, we should offer plaintext signatures as an optional performance enhancement for advanced developers. == Advantages of using SSL for API calls -- It's overwhelmingly simpler for developers. I've implemented OpenID and OAuth, and I've worked for years with developers trying to handle signatures on the Facebook Platform. In my experience, calculating signatures is one of the most complex and difficult parts of an authentication protocol, and developers often get it wrong. By moving that piece down the stack we can get it out of their way and let developers focus on building their apps. -- Existing tools ecosystem It's not that SSL is a simpler encryption protocol than OAuth (it's not) but rather that commonly available tools almost universally support it - every major web browser, as well as most libraries for making HTTP requests (like curl) have built-in support for SSL. For OAuth 1.0, you need to use a client library just to construct your very first request. -- Smaller client libraries A good chunk of code in many client libraries is devoted to calculating and verifying signatures. For example, the OpenID PHP library imports several BigMath modules and encryption schemes. Even the relatively simpler Facebook client library requires several functions to sign requests. This makes the client libraries a black box and impedes understanding. Wouldn't it be great if we could write a protocol that doesn't even require a client library to implement? If I could just make an authenticated API request in my browser, as easily as with Basic Auth? == Disadvantages of using SSL for API calls -- Difficulties of debugging Both signatures and SSL present difficulties in debugging, but they tend to be different. While with signatures you worry about composing the arguments wrong or using the wrong algorithm, with SSL you worry about reading the request over the wire. You can't sniff a request, and to intercept it, you need an HTTP proxy that understands SSL, and you need to worry about invalid certificate errors. To aid in this, providers will probably offer a non-SSL endpoint for debugging, but they may need to set up a sandbox environment to prevent damage from tokens exposed in plaintext. -- Variable costs for providers Server CPU costs will increase when handling SSL requests - especially on every API call instead of just at the auth stage. At scale, this can become expensive, although it can be offset by using specialized hardware to terminate the SSL connection. All the big companies I've talked to are comfortable trading these higher costs for increased adoption due to the simplicity. -- Fixed costs for smaller providers There is a fixed cost to obtaining and signing an SSL certificates, although that has dropped in recent years such that an operator can have a cert signed for a single domain for pretty cheap. -- Latency SSL connections take more time to establish than normal HTTP connections. Servers can use specialized hardware to speed it up, but clients rarely do, which means that for client-to-server API requests, there may be some higher latency in each request. Smaller, mobile devices may be disproportionately affected by this, but as they grow more powerful it's less of a concern. Already today newer phones can handle SSL just fine. -- Browser limitations for cross domain communication A more niche disadvantage is that some cross domain communication techniques require the protocol of the parent page to match that of the endpoint being queried. So for example, in some browsers, for some API calls, it would be impossible to make an API call to an HTTPS endpoint from a normal HTTP page. However, as browsers advance and HTML5 methods like postMessage become more common, this will become less of an issue. -- Verifying information on the relying party If information is passed from a Service Provider to a Consumer through the user's browser, then that information cannot be verified without an API call, unless a signature is provided. Similar to stateful vs. stateless mode in the OpenID 2.0 spec, the signature can serve as a performance enhancement to avoid an API call. == Providing a non-SSL option for the short head Most platforms tend to have a small number of fairly large developers and then a really large number of smaller developers. The former are typically experienced (or at least, they are by the time they get big) and have made a large investment in the platform. The latter range from experienced developers to amateurs to folks that would not typically program. For this spec to be successful, it must meet the needs of both groups. Facebook is very interested in adopting OAuth WRAP / 2.0 / whatever because we want to help our long tail developers use our platform more easily. For the long tail, the simplicity provided by SSL will be crucial. It means smaller or nonexistent client libaries, it means that developers can just try out the API by typing it into a web browser, and it will help reduce debugging and maintenance costs. However, for the short head of high volume developers, we probably want an option to use something other than SSL to make secure requests. These developers tend to have already solved the low hanging performance fruit, and for them it may be a significant penalty to pay the SSL connection cost on every request. To that end, I think it's pretty important that OAuth 2.0 support a method other than SSL as an option for advanced developers. But it should be just that - an option, and only for advanced developers, so that beginning programmers and folks learning an API don't need to worry about signatures when they just want to play around. Please let me know if I'm missing something or if my assumptions sound incorrect. -Luke Shepard Software Engineer, Facebook Platform
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
