OAuth and Signed APIs

[alexandrag2254]

Hi All! 

if I have concerns disclosing my private/secret api keys on the web and/or to a third party, is there a way to incorporate signed API (signed requests) with OAuth protocol? Ideally I want to prevent anyone from using my api request information to make other calls that I have not authorized. I've read up that other api's use protocols that sign the url with a secret key making a request authorized but does not contain my secret key, but also can be used by anybody for just this one specific request. Is this something that Fitbit also uses and/or is there a way I can incorporate this to my web app?

I'd really appreciate any resource/code recommendations and/or advice. Thanks again for helping me sort this out! 

[JeremiahFitbit]

---

@alexandrag2254 wrote:

if I have concerns disclosing my private/secret api keys on the web and/or to a third party

---

You *should* have concerns about this. 🙂

Can you please elaborate on your app? Why would a third-party be handling your application's client secret? You should never distribute your client secret to any web server you do not control.

---

@alexandrag2254 wrote:

Ideally I want to prevent anyone from using my api request information to make other calls that I have not authorized.

---

If a third-party has your application's client secret, it could impersonate you. Request signing would not protect you from this in that scenario.

---

@alexandrag2254 wrote:

I've read up that other api's use protocols that sign the url with a secret key making a request authorized but does not contain my secret key, but also can be used by anybody for just this one specific request. Is this something that Fitbit also uses and/or is there a way I can incorporate this to my web app?

---

OAuth 1.0a uses request signing, however, OAuth 2.0 does not use it. Request signing was necessary with OAuth 1.0a because HTTPS was not required. OAuth 2.0 requires HTTPS.

In order for an evil app to make "calls that [you] have not authorized", the evil app would need to obtain a user access token from your application. If an evil app is capable of obtaining an access token, it is likely also capable of obtaining your client secret, so signing the request would not be beneficial.

[jmitchell38488]

"Evil app" can deduce your information through man-in-the-middle attacks, which is where signing comes in, especially if the attacker isn't able to determine your private keys, or hashing keys from the message. Since HTTPS is less secure than it once was (hacked in 2011) and some keys/certificates provide next to no security whatsoever, message signing may be something that imlementers of oauth2 incorporate down the track. It's another level of complexity but it's still security in depth.

Agree, that if your keys are compromised there isn't anything you can do about it except regenerate another set of keys and figure out how you were hacked. But for MITM attacks, message signing is an effective method of threat mitigation.

I've used HMAC with sufficiently large keys and request timeout limits (built into the hash as well as the request header) in the past without any issues on APIs I've built, but more can certainly be done to improve security.

[JeremiahFitbit]

While there have been minor issues, HTTPS is strong enough to protect the world's economy.

If your HTTPS is compromised via a man-in-the-middle attack, you have significantly greater concerns than request signing. You can do a reverse DNS lookup on each request or implement your own HPKP if you're that concerned.

[alexandrag2254]

Thanks @JeremiahFitbit for the response! Glad I'm on the right track with my concerns. 

Potential project in a nutshell: web app that will keep track of a contract/agreement between two users based on future activity results (from one of their Fitbit data) for motivation purposes. User would grant access to their data via secure login process then at a later date the web app would request the necessary data via Fitbit web api to inform the contract/agreement. 

So, I'd like to assure users that the data I'm retrieving from Fitbit is untampered with as well as the "man in the middle" attack. (I'm starting to think these 2 issues need to be addressed separately?). 

Given Fitbit protocol I will be using OAuth2 however, I am considering using an additional security protocol. Based on your response, this is unnecessary? Perhaps because OAuth2 uses HTTPS? As @jmitchell38488 mentioned, would HMAC be a viable security addition? 

[jmitchell38488]

It might not be necessary as long as you're validating the SSL hostname and the certificate. But it is still possible.

A healthy debate on the matter is found on Stack Overflow:

http://stackoverflow.com/questions/14907581/ssl-and-man-in-the-middle-misunderstanding

[JeremiahFitbit · Accepted solution]

@alexandrag2254: Your concerns should be adequately addressed by HTTPS. HTTPS provides secure communication of your request and the response from the Fitbit Web API. (I encourage you to learn about man-in-the-middle attacks on your own and make a decision about how much of a concern it should be for you, as well as what steps you might take to mitigate them. This is beyond the scope of support Fitbit will provide.)

OAuth 1.0a's HMAC signing is only used to validate the request. A signature is not returned on the response with OAuth 1.0a. Fitbit has no current plans to implement request or response signing with OAuth 2.0 requests.