Reading over the OAuth protocol (RFC 5849), I noticed something a little odd in section 2.1:
Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanisms such as TLS or Secure Socket Layer (SSL) (or a secure channel with equivalent protections).
and section 2.3:
Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections).
Performance
This surprised me, since I’ve always thought of/used OAuth as an “encryption-free” protocol. At it turns out, the OAuth people seem to think of the non-use (or, in fact, minimal use) of SSL as primarily a performance issue:
In 2007 when OAuth 1.0 was being created, SSL was used sparingly for APIs. As CPUs have become faster and more specialized SSL hardware has been deployed, it has become increasingly possible to operate APIs over SSL. Some APIs, like the Google Health Data API or Yahoo!’s Fire Eagle API, operate fully over SSL anyway as developers are interacting with non-public data. Using SSL obviates the primary purpose of the cryptography used in OAuth 1.0a, which was designed for transferring data over insecure channels.
Export
I think they’re missing the boat here. For mobile app developers, SSL-based protocols are a real hassle, not due to technical considerations, but due to legal ones. If you use general-purpose encryption in your app, then that app then becomes subject to bothersome export controls. (This is the case in the U.S., at least; developers in other countries may or may not face similar issues.)
A good-enough protocol like OAuth, which operates in the clear, is very handy for app developers, and it would be a big mistake to wrap it inside SSL. OAuth isn’t really secure outside of SSL, of course (Bad People can always extract a client key from your app, and steal a resource owner’s token credentials when they’re delivered over the wire) but it strikes me as good enough for the vast majority of not-that-important services.
This is probably why lots of services (Twitter!) ignore the strict language of sections 2.1 and 2.3 of the spec.
As far as I understand the OAuth on iOS situation, as long as you’re not providing the code that’s actually performing the crypto, you should* be safe from dealing with export regulations. Let Apple worry about that by using CommonCrypto on iOS. Legalities aside, letting Apple’s code do the crypto legwork is just the smart thing to do anyway; it’s difficult to get right if writing it yourself.
* I Am Not A Lawyer
Ed: With respect, I must say that my understanding is 180 degrees from yours; I believe that using crypto, whether you write it yourself, or link in AAPLs, is what lands you in the CCATS briar patch. Even making an HTTPS connection is problematic. I’d like to be wrong about this, but have been unable to convince myself than I am. You’re right about using CommonCrypto to generate the HMACs used in OAuth, thought.