OAuth: sorting parameters when signing

jfriedl · 2012-01-11T12:28:00.000Z

The page on creating a signature (https://dev.twitter.com/docs/auth/creating-signature) doesn’t mention anything about sorting the parameters, but it probably should…

kurrik · 2012-01-11T19:26:41.000Z

Wow, what an oversight. I’ve made the change, thanks for pointing this out!

jfriedl · 2012-01-11T21:50:03.000Z

I hadn’t looked at your OAuth docs in a couple of years, and was suitably impressed when I came back yesterday… I’d never seen such clear OAuth docs, so thank you.

But there’s a slight boo-boo in the update … you must sort on the percent-encoded copy of the key, not the pre-encoded version:

http://tools.ietf.org/html/rfc5849#section-3.4.1.3.2

And considering that the secondary sort is the value, it’s probably easiest to build up the list of “encodedkey=encodedvalue” pairs, then sort that, then concatenate with “&”…

jfriedl · 2012-01-11T22:25:16.000Z

Another issue is that the two items that go into creating the signing key must be percent-encoded before being concatenated by ‘&’:

 http://tools.ietf.org/html/rfc5849#section-3.4.2

This may be a non-issue for Twitter if your secrets are always alphanumeric, but it’s probably better to be safe than sorry…

kurrik · 2012-01-12T18:57:01.000Z

Thanks again. I’ve addressed both issues:

Sorting on percent-encoded key is mentioned. I refrained from describing your algorithm, though, as sorting on the intermediate string will take the “=” character into account for the sort, which I believe is incorrect (and may lead to some subtle error in a few cases). I’ve put in a note about secondary sort, but that shouldn’t apply to Twitter API requests. Hopefully you’ll find the updated text to be suitable.

Percent encoding the consumer key and secret are now mentioned as well. I do believe that this won’t be an issue, but it’s best to be rigorous here.

Thanks for catching these!

jfriedl · 2012-01-12T22:53:44.000Z

If I can impose, could I ask you to expand on how sorting on the ‘=’-coupled pair could lead to problems? It seems that the ‘=’ won’t become relevant to the sort except when the keys are identical, and then won’t impact the sort because the ‘=’ is the same across all pairs that get that far, leaving the encoded value left to differentiate for the sort.

I ask not because I think the presentation in your docs is lacking, but if there’s an issue here, I’m worried for myself for not seeing it(!)

jfriedl · 2012-01-12T23:31:52.000Z

Belay that last request… a tiny bit of thought on my part comes to the realization that ‘=’ becomes relevant not only when the keys are identical, but when one key is a prefix for another, and in that case the ‘=’ could subvert the shorter key’s earlier placement: the way I was doing it would sort the keys “test” and “test1” incorrectly, so thanks for making me rethink this!

kurrik · 2012-01-13T00:11:32.000Z

Yep, that’s what I was thinking