Started getting error 99 when requesting auth token (SOLVED)


#1

Code that has been working for years suddenly stopped working.

Getting error 99 when requesting token. I have tried resetting the consumer keys and re-encoding base64.

I have tried with both my clients twitter account and my own. same result.

Here is the curl command I’m using to test with.

curl --request ‘POST’ ‘https://api.twitter.com/oauth2/token’ --header ‘Authorization: Basic BASE64TOKENREDACTED’ --header ‘Content-Type: application/x-www-form-urlencoded;charset=UTF-8’ --data “grant_type=client_credentials” --verbose

Here is the response minus the auth key

* Hostname was NOT found in DNS cache
*   Trying 104.244.42.130...
* Connected to api.twitter.com (104.244.42.130) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
* 	 subject: C=US; ST=California; L=San Francisco; O=Twitter, Inc.; OU=Twitter Security; CN=api.twitter.com
* 	 start date: 2016-06-29 00:00:00 GMT
* 	 expire date: 2019-09-19 12:00:00 GMT
* 	 subjectAltName: api.twitter.com matched
* 	 issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* 	 SSL certificate verify ok.
> POST /oauth2/token HTTP/1.1
> User-Agent: curl/7.35.0
> Host: api.twitter.com
> Accept: */*
> Authorization: Basic REDACTED
> Content-Type: application/x-www-form-urlencoded;charset=UTF-8
> Content-Length: 29
> 
* upload completely sent off: 29 out of 29 bytes
< HTTP/1.1 403 Forbidden
< cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
< content-disposition: attachment; filename=json.json
< content-length: 105
< content-type: application/json;charset=utf-8
< date: Tue, 20 Jun 2017 14:03:55 GMT
< expires: Tue, 31 Mar 1981 05:00:00 GMT
< last-modified: Tue, 20 Jun 2017 14:03:55 GMT
< ml: A
< pragma: no-cache
* Server tsa_b is not blacklisted
< server: tsa_b
< set-cookie: guest_id=v1%3A149796743591513829; Domain=.twitter.com; Path=/; Expires=Thu, 20-Jun-2019 14:03:55 UTC
< status: 403 Forbidden
< strict-transport-security: max-age=631138519
< x-connection-hash: 3706ca00297b9cf490e60923291b72d4
< x-content-type-options: nosniff
< x-frame-options: DENY
< x-response-time: 9
< x-transaction: 008a4ed900e99044
< x-tsa-request-body-time: 1
< x-twitter-response-tags: BouncerCompliant
< x-ua-compatible: IE=edge,chrome=1
< x-xss-protection: 1; mode=block
< 
* Connection #0 to host api.twitter.com left intact
{"errors":[{"code":99,"message":"Unable to verify your credentials","label":"authenticity_token_error"}]}

I am at a loss as to what the problem could be, the code has not changed and has been working for years.

Any Ideas would be appreciated.


#2

That’s really odd - I’m unable to reproduce this myself. I’ve tested using an app of my own and a similar curl request, as well as this simple PHP example, and there don’t appear to be any issues on this side. I did trigger that error when I inadvertently miscalculated the Base64 encoded version of the consumer key:consumer secret pair a couple of times.

Is there any chance you’ve had any clock drift?


#3

This sample works for me right now.


#4

Hi Andy,

Used the example you provided and it worked for me too.

Was using an online base_64 encoder to generate the token and it seems that it produces vastly different results to the PHP base64_encode. When I plugged in the output of the php base64 encode everything came back to life.

Thanks for pointing me in the right direction.

Cheers,
Mark.


#5