Enquiry on Revoking of access token using client id and client credentials

[benjosantony]

I am considering storing the access token and refresh token on my server side or locally on my mobile app.

If I choose to store it on the client side the attach area is reduced as a compromise of the keys will be done on a per user basics, but I will loose other capabilities such as subscription api. 

However storing it in my  backend side will give me the ability to use subscription apis and a lot of other things related to custom triggers on my fitbit watch face specific to a user.

But obviously if my server is compromised I might have to do a lock down (For protecting all user sensitive data). However if the attacked has already managed to get access to the refresh token and access token of all users by the time I detect the issue then users fitbit data might be compromised. Hence I am trying to find out if there is a possibility of doing a similar lock down on the fitbit side easily. 

[Gordon-C]

Hi @benjosantony,

If you're worried about your system being compromised, I'd recommend using the Authorization Code Grant Flow and store the tokens on your server.  The access token is short lived and will expire after 8 hours.   You could use extra security of Authorization Code Grant Flow with PKCE, https://dev.fitbit.com/build/reference/web-api/oauth2/#authorization-code-grant-flow-with-pkce, for added security if your server application doesn't have the security of web services.  You'll want to store the access token and refresh tokens.  You'll need the access token to execute any API call.  The refresh token is used to get a new access token/refresh token pair once the access token has expired. 

I would suggest if your system is compromised, contact us so our security team can get involved to help assess the impact.     

[benjosantony]

Hi Gordon 

Thanks for the reply. 

As I highlighted in my question I am looking at a worst case scenario. As you pointed out for security reasons it is best to use use Authorization grant flow which is what I am planning to use 

But my question was what if my server gets compromised. (I am not planning to make my server easy to hack but regardless of the security measures I put in place there is always a possibility of a malory getting access to the access token and refresh token for atleast a period of time which could be used to in malicious ways, eg : Get a new access token and refresh token making the old one invalid or if the client id/secret is leaked malory could revoke the tokens etc ) 

So basically as far I understand if such a issue is detected it will be best to get in touch with fitibit as soon as possible.

May I enquire how what is your SOP when such issues are highlighted? 

[Gordon-C · Accepted solution]

Hi @benjosantony 

Depending on how your application was compromised, you could look at resetting the client secret and/or revoking the client access tokens.  These can be done in your application settings of the dev.fitbit.com portal.

When you reset your client secret, you will receive a new client secret and will need to modify the client secret in your code for your application to continue querying the APIs.

Revoking the client access tokens allows you to revoke all access tokens issued before a specified date.  The users who access tokens were revoked will need to reauthorize consent.

Both of these things are fairly drastic, but allow you to immediately protect your users, application and the data.  

It's been a long time since such issue has occurred.   When we discover your application has been compromised, we will work with you to determine the size of the impact, what caused the issue, the next steps to address the issue and prevent it from happening again, and how to communicate the problem to our mutual customers.  You can reach out to customer support at https://dev.fitbit.com/build/reference/web-api/help/, and we can take it from there.

Gordon