In the midst of what might seem like a crisis when viewed from within the web’s echo chamber, it can be difficult to sort fact from fiction, threat from hysteria. Such was the case last weekend when three terms that typically evoke passionate responses were combined in a single meme — OAuth, Phishing, and Twitter.
The source of concern was a scam spreading on Twitter via fake direct messages. These messages mimicked Twitter’s own opt-in email notifications that go out when users of the service receive a direct message. You can read the details on Twitter’s blog, released in a responsible and timely fashion during the incident. Engineers no doubt worked overtime to mitigate this while the rest of us enjoyed holiday leftovers and more relaxing weekends.
It didn’t take long for some to try and link the incident to Twitter’s lack of OAuth support in their API. Some, such as Chris Messina, clearly understood the distinction but others seemed to blur the line. This post is an attempt to demonstrate the orthogonality of OAuth and phishing with regard to this specific incident.
Phishing Defined
Let’s start with a precise definition of phishing, taken from Wikipedia and quoted on Twitter’s own blog covering the incident:
“Phishing is the criminally fraudulent process of attempting to acquire sensitive information such as usernames, passwords and credit card details by masquerading as a trustworthy entity in an electronic communication.”
If your inbox looks like mine, phishing attempts are nothing new. Links typically contain misleading subdomains, misspelled top level domains, and other tactics in an attempt to establish enough trust to get a click, after which a fake site mirroring the original attempts to collect the sensitive information.
This was the tactic employed by the scammers over the weekend in their attack against Twitter users and it is almost completely unrelated to OAuth or lack thereof in Twitter’s API. The end-to-end flow of receiving an email, clicking a link, and logging into what looks like a legitimate site does not change when using OAuth. This exact attack is equally possible for sites using OAuth.
Authentication vs. Authorization
OAuth provides a method of secure API authorization where as the act of logging into a site is the act of authentication. For sites that use OAuth, users normally must authenticate prior to authorizing third party API access. These are two separate steps. The difference between authentication and authorization isn’t mere pedantry; it is critical to the understanding of OAuth and its place along side complementary technologies such as session-based logins or OpenID.
Remember that authentication answers more of the “Who am I?” question, sometimes merely validating a claim such as “I have control of this URL,” as is the case with OpenID. Authorization handles the “I, having been authenticated, am authorized to perform this action” part of the equation.
OAuth allows scoped API access (a la valet keys) to user data. The user remains in control, having the ability to disable a particular third party’s access to data while leaving others intact. Service providers can take this as far as they want, scoping each OAuth token to specific actions rather than an all-or-nothing approach. Users under this system have no reason to give their passwords to any third parties and sites can message strongly against it without worries of curtailing API usage and its related marketing benefits.
Tying (or rather, not tying) this back to Twitter, the phishing scam was an attack to gain authentication credentials for Twitter users and had nothing to do with authorization, the domain of OAuth.
