Authorization issues
So far, this article has largely focused on the technical deficiencies of Twitter's own OAuth implementation. For the rest of the article, we will be looking primarily at broader OAuth issues that also affect many other implementations. We will still be discussing OAuth in the context of Twitter, but it's important to keep in mind that the following issues are widespread and aren't necessarily specific to Twitter's implementation.
The manner in which OAuth relies on page redirection to facilitate the authentication process poses some unusual challenges that are difficult to address. One issue that has been raised is that the user remains logged in on Twitter (and might not even realize it) when he or she goes through the legitimate redirect-based authorization process that is initiated by a third-party website. This could be a problem if the user is using a computer at a public location, such as a school computer lab.
Say, for example, that a user logs into an online game and then authorizes that game to access their Twitter account. When they are done playing, they will likely log out of the game so that the next person to use the computer won't mess with their game account, but they might not realize that they need to log out of Twitter too due to their use of the OAuth authentication process that they performed during the session.
It's not clear exactly what the right behavior should be, but it's arguable that Twitter should log the user out after handing authentication to the third-party service in cases where the user wasn't already logged into Twitter before initiating the authentication request.
Another somewhat related issue is that the "Deny" button on the authorization page is really just a cancel button. If you are prompted to authorize an application that you have already authorized and you click the Deny button, Twitter will not revoke the application's existing authorization to access your account. Again, this is a situation where it's not really obvious what behavior the user should expect.
The word "Deny" has a very specific meaning that is somewhat misleading in the way that it is used on the page. I think that implementors should either change the denial button to use the word "Cancel" or make it revoke existing access in cases where it exists. Perhaps the user should be prompted. As previously stated, this is not a Twitter-specific issue—the same problem exists on Google's authorization page, too.
Phishing risks
Twitter doesn't have any kind of vetting process or validation procedure to ensure that consumer key registrants are who they claim to be. For example, there is absolutely nothing to stop me from registering a Twitter OAuth application key claiming that my company is Apple and my product is Mac OS X. When a malicious person registers a key that pretends to be a legitimate product, the company that makes that product has to go through a lengthy arbitration process with Twitter's administrators and demonstrate that they own the trademark in order to get the falsely registered key invalidated.
This problem is not unique to Twitter, but Twitter exacerbates the risk of phishing by failing to use appropriate language on its authentication page. When Twitter presents users with the option of granting access to an application, it warns the user to only allow the authorization to proceed if they trust the party requesting access, but they don't warn the user that the initiator of the request and recipient of account access could, in fact, be somebody other than the entity stated on the authorization page.
Arguably, Twitter will be able to partially mitigate the risks of such attacks by finding and invalidating fraudulently registered keys. One of the advantages of OAuth is that the malicious application will have its access to user accounts revoked when the key is invalidated. A more serious problem is when phishing attacks are perpetrated with a compromised key that came from a legitimate third-party application.
OAuth supports a callback parameter that allows the party initiating the authorization request to specify where the user's access token (the token used to access a user's account) should be sent when the authorization process is completed. A malicious individual with a compromised consumer key could request authorization in a manner that appears to be on behalf of a legitimate application, but could have the key sent to their own server so that they can control the user's account.
The user would see a normal Twitter authorization page on the official Twitter website with the name of a legitimate and safe application, but they would unknowingly be granting access to the malicious third-party that initiated the authorization request. This is especially dangerous because all of the things that users have been trained to look for to spot phishing—like the URL and the SSL certificate—will appear exactly as they should, giving the user a false sense of security.
Twitter has taken some reasonable steps to limit the risk of such an attack. Specifically, Twitter has blocked keys that are registered for the desktop from using the callback parameter. Any consumer key that is registered on Twitter for a desktop application key will only be able to use the so-called out-of-band (OOB) authorization method, which doesn't rely on redirection. This is one of the few things about Twitter's approach to OAuth that actually makes good sense. Unfortunately, it doesn't protect against such a phishing attack in circumstances where a key that has redirection enabled is compromised.
The consumer secret key for a Web application is stored on the servers of the company that operates the application, so it is unlikely to be compromised. The problem is that there are a lot of mobile applications that rely on the redirection method and configure their Twitter consumer keys to function in Web mode. This is because a very common practice for mobile applications is to use the redirection authorization method in conjunction with a custom URL handler that is registered with the platform.
The URL handler trick makes it possible for the Twitter website to hand the user's access token directly back to the application when authentication is complete. In cases where that approach is used, the application's key necessarily has to be configured as a Web key, even though it is used in a desktop application. If that key is compromised, it is susceptible to the previously described phishing attack. (It's also worth noting that there is a risk of some malicious application overriding the URL handler settings to make itself the recipient of the access token.)
Ideally, OAuth implementors should require application developers to supply the callback address when they configure their key and should not allow that setting to be overridden by the client application in a request parameter. Twitter has a field in the key configuration that allows the developers to specify a default, but they still allow client applications to use the dangerous callback override parameter.
Security is hard, let's go shopping!
Individual implementations aside, the general concept behind OAuth's redirection-based authorization process materially increases the risk of phishing. The people behind the standard are fully aware of that fact, but they don't believe that the issue should necessarily be addressed by the standard itself.
They have argued for quite some time that end users should simply be more careful and implementors should come up with best practices on their own. This is because the purpose of the OAuth standard was to mitigate the password antipattern, not to holistically solve every security problem.
"OAuth cannot help careless users, and phishing is all about not paying attention to what you do. There has been some interesting discussion about phishing on the OAuth group and the bottom line is, it is far beyond the scope of the protocol," OAuth contributor Eran Hammer-Lahav wrote in 2007.
Unfortunately, there are advocates of OAuth who are less honest than Hammer-Lahav about the standard's scope and limitations. Some proponents of the standard misrepresent its maturity and suitability for adoption while downplaying its weaknesses and risks.
When people try to raise concerns about the problems, OAuth advocates tend to argue that developers who don't like OAuth are simply lazy or don't care about security. Some of the people behind the OAuth standard try really hard to convince end users that they should expect OAuth support everywhere, even in contexts where it doesn't really work or make sense. Their attitude is that developers should man up and learn to live in the brave new OAuth-enhanced world where solving the password antipattern takes priority over every other security issue.
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. It should be approached with extreme trepidation and the high level of caution that is warranted by such a convoluted and incomplete standard. Careless adoption can lead to serious problems, like the issues caused by Twitter's extremely poor implementation.
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. In light of the heavy involvement in the draft process by Facebook's David Recordon, I'm really hopeful that the official standard will adopt Facebook's sane and reasonable approach to that problem.
Although I think that OAuth is salvageable and may eventually live up to the hype, my opinion of Twitter is less positive. The service seriously botched its OAuth implementation and demonstrated, yet again, that it lacks the engineering competence that is needed to reliably operate its service. Twitter should review the OAuth standard and take a close look at how Google and Facebook are using OAuth for guidance about the proper approach.
reader comments
62