Re: [OAUTH-WG] Discussion of SSL as the primary means for OAuth communication

[John Panzer <[e-mail]>]

Luke,

Thanks again for writing all of this up in such a cogent way.  Some comments
inline:

On Thu, Jan 28, 2010 at 7:29 AM, Luke Shepard <[e-mail]> wrote:

>  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?
>

To these, I'd also add the obvious:  SSL data is protected from reading in
transit, while (only) OAuth signed data is not.  This is important for many
kinds of data passed in API calls.


>
> == 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.
>

Note that GMail recently turned on SSL for all user requests (for other
reasons), constituting a natural experiment in what happens to a large
service without and with SSL.  I don't know if there are data we can share
about performance impact, but I can investigate.


>
> -- 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.
>

Apparently StartSSL will sign a certificate for free.  I have not tried it
out.


>
> -- 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.
>

Shouldn't we be assuming HTTP keep-alive connections for APIs where latency
and performance is a concern (and where there is sufficient traffic to make
keep-alives a good tradeoff)?  So the cold-start time may be higher, but the
amortized cost may approach negligible.  It's the initial SSL handshake that
costs, and you can re-use the same SSL connection across multiple calls to
any path on a given host.  Switching between hosts of course requires
another connection, and this would drive API design.  But it should drive
API design anyway if latency is a concern, as the initial TCP connection
ain't cheap either.


>
> -- 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.
>

This is true but does the structure need to be standardized?  (Assuming it's
the SP that would verify the information it originated of course.)


>
> == 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.
>

I agree with the long tail argument, and if there is a requirement for
servers to support SSL as an option then client implementors could make this
choice.  If it's left up to servers to decide though, then client
implementors generally have to deal with the full complexity of both
options, unless they write to exactly one provider of choice.  Since we're
hoping/planning that common libraries will be the main way client developers
interact with all this though, that means that the complexity is pushed to
the library developers -- forcing libraries to make a choice between
complexity and full compatibility is not good for the ecosystem.

I would love to see some public data on the performance trade-offs of SSL
for API use cases, because I suspect that it is much lower than some people
think for a properly designed API with keep-alive connections.  (The
security issues already discussed are another point, I'm just talking about
server cost and latency hit here.)


> Please let me know if I’m missing something or if my assumptions sound
> incorrect.
>


>
> -Luke Shepard
> Software Engineer, Facebook Platform
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>