I maintain an implementation of OAuth. Whilst checking existing code and implementing my own version I wondered how some implementations will differ.

OAuth uses RFC3986 for the encoding of URI parameters. Another often used encoding scheme is RFC1738 or RFC2396 (updated in RFC2732).

The differences? Quite a bit.

The unreserved characters in RFC3986 are:

unreserved = ALPHA, DIGIT, '-', '.', '_', '~'

And in RFC17138:

unreserved     = alpha | digit | safe | extra
safe           = "$" | "-" | "_" | "." | "+"
extra          = "!" | "*" | "'" | "(" | ")" | ","

And in RFC2396/2732

"A" .. "Z", "a" .. "z", "0" .. "9",
"-", "_", ".", "!", "~", "*", "'", "(", ")"

What do some programming languages use?

PHP

PHP has two options. Use urlencode or rawurlencode. The difference between the two is the escaping of the “+” character.

rawurlencode claim to fame is to be compatible with RFC1738. In fact it is not. It encodes all characters as in RFC3986, and then also the “~”. So rawurlencode comes close. It escapes everything, except:

A-Za-z0-9\-_.

So the only difference here is the “~” character. The correct funtion will be:

function oauth_urlencode ( $s )
{
    return str_replace('%7E', '~', rawurlencode($s);
}

Perl

CPAN implements URI:Escape. This one uses RFC2396/2732 as the basis for its character encoding. The default for this function is to escape everything except:

A-Za-z0-9\-_.!~*'()

Javascript

Yet another encoding method. Most javascript programmers will use the function escape. This one encoded everything except:

A-Za-z0-9\-_.+*/@

Addition from John Kristian: when you want to encode with Javascript you can take a look atOAuth.percentEncode in oauth.googlecode.com/svn/code/javascript/oauth.js

It is a mess, what to do?

I assume that programmers are lazy and will re-use their good old trusty encoding functions. They should, it is how we train programmers. This will give some interesting problems with OAuth though, as OAuth insists on encoding and sometimes double encoding parameters. And uses those encoded values to calculate the signature of a message.

This insistance on using a very specific implementation of encoding is, in my opinion, the Achilles heel of OAuth.

When checking the signature we have basically two options:

1. Not decode whatever comes in before recalculating the signature. In that way we won’t make any false assumptions about parameters being encoded one way or the other.
2. Recode all incoming parameter values and names, in that way we make sure that we use the correct encoding (according to the spec) for our signature calculation.

However, we must assume that the encoding used in calculating the signature base string and the key from the consumer secret and the token secret is correct according to RFC3986.

Conclusion

We, as a community using OAuth, need to create test sets that will test all edge cases, otherwise we are in for a rough ride. And, to help other programmers, there is an immediate need for correct implementations of the RFC3986 parameter encoding.

Update

The OAuth community has a nice set of testcases online at wiki.oauth.net/TestCases Let’s all use them and make sure that our implementations are correct!

We are not the only ones interested in integrating our content. So far, we’ve started looking at various possibilities- for users and servers signing on to (federated) social networks, for publishing, aggregating, exchanging and subscription to content, and for better ways to describe content and meta-content on the social networks.

Authenticating People: OpenID

To avoid having to create a separate login and password for each social network, we have been integrating the decentralized log-in system provided by OpenID for user authentication.

Servers Communicating With Other Servers: OAuth

Once we have users signed into one social network, we want to allow them to move their data from one network to another. For this we are looking at the open protocol OAuth, which will standardize server to server communication, i.e. the passing of authentication tokens through APIs. This will help make our server-side communication more robust and streamlined.

Representing Information: Atom + RDF

After authenticating, but before we can move content from one place to another, we also need a way to define our content. We’re starting to use RDF as a standard formatting method for our content. We see users and their contacts as another form of content, and are using FOAF to describe their networks. Other forms of content, such as events or projects, allow other standard formatting techniques permissible in RDF- such as DOAF, SOAF and MicroFormats.

Finding Information In The Network: OpenSearch

Since our implementation of RDF will be done in XML, it could be pretty easy to search through the various pages’ content and meta-content. To do this, we’re looking into OpenSearch, which should standardize the presentation of information as well as allow auto-discovery, for instance of things like OpenIDs. We’re still looking into ways to keep our website scalable while using OpenSearch.

Staying Up To Date With Changes: XMPP Publish & Subscribe

Once we have our content properly labeled, we can use standards like Atom1.0 to exchange parts of our content. Specifically, we can use Atom to format newsfeeds and other time-sensitive content, and then use XMPP to announce it. By using XMPP instead of HTTP, we can have persistant connections which will allow the networks to propagate changes as fast as possible.