OAuth tutorial: clarification needed

[SunsetRunner]

Hi,

I am about to write a headless program (Spring boot with Springsecurity5) that automatically once a day fetches the data of all devices/users that authorized access by my app .

I registered a Fitbit app, and walked through the "Oauth 20. tutorial page".

My understanding was, that once I got the authorization code from a user, I am set and can use that code indefintely to retrieve an access token and fetch the data.

But apparently, that authorization code expires after the first use.

So, instead I need to do per user

1) with that authorization code retrieve an access code and a refresh code

2) store the refresh code

3) do my request with that new access code

4) after 24hrs request a new access code with that stored refresh code

5)  start at 2) again

Is that correct?

Is at some point a login via the Fitbit login page required? As said above, the program shall run unsupervised on a server somewhere.

Since the access code expires only after one hour, it's difficult to test.

Thanks

[JohnFitbit · Accepted solution]

Hi @SunsetRunner,

Welcome to the forums!

Your steps are correct. The authorization code is only needed during the user consent flow. Upon user consent, Fitbit redirects the user back to your application's redirect URL with an authorization code as a URL parameter. Your application then exchanges the authorization code for an access token and refresh token.

In step 2, please also store the access token along with your refresh token, as it is needed to make a majority of API calls to the user's Fitbit account.

The access token has a default duration of 8 hours. When your access_token expires, your application will use the refresh_token that it received with your access_token, to obtain a new access_token and refresh_token. Once you use the new access_token in an API call, the original refresh_token you received will become invalidated, and the new refresh_token you received will become the new active refresh_token. 

There isn't any reason to store the authorization code as it is only used during the consent process, and will expire after 10 minutes. The login page will only prompt during the user consent flow so that the user can log in to their account and select which scopes to allow access to on the authorization page. If you'd like to force your user to authorize your application every time, you can include the "prompt=login consent" parameter in your authorization URL.

prompt

Specify if you need to force the Fitbit authentication or the OAuth 2.0 authorization page to be displayed. When used, the redirect_uri parameter must be specified. none for default behavior. consent to require consent from the user, even if they have previously authorized your application. login to require the user to sign in, but request consent according to the default behavior. login consent to require the user to sign in and authorize your application. Optional Type: string

I hope this helps. Let me know if I can clear anything else up for you.

[SunsetRunner]

Hi @JohnFitbit,

thanks.

Just one other question regarding this:

The access apparently token contains the id of the user.

So, I can always use the "current user" shortcut in the URLs like

https://api.fitbit.com/1/user/-/profile.json

and get the data of the user the token "belongs" to?

[Gordon-C]

Hi @SunsetRunner 

When executing the Web API endpoints, you can specify the user id shortcut, "-".  When the hyphen is specified, we use the access token to determine which account's data to return.

Gordon