implicit grant flow

[hagar_coreg]

hello,

I've been using the implicit grant flow for a while, but two days ago I've noticed that after I click on the oauth 2.0 I no longer have the option to choose implict grant flow, and the default is the authorization grant flow. Does someone know why this happened or how to change it?

[Gordon-C]

Hi @hagar_coreg 

Are you using a tool that allows you to select the authorization flow?   The APIs support implicit grant flow, see Other Supported Authorization Flows.  Since the implicit grant flow is not very secure against man-in-the-middle attacks, we do not highlight this authorization flow in our documentation.

Gordon

[hagar_coreg]

thank you for your quick response:)

what is a tool that can allow this? for about a year I had the option to choose implicit grant flow each time with no problem. I chose this authorization because I need tokens that expire after a year and not 8 hours. can you please explain how to allow this option again?

thank you, 

Hagar

[hagar_coreg]

this is what i used to get:

and this is what i get now:

[Gordon-C]

Thank you for sending the pictures.   I see you've been using the OAuth 2.0 tutorial.   The OAuth 2.0 tutorial is provided to demonstrate how to implement the authorization flow.   It's not intended to be used in a production use case.

I can help you find another way to generate the tokens for more than 8 hours.   Can you describe your use case for me and specifically how you've been using the OAuth 2.0 tutorial for your scenario?  This will help me provide you with some options.

[hagar_coreg]

thank you very much! 

I have been using fitbit watches for a university research project. Each time a watch is used for about a month, during which I receive a report (pulse) to an external app, in order to ensure the watch is being worn and is working. I generate the token at the beginning of each month because I use it to get the report. After the month is over, I insert the token to an r program that transfers the data that was collected to my computer.  

normally, I would open a fitbit account and generate a token this way (I've been doing so for about a year with no problem): 

I appreciate your help,

Hagar

[hagar_coreg]

to be clear- each time I used to open an account, register an app, and use the OAuth 2.0 to generate a token that I used

[hagar_coreg]

@Gordon-C 

[Gordon-C]

Hi @hagar_coreg 

So, I see what you're trying to do; you create a Fitbit user for your study, then registering an application specifically for that user to download their data.  This is not the way the APIs were intended to be used.   Let me explain the best way to query user's data, and then I'll show you how to continue using your method today.

The best way to query your participants data is to create a single application/client ID and have all of the users consent to share their data with that single application.   We recommend using the Authorization Code Grant Flow [with PKCE] because it is more secure, but you could use implicit grant flow too.   Your application will generate a single authorization URL which you will provide to all of your participants.   When the user clicks on the authorization URL, they will be required to log into their account and consent to share their data.   After consent, your application will be provided an access token and refresh token, and both need to be stored.   The access token is short lived, however, the refresh token does not expire.   So, when you're ready to fetch the user's data after 30 days, use the refresh token to obtain a new access token and query your report with the new access token.

I see you are somewhat familiar with R.  Good news we have an example in our documentation.   See https://dev.fitbit.com/build/reference/web-api/developer-guide/libraries-and-sample-code/.   

Now for your use case.   The OAuth2 Tutorial is generating the authorization string for you to get the access token.   The syntax of the authorization string is the same, so all you'll need to do is change the values for each user.   For example, the authorization string to query activity data would be

https://www.fitbit.com/oauth2/authorize?response_type=token

&client_id=<client ID>

&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback

&expires_in=31536000

&scope=activity

You'll want to supply the value for the client ID associated with each user, change the redirect_uri value to match the application configuration, and add the additional scopes for that data points you need to query.

I know how particular IRBs can be about protecting user's data, so I highly recommend switching to the authorization code grant flow.   If you would like to have a detailed conversation about this for your future studies, please let me know.   I can arrange a meeting with you.

Gordon

[hagar_coreg]

thank you @Gordon-C 🙂

I think what you are describing is something we tried to do after our original plan didn't work but was unsuccessful, maybe you could pinpoint what went wrong

we used the tutorial as instructed until step 4, in which we changed the "expires_in".

I didn't see any actual change in the token, but the parsed response changed to 31536000 seconds. Unfortunately the token still expired, is there something else I should have done?

Maybe it only works if I submit request in the "access user data"? is this something that only has to be done once?

thanks again,

Hagar

[Gordon-C]

Within your authorize URL, set response_type=token.   This forces the implicit grant flow.

[hagar_coreg]

looks like it's working, thanks for all of your help!

[Nathile_Wen]

How did you change the expiration date after changing the response_type to "token"? For my test, it says it expires in 86400 seconds, which is not what I wanted. 

[Gordon-C]

For the implicit grant flow, the expiration date is configured in the authorization URL.   See Authorize.