(2010-09-03) Oauth Fail Esp Twitter

Ryan Paul says: The current version of the standard— OAuth 1.0a —is an inelegant hack that lacks maturity and fails to provide clear guidance on many critical issues that are essential to building a robust authentication system. Website operators who adopt the current version of the standard have to tread carefully and concoct their own solutions to fill in the gaps in the specification. As a result, there is not much consistency between implementations. FaceBook, Twitter, and Google all have different variants of the standard that have to be handled differently by third-party applications. Twitter's approach is, by far, the worst... The OAuth specification itself describes the secret key security issue and says explicitly that implementors should not do what Twitter is trying to do.

Twitter felt that allowing FOSS Twitter clients to use OAuth posed an unacceptable risk. The company warned that it would invalidate any OAuth keys that it found published in the source code of FOSS client applications. This was deeply troubling to the developers who maintain such software, including me... In response to the concerns raised by the FOSS community, Twitter committed to implementing an alternate OAuth authentication mechanism specifically for FOSS applications... Despite promising to have it ready for FOSS client applications, Twitter still has not completed this system... By turning off Basic authentication (BasicAuth) without offering a suitable alternative for FOSS clients, Twitter effectively made it impossible for FOSS client applications to continue functioning normally.

Aside from handling the consumer secret issue poorly, Twitter's OAuth implementation has a number of bugs, defects, and inconsistencies that pose challenges for users and developers.

To be clear, I don't think that OAuth is a failure or a dead end. I just don't think that it should be treated as an authentication panacea to the detriment of other important security considerations. What it comes down to is that OAuth 1.0a is a horrible solution to a very difficult problem. It works acceptably well for server-to-server authentication, but there are far too many unresolved issues in the current specification for it to be used as-is on a widespread basis for desktop applications. It's simply not mature enough yet. Even in the context of server-to-server authentication, OAuth should be viewed as a necessary evil rather than a good idea.

As I have written in the past, I think that OAuth 2.0—the next version of the standard—will address many of the problems and will make it safer and more suitable for adoption. The current IETF version of the 2.0 draft still requires a lot of work, however. It still doesn't really provide guidance on how to handle consumer secret keys for desktop applications, for example.

Eran Hammer counters his hyperbole. But doesn't really provide a solution. Twitter, nor anyone else, should rely on the client identifier when making any meaningful decisions about an application... Last year I wrote about alternative flows... In other words, OAuth does not provide a solution to address Twitter’s requirements for managing installed application. My issue is with making this sound like the protocol is broken or unsafe. This is like people saying HTTP is broken because it doesn’t do bi-directional streaming well – it wasn’t designed to do that.