8

So if a user authenticates to the site using a username/pw, they get a session token which is passed back to the server to validate who they are.

However when you use an API like twitter or 4square, you have both a token and a secret. What extra value is there in adding an api secret to the api token especially if you are going to send both of them in the URL.

The only plausible thing I've been able come up with is it makes the numberspace REALLY big, but a 128bit token already has a HUGE numberspace, so that makes be believe that is probably no the reason for the extra value.

So why have 2 values, both of which are transmitted in each request?

  • Perhaps a duplicate of this – puzzlepalace Feb 9 '16 at 22:25
  • One might be session cookie and the other an a CSFR token. Where the session token is for all pages and the CSFR token is a nonce to protect bogus POST requests. – whatever489 Feb 10 '16 at 0:26
4

This statement is incorrect:

both of which are transmitted in each request

The secret is never sent. Instead, each request is signed with the secret. From the Twitter API documentation, the data that is sent is in the Authorization header is:

OAuth oauth_consumer_key="xvz1evFS4wEEPTGEFPHBog", 
    oauth_nonce="kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg", 
    oauth_signature="tnnArxj06cWHq44gCs1OSKk%2FjLY%3D", 
    oauth_signature_method="HMAC-SHA1", 
    oauth_timestamp="1318622958", 
    oauth_token="370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb", 
    oauth_version="1.0"

The documentation continues to say:

The oauth_signature parameter contains a value which is generated by running all of the other request parameters and two secret values through a signing algorithm. The purpose of the signature is so that Twitter can verify that the request has not been modified in transit, verify the application sending the request, and verify that the application has authorization to interact with the user’s account.

As the documentation states, the signing is used for authentication and to ensure that the request isn't tampered with after it has been signed.

Another advantage of this authentication strategy is that it interacts well with stateless services.

  • Yup. Facebook also uses shared secrets to allow the developers to verify that requests from the Facebook API actually came from Facebook. For example, if a user purchases something in your Facebook application, Facebook will validate the purchase and send a request to your application that instructs you to award the purchased items to the user. That request is signed using the shared secret, so you can be sure that it could only have come from Facebook and not from some other source. – MusikPolice Feb 11 '16 at 15:52
  • Actually the 4square API does require transmission of both the CLIENT_SECRET and CLIENT_ID for what they term "userless access" developer.foursquare.com/overview/auth.html – boatcoder Feb 17 '16 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.