OAUTH Parameter Encoding

Question

When implementing OAUTH, I have the following problem. When creating the signature base, should encoded parameters be encoded again or should encoded parameters be left out of the encoding when normalizing parameters?

Answer 1

It seems you need to apply double encoding when I read the documentation:

For example, the HTTP request:

   POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
   Host: example.com
   Content-Type: application/x-www-form-urlencoded
   Authorization: OAuth realm="Example",
                  oauth_consumer_key="9djdj82h48djs9d2",
                  oauth_token="kkk9d7dh3k39sjv7",
                  oauth_signature_method="HMAC-SHA1",
                  oauth_timestamp="137131201",
                  oauth_nonce="7d8f3e4a",
                  oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"

   c2&a3=2+q

contains the following (fully decoded) parameters used in the signature base sting:

           +------------------------+------------------+
           |          Name          |       Value      |
           +------------------------+------------------+
           |           b5           |       =%3D       |
           |           a3           |         a        |
           |           c@           |                  |
           |           a2           |        r b       |
           |   oauth_consumer_key   | 9djdj82h48djs9d2 |
           |       oauth_token      | kkk9d7dh3k39sjv7 |
           | oauth_signature_method |     HMAC-SHA1    |
           |     oauth_timestamp    |     137131201    |
           |       oauth_nonce      |     7d8f3e4a     |
           |           c2           |                  |
           |           a3           |        2 q       |
           +------------------------+------------------+

Note that the value of "b5" is "=%3D" and not "==". Both "c@" and "c2" have empty values. While the encoding rules specified in this specification for the purpose of constructing the signature base string exclude the use of a "+" character (ASCII code 43) to represent an encoded space character (ASCII code 32), this practice is widely used in "application/x-www-form-urlencoded" encoded values, and MUST be properly decoded, as demonstrated by one of the "a3" parameter instances (the "a3" parameter is used twice in this request).

Answer 2

Per the spec: https://www.rfc-editor.org/rfc/rfc5849

Each level of parameter is encoded.

So each OAuth (not the signature, which is being created) and user parameter is encoded.

Then these (except for realm) are joined into a sorted parameter list.

That string is URL Encoded and joined with a URL encoded Method and URL Encoded Base URL.

That's the base string, and that's 2 levels of encoding prior to being hashed.