access token from refresh token request is only valid for 8h

[youbs]

Hello!

I was trying to get a token for user valid for a week with this request

https://www.fitbit.com/oauth2/authorize?response_type=token&client_id=238QZ9&redirect_uri=vital%3A%2F%2Fjoinvitalhealth.com&scope=activity%20heartrate%20location%20nutrition%20profile%20settings%20sleep%20social%20weight%20oxygen_saturation%20respiratory_rate%20temperature&expires_in=604800

Once the token is expired we send refresh token request 

curl --location --request POST 'https://api.fitbit.com/oauth2/token' \
--header 'accept: application/json' \
--header 'authorization: Basic <token>' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Cookie: JSESSIONID=D4FFFEB5F8E1C99AFB292892CCF53F01.fitbit1; fct=f5f684ce95f94d5f91941eda886ccdec' \
--data-urlencode 'grant_type=refresh_token' \
--data-urlencode 'refresh_token=<refresh_token>' \
--data-urlencode 'expires_in=31536000'

from the docs it seems we can pass expires_in as argument but even with higher value like 1y the response returns a token which is only valid for 8h

https://dev.fitbit.com/build/reference/web-api/authorization/refresh-token/

the response I got was 

    "access_token": "token",
    "expires_in": 28800,
    "refresh_token": "refresh_token",
    "scope": "weight profile sleep social location heartrate activity nutrition settings",
    "token_type": "Bearer",
    "user_id": "B5SR9R"
}

why the token is only valid for 8h despite of giving expires_in within the request, I know the supported value is 8h only then why even having the option to have this argument? Can you explain how refresh token mechanism works? And if we want a new token for longer validity what can we do?

Thanks

[GordonFitbit · Accepted solution]

Hi @youbs 

You can obtain an access token with a lifetime of 1 week using the implicit grant flow.   This authorization flow is not recommended due to the risks to man-in-the-middle attacks.   Here are the steps to do it

1. Set your application type = client

2. I believe your authorization URL is correct: 

https://www.fitbit.com/oauth2/authorize?response_type=token&client_id=238QZ9&redirect_uri=vital%3A%2F%2Fjoinvitalhealth.com&scope=activity%20heartrate%20location%20nutrition%20profile%20settings%20sleep%20social%20weight%20oxygen_saturation%20respiratory_rate%20temperature&expires_in=604800

3. When the user is redirected, the access token will be provided in the URL.   For example

vital://joinvitalhealth.com#access_token=<access_token>&user_id=<user_id>&scope=nutrition+temperature+settings+location+respiratory_rate+profile+activity+sleep+weight+heartrate+social+oxygen_saturation&token_type=Bearer&expires_in=604800

4. You'll use the access token when querying the endpoints.

Please note, the implicit grant flow does not provide you with a refresh token.   At the end of the 7 days, your application will lose access to the user's data.   Therefore, the user will need complete the authorization flow again for your application to receive an updated access token.

We recommend either the authorization code grant flow or authorization code grant flow with PKCE.  Even though the access token is short-lived, you can maintain access to the user's data by maintaining the access token and refresh token pair.

Gordon