This morning, my friend Marjolein Hoekstra (aka @CleverClogs) brings this blog entry by Terence Eden to my attention. In it, he suggests that Twitter’s OAuth is a “gaping security hole,” but what he really illuminates is that he totally does not understand the point of OAuth. Let me try and explain:
In the bad old days of Twitter only allowing HTTP Basic authentication, in order for third-party applications to access your Twitter account, you had to hand out your username and password. While this “worked” it wasn’t ideal. Why? Well, any time you changed your password — either to prevent an application from continuing to have access to your account, or out of good “security hygiene” practices of regularly changing your password — you had to go back to every application that you wanted to continue to work on your behalf. If you use more than a few applications, this quickly became a tedious process as you can imagine. Again, this was less than ideal.
Eventually, Twitter rolls out OAuth, an open implementation of a cross-service authorization scheme. Each application now requests authorization to act on a user’s behalf, and such access is now manageable per application rather than an all-or-nothing as it were with HTTP Basic auth. This is a huge win as this decouples the user’s Twitter credentials from a third-party application’s privileges to act on behalf of that user. You can now change your Twitter password to maintain good security hygiene without the inconvenience of having to update every third-party application with your new password. You can now revoke access from a single application without having to, again, update every other third-party application with your new password.
Terence, sadly, mistakes this radical improvement as a defect and a security flaw. What’s truly sad is that Terence even knows about the Twitter OAuth Connections page where one can de-authorize individual applications, yet he still missed the whole point and benefit of OAuth in the first place. How?
He suggests that “Changing a password should
Programmer, husband, father, singer, guitarist, tinkerer, reverse engineer, strange, and living in New Jersey. 
Hi,
I understand how OAuth works – and I think it’s a great idea for security. But consider the following…
Suppose a hacker somehow gets your password. She uses it to OAuth with a Twitter application. You notice strange activity and change your password. The hacker is still able to use Twitter as you. Your password has changed but the hacker’s access hasn’t been revoked – even though she is using the “old” password.
I don’t think OAuth is broken – I think that Twitter should revoke all tokens when you change your password. Otherwise changing your password has no effect on malicious users logged in through OAuth.
I only saw the OAuth Connections Page because I went looking for it. I doubt a “normal” user would give it a second though. They’ve changed their password – so all “baddies” have been kicked out. Right?
I’m not for one second questioning the security of OAuth nor its usefulness. But in this case, the lack of usability has caused a security problem.
Terence (with one R :-) )
“He suggests that “Changing a password should – in the minds of most people – mean that you need to re-enter your password even if you have previously authenticated yourself.” Is this true? Is this what “most people” (that means YOU) think?”
Yes, this is what i think as well. I value security over convenience in this case.
With all respect to the comments of Terence and Mr Anonymous: I am with Dossy on this one. Decoupling the use of user-id’s/passwords (authentication) with autorizations is a *good* thing, and best practice. It does increase security levels and therefore should be implemented as is.
What could change though, listening to the arguments by Terence and Mr A, is the proces with which Twitter, or any other OAuth supporting service, handles password changes.
It would be helpfull to see a list of OAuth enabled applications after a password change, as a reminder to the user that some applications are authorized to access their profile. Such a change would be fairly easy implemented.
In the case of someone compromising your Twitter account, the remedy is:
1) Change your password, thus locking the attacker out of your account.
2) Go into your authorized Twitter applications (on the Connections tab) and deauthorize any applications the attacker has authorized.
Again, if you are indeed correct that “most users” (and not just you and others like you) think changing your password will deauthorize all previously authorized applications through OAuth, then this is a user education issue, one that I would fix by adding a link to the Connections setting page on the password changing page with text that explains that “changing your password does not deauthorize any previously authorized applications. To do that, go to [link to Connections page]“.
I will say it outright: deauthorizing ALL OAuth tokens on a password change completely negates the value of OAuth. Period.
It seems to me that there are two kinds of password changes being talked about here – one in which the user is happy for authorized apps to continue working and one in which the user wants to say, “i’m worried my account has been compromised so re-authorize all previously authorized apps”. It doesn’t seem to me like it would be difficult to present these two, in a meaningful way, as alternative options on a password changing screen?
I agree with that option as well. It largely depends on what the outstanding tokens allow access to in my opinion. So for example I might want to revoke tokens authorizing apps that tweet on my behalf, but maybe not tokens authorizing apps to see my profile details.
The original author is confused about the difference between authentication and authorization. They are not the same thing. Authentication proves someone or something is who they say they are within some given context. In the computer world for end users, this is typically a username, which may be known by many, and a password, which should be known only by the individual. There are other methods of authentication that may be used such as key exchanges as implemented in SSL/TLS and ssh. Other systems, such as kerberos, use a weird combination of passwords, shared keys, and tokens to provide authentication.
Authorization is the other piece of the puzzle. Now that you’ve proven you are who you say you are, what are you allowed to do? There are a variety of mechanisms to use for authorization, sometimes it’s simply assuming a person with the right credentials, be it username and password or matching public/private keys, is allowed to do whatever. Other times it’s providing a list of principals allowed to perform some function. I don’t know enough about OAuth to go into its workings, but it is very clear that OAuth is about authorization, not authentication.
I agree with Havard. Changing a pwd does not, in any other context, automatically undo settings or prior actions, why should it do so in the case of OAuth?
This would be like my bank canceling all of my scheduled payments when I change my website password, which I am most definitely not expecting them to do. Facebook doesn’t drop all the applications that I’ve authorized when I change my password, and it would be a nightmare if it did.
Alex: That’s a great analogy — hopefully, that helps others understand why the “expected” behavior that Terence suggests is both counter-intuitive and a poor implementation decision.
I would paraphrase what Terrence said a bit: Most users expect that when you change your password, having known the old password will not grant you access to the resource the new password is controlling access to. OAuth changes the landscape in this case.
My analogy is this – I grant access to a bank account to my copy of Quicken. Then I find my password had been used by someone else to grant access to their copy of Quicken. I then change my password at the bank. Should the bank continue to honor Quicken transactions without requiring me to re-authorize? I think not.
The only difference I see here is in the value of the transaction. Twitter being low value (to many people). The default should be to revoke the outstanding tokens, since many users will not understand the risk or be able to find the interface needed to do it themselves.
Another question that occurred to me — how is this different than cookies allowing access to a site when browsing? I believe it is considered a best practice to invalidate any cookies issued when the password to a site changes. I think that should apply here as well.
Good question. I suspect the twitter user community who was accustomed to the old pre-oauth ways of dealing with authorization may expect that a password change deauthorizes everyone since that’s how it used to work. But twitterers who started post-oauth probably expect that the apps are authorized separately from the password.
Most other similar applications (facebook, desktop OS) authenticate apps separately from the generalized logon, sot he oauth usage twitter employs seems to be trending towards standard.
OTOH, the issue with expecting apps to be booted out of access is just a legacy of the old way of doing things.