Unexplained 403 Responses from Token Refresh

[LifeOmic-Dev]

I currently have an application that performs an hourly ingestion of Fitbit data and refreshes tokens at the start.  There is some functionality present in this to detect when a user has revoked access to the application upon token refreshes failing.

On 12/31 a little after12:00 UTC, I noticed that one hourly ingested resulted in nearly every request to "/oauth/token" resulted in 403 responses.  Looking at the documentation for token refresh, this does not seem to be a standard error case.  The app was not adjusted that day and this particular type of error has not been noticed at any other time.

The Fitbit status page does not show an error having occurred on this date.  Can anyone explain why all of my requests would have experienced this error?

[Gordon-C]

Hi @LifeOmic-Dev 

I checked one of your applications and I'm not seeing 403 errors on the /oauth2/token endpoints.   I do see 403 errors on the Get Devices and Get Profile endpoints.   I'm not sure if it's related, but I see all of your endpoints using version 1.2; for example, GET http://api.fitbit.com/1.2/user/-/devices.json.   This is incorrect.   Only the Sleep endpoints have been upgraded to version 1.2.   All other endpoints are using version 1, and introspect is at version 1.1.

Except for Sleep, please change the version of the endpoints back to 1 and retest.   

See documentation: https://dev.fitbit.com/build/reference/web-api/

[LifeOmic-Dev]

Hi @Gordon-C,

Yes, we are using 1.2 for the API endpoints.  I don't recall seeing errors come back from the endpoints you mentioned with that versioning, but that is good to know that the version does differ across endpoints.  

We use AWS to host our services.  I have revisited the offending X-Ray trace and below is one instance of what I had seen.  Also like you had mentioned, I have seen other 403 occur when requesting profile or devices for users who did not grant that permission.

{
  "id": "9a1ef104ea616830",
  "name": "api.fitbit.com",
  "start_time": 1577793612.475,
  "end_time": 1577793612.517,
  "error": true,
  "http": {
    "request": {
      "url": "https://api.fitbit.com/oauth2/token",
      "method": "POST"
    },
    "response": {
      "status": 403,
      "content_length": 0
    }
  },
  "namespace": "remote"
}

[Gordon-C]

Hi @LifeOmic-Dev 

Receiving a 403 when trying to request a user's profile and device data when they haven't consented to share it should be correct.  Please see the Troubleshooting Guide.   

Are you still receiving the 403 error when trying to refresh the access token for this user?   If so, please private message me the Fitbit user's user id and the complete syntax of the endpoint including the headers.

[LifeOmic-Dev]

Correct, I have the 403s for all non-OAuth endpoints covered to expect such denial of access.

Our OAuth token refresh workflow has not changed in months.  Apart from the incident I mentioned, I have not seen an influx of 403 responses during token refresh.  I can't provide a particular user for you since this happened to over 500 users.  The time listed on that X-Ray log excerpt will provide a rough estimate as to when this happened.

 Ignoring the ${..} variable substitutions below, this is the exact POST request I'm sending:

Method	POST
URL	https://api.fitbit.com/oauth2/token
Headers	'Authorization': `Basic ${base64 encoded id:secret}`, 'Content-Type': 'application/x-www-form-urlencoded'
Body	grant_type=refresh_token&refresh_token=${refresh token}