Sending GET parameters is causing authentication failure


I’ve got a valid token/token_secret for my app. I’m trying to run “GET account/verify_credentials”. If I send it without any optional parameters then everything works fine, but if I add in “skip_status=true”, suddenly my authentication breaks.

Right now I’m adding that on as a query string to the URL, is that how it’s supposed to be sent?

Do I need to include that parameter when I sign my request even though it’s not actually part of authentication?

Should be simple, I just don’t know what I have to do and I can’t seem to find it in the documentation.


I’m having the same issues actually, what does yer query string params look like when you do the GET request?


Hi Jeff,

Every parameter is meaningful when using OAuth and each needs to be present in the signature base string before signing the request. It’s best to use HTTP header-based auth instead of query-string based OAuth to help make this relationship clearer. [node:204] has some tips that may help as you learn some of the OAuth basics.


I have read all of that, as well as all of “Using OAuth 1.0a”. Also, just to be clear I am currently sending the OAuth string as a header.

I assumed that since the method of “account/verify_credentials” was GET, that any non-oauth parameters would be sent via the query-string. Also, it makes sense to me that every parameter sent should be encoded into the OAuth signature so that the server can check for tampering/data loss, but at the same time it seems strange that non-oauth parameters should be included in the authentication request.

That being said, here is what I tried so far.

  1. Sending the OAuth header alone - this works.
  2. Sending the OAuth header exactly the same as 1. but adding a query string of “skip-status=true” - this fails.
  3. Adding “skip-status=true” as a parameter to the OAuth header (thus it is being computed in the OAuth signature) - this fails.

The only thing I can think to do now is to send the skip-status parameter in the query-string, and also include it in the computation of the OAuth signature. I’d rather know if this would work before I try it though, as it will require that I rewrite/add some additional code.






Looks like you have to send the parameters as GET (or whatever method the api endpoint specifies), but also include them right alongside all the other parameters that are being signed.


Can anyone explain me what this means concretely? In my case the requested URL is in example - so do I have to specify this entire URL as is if I concat my base string for signing? Or do I have to encode this somehow?

The document contains the following sentence:

“The signature base string is composed of the HTTP method being used, followed by an ampersand (”&") and then the URL-encoded base URL being accessed, complete with path (but not query parameters), followed by an ampersand ("&")."

No query parameters!


OK, I got it after a whole day of work and thinking around several corners: the HTTP query parameters have to be separated from the URL. This gives a short URL and a set of parameters. These parameters have then to be added to the sorted set of OAuth parameters. This short (!) URL and the whole set of parameters is then to be signed. Then the HTTP request is to be made again to the entire, long URL.

Guys, is this somewhere documented here? Can I read here an example containing a signed query to a parameterized URL??? I didn’t found a damned single one!


The signing process is documented in depth at and also here:


Cool, I study these documents for more than a week now. But I haven’t seen this page a single time. It could have saved me a lot of wasted time.


That’s because It’s brand new :slight_smile:
We announced it a few days ago through [node:3411,title=“this Blog Post”]


You saved my life with just a simple paragraph, I have been searching for days