Refresh Token expiration so short.

[vidapura]

I've been looking at various posts here in relation to the Oauth2 and the various tokens.

Such as: https://community.fitbit.com/t5/Web-API-Development/Invalid-or-expired-refresh-tokens/m-p/1057036#M3...

It would appear from reading that thread that the refresh tokens expire in a very short time.

So, my question is.. if the user authorises my app today.. and we make api calls to get data .. thats fine.

But what happens tomorrow when we want to get data again .. the refresh token will have expired.. 

So the user  will have to go through the login process all over again will they?

Thats a bit clunky isn't it?

Is there an alternative?

Thanks

Vida

[GokhanFitbit]

The documentation about the refresh tokens below explains that:

https://dev.fitbit.com/reference/web-api/oauth2/#refreshing-tokens

A refresh token does not expire until it is used. A refresh token can only be used once, as a new refresh token is returned with the new access token.

Are you trying to use the same refresh token multiple times?

[vidapura]

Thank you gokhano ,

I didn't understand that the Refresh token expiration only starts from when they are used.

With that useful nugget of info I was able to better understand the docs and posts related to this.

Thank you.

I'm just trying to figure how a system would work where we have 120 patients participating in a study.

Each of which is given a fitbit to use.

We'd like to have centralised control of the data from the 120 fitbits so clinicians can review the patient activity levels.

So,  we have 120 individual accounts and I'm trying to figure out how we would retrieve all the data from these accounts on a weekly basis.

Ok, so for initial setup, the Admin would have to one-time manually enter credentials to authorise 120 accounts. (not nice, but hey...)

Once the 120 accounts are all authorised I can store the refresh tokens for use in a weeks time.

Thats great. And we can continue to re-authorise and retrieve data every week...

But from what I see in the forums, the refresh tokens could be rendered useless at any time if the FitBit service is re-versioned, restarted or whatever.

Basically they can be revoked after an arbitrary time... could be three months, could be one day.

So, the admin looking after the data for the 120 trial patients could have to slog through 120 authentications all over again.. and no telling when they'd have to do it again.. could be the next day or whatever .. right?

Thats the sticking point really...  

Its such a pity we can't have 120 devices linked to a single account.

Thanks for the time you have taken to reply to me on this.

[DavidSFitbit]

@vidapura since you're utilizing refresh tokens I'm assuming you're going through the Authorization Code Grant Flow. I'd like to clarify a few things:

• Refresh tokens won't ever be revoked unless you breach the terms of service for the API.
• Refresh tokens are invalidated after they're used to obtain a new access token.
• Once an account has gone through the authorization process for your integration, you can continue to refresh an access token indefinitely.

You shouldn't have to re-authorize 120 users unless there was some catastrophic failure on the Fitbit side. I understand that this is for a study, but we've seen integrations let the users authorize the integration themselves.

[MattJDavis]

I'm having the same issue. My refresh token seems to not work after the 8 hours. I can refreshtoken and it works in testing and I have a script that updates the refresh token. The refresh token function works fine for what is seemingly only the period the access token is valid then it stops working. I actually have monitoring on the refreshtoken call showing this discrepancy. 

Just to clarify I am getting the new refresh token and using that each time. 

[MattJDavis]

I'm having the same issue. My refresh token seems to not work after the 8 hours. I can refreshtoken and it works in testing and I have a script that updates the refresh token. The refresh token function works fine for what is seemingly only the period the access token is valid then it stops working. I actually have monitoring on the refreshtoken call showing this discrepancy. 

[vidapura]

@DavidSFitbit Thanks for taking the time to address my query.

I would be using the Authorisation Code Grant Flow unless there is some easier way to gain access to all my users data. From reading the docs thats the only way I thought possible, though I have to admit I am new to the whole OAuth2 thing.. so please forgive me if I've missed something obvious.

(and feel free to educate me if there is an alternative!!)

That said, yes I was under the impression that the refresh tokens would be invalidated, revoked or rendered useless, in other circumstances such as server reboots or code updates or whatever..

We don't want to allow users authorize themselves as we have GDPR regulations (see here: https://www.dataprotection.ie/docs/GDPR/1623.htm) that necessitate anonymisation of data.

So we just want to set up 120 accounts with non-identifiable names like user1234@ourdomain.ie with passwords that we set. (we don't want participants registering fitbits in their own names)

We would then handout the associated fitbit devices to the study participants.

A cross reference table will be maintained for the study duration but will be deleted once the study is over. We'll keep the data after but because its linked to those accounts rather than the study participants real accounts it will be compliant with the data protection regulations.

And then for the next study we would intend to reuse the accounts and fitbits.

So, in reality, the use of Oauth2 for Api authentication/authorisation is more of a hindrance to us. Something we have to work around.

We'd much prefer not to be saddled with it.