Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

OAuth2 does indeed send a secret bearer as an "Authorization: Bearer" header, but OAuth1 does not.

The FitBit stuff I recall seeing other day was OAuth1. It would look like oauth_token=XXX and oauth_consumer_key=YYY, along with oauth_signature=ZZZ. If that's what you're seeing, it's not a bearer token and that data isn't secret. Those values are essentially record locators.

OAuth1 has an undisclosed "consumer secret" (embedded in the app) and "token secret" (acquired at login) that are used to sign the request. So these requests don't leak any usable tokens. If you also see oauth_nonce and oauth_timestamp values, then the signature is also protected from a replay attack.

The response body of the request that originally acquired the token/secret would leak these secrets.

I'm sure there are bearer tokens out there for other services, but if fitbit is using OAuth1, you'd have to snag that original token acquisition to call the api as that user.

Edit - I hope this doesn't come off as argumentative. I just want to point out the good design choices made by the guys that weren't actually compromised by this. OAuth2 is really easy to implement, but it kinda feels like a step backwards security-wise.



"OAuth2 is really easy to implement, but it kinda feels like a step backwards security-wise."

No, no it isn't. There are about three proper ways to implement it. Almost nobody whose site I've come across that uses OAuth2 has it properly implemented.

Token revocation and authentication is hard, folks.


> The FitBit stuff I recall seeing other day was OAuth1.

Fitbit uses oAuth 2

https://dev.fitbit.com/docs/oauth2/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: