There is a pretty good story behind this. That is, how we found and managed the OAuth protocol security threat identified last week. In many ways, the story is much more important and interesting than the actual technical details of the exploit.
For everyone involved, this was a first-of-a-kind experience: managing a specification security hole (as opposed to a software bug) in an open specification, with an open community, and no clear governance model. Where do you even begin?
But right now, I know you want the technical details.
As an authorization delegation protocol, OAuth must be secure and allow the Service Provider to trust the Consumer and validate the credential provided to gain access. To accomplish that, OAuth defines a method for validating the authenticity of HTTP requests. This method is called Signing Requests and in order to understand it, we must first explore the security features and architecture of the protocol, which will be the focus of this part of the Beginner’s Guide.
In the following part we will explore how all this comes together and translates into the OAuth signature workflow using interactive examples. The examples in this post cannot be viewed in a feed reader.
Public comments about OAuth are a great opportunity to explain the thinking and goals behind the protocol. Rob Sayre asks about the protocol use of redirection in order to get the user to grant access:
“Maybe I’m missing something, but doesn’t this train users to enter their credentials into web pages they’ve been redirected to?”
First, you are correct. Redirection carries with it some risk of training users to follow a pattern of coming to a login screen without explicitly entering a URL in the browser address box. The basic idea behind phishing is getting the user to a page they think is one thing but is really something else. A link in an email message made to look like your bank is actually a fake page asking you to enter your username and password. When you fall for it, it usually redirects you back to the real bank to enter it again (making you think you just mistyped).
Pownce’s API chief Shawn Allen recently opened a Google group to discuss the upcoming Pownce public API trying to capture the same community buy-in the Twitter group is known for. Shawn raised the question of API security and authentication, something I have been thinking about for a couple of months now (building a somewhat similar service). The goal is to try and find the right balance between ease of use for developers, security and privacy. Nouncer requires a solution that will address multiple client needs (desktop application, AJAX script, server-side web script), and will be easy to use in multiple technologies. This message was originally posted to the Pownce API group and has been revised for the Hueniverse blog.