Is there a way to trace or simulate OAuth signature creation

🛠️ Open Technologies
,
1

Is there any way to see the OAuth 1.0 signature string that Postman generates BEFORE it is encrypted? My calls work in Postman just fine but when I try to replicate them in a custom script language I never manage to get the same signature that Postman does. As I’ve googled I see this is a fairly common question for people starting to work with OAuth 1.0. The most common response is “you forgot to alphabetize your parameters” or “a character needs to be urlencoded” but I’ve been staring at my unencoded string for days and don’t see a mistake.

My request URL has a couple querystring parameters, but I am using a POST and according to the documentation I don’t need to include any parameters besides the one required unless I am posting form data and not using the form data content type. So the data portion of the sig consists of just the required pieces of info: oauth_consumer_key, oauth_nonce, oauth_signature_method, oauth_timestamp, oauth_token and oauth_version. Easy to alphabetize, as I’ve read and re-read the standard my string shouldn’t have anything else. indeed when I change the realm or the querystring params or the body of post it doesn’t affect the sig that Postman generates so I think I am correct that none of those pieces of info are used.

the full signature before encryption is in this form:
{method.upper}&{url(minus the querystring).urlencode()}&{datastring.urlencode()}

I have a correction function for capitalization of the urlencoding - the OAuth standard says that %3A is correct and %3a is bad, etc. I saw a post on stackoverflow or somewhere that said his encoding method added a hard return to the end of the string, so I added a trim() but that had no effect and I can conclude that isn’t affecting me.

After after the hash I do some small corrections: the trim() I mentioned above, re-URL encoding to fix any -,+, _ and / created by the hash and add a %3D to the end, but those are easy to see and my string is obviously wrong before it gets to that point.

the encoding uses a standard function, so I can’t mess that up. I call it like in a super obvious way. Any issue there?
oauthSig = proxy.EncodeHS256("{sigString}","{consumer_Secret}&{token_secret}")

For some basic test values I end up with this signature string:
POST&https%3A%2F%2FmyURL.com%2Fsubdirectory&oauth_consumer_key%3D555588884444777733336666%26oauth_nonce%3D10E7ZKnuxDf%26oauth_signature_method%3DHMAC-SHA256%26oauth_timestamp%3D1687965335%26oauth_token%3D111166662222777733338888%26oauth_version%3D1.0

using consumer secret 1 and token secret 2 I get this in Postman:
oauth_signature="lv%2BbohpHYqR23LIs4XqFjyA3wtwxayZltoiYT6ss0ms%3D"
but in my script I get:
OAUTHSIG="nyEyepA7lXiaR0HRZPMDQHTPdJEZMyMy7uEpEAIjFyw%3D"

A few months ago I ran into an issue that the code window in Postman didn’t take into account the pre-request script so I know the the code window didn’t truly reflect what postman was sending. But I’m not using a pre-request script this time and the generated sig updates immediately when I expect it to and not when I don’t. What are the chances that the sig in the Postman code window is actually wrong? I know the request works, but maybe what is shown in the code window isn’t the actual string that Postman would send. Should I not trust that?

2

It turns out that I had two major incorrect assumptions. I now have working code.

1- the code presented in the code window is generated independently and does not necessarily match the code sent by Postman. I wasted more than a day trying to get my generated signature to match the signature in the code window.

2- My second paragraph where I said the params in my URL should not be part of the sig for POSTs was incorrect. My content type was JSON and I used the appropriate content-type flag. The parameters added to the end of the URL should count as form data and since I am not using “multipart/form-data” as the content type, I fall into that exception where the parameters get used like a GET.

The following resources were very helpful: