Authorization Process is Confusing

[iPh33r]

I'm now at the point where I'm registering my Fitbit Sense watchface app. There is no explicit step-by-step instructions to guarantee a successful experience for someone who's just learning about apps and doesn't have a website to download the app from, nor a redirect URL to go back to. Which Fitbit doesn't like. Even if I use "https://localhost:8080/"

I've tried using the OAuth 2.0 Tutorial Page but I barely even understand the whole tokens thing so I'm flying VERY blind here. I've tried reading up on the documentations and the APIs and it's all still going way over my head. 

I keep getting this after logging in: 

The app you're trying to connect did not provide valid information to Fitbit. Please report this issue to them.

Developer information: invalid_request - invalid_redirect_uri

Can anyone give me detailed step-by-step instructions so I can get past the whole authorization process and continue to learn more about coding?

[iPh33r]

I tried looking up if there's any guides on youtube and apparently I need to use Postman? Can anyone explain?

[Gordon-C]

Hi @iPh33r 

I'm sorry you're having trouble getting started with the your watchface application.   Let me see if I can help.   Where are you in the application development process with your watchface application?   It sounds like you might be mixing up the Device SDK and Web API functionality.

Gordon

[iPh33r]

Thank you for getting back to me! Since then I've learned two things that solved this problem:

• OAuth 2.0 Application Type: Server
  • I read in multiple places that to pull data from your own profile database it had to be either Client or Personal. This was confusing, but setting it to Server fixed it apparently.
• Callback URL: https://app-settings.fitbitdevelopercontent.com/simple-redirect.html
  • All other examples I've seen used "https://localhost" and Fitbit REALLY doesn't like that.

[Gordon-C · Accepted solution]

Hi @iPh33r 

Thank you for clarifying where you had trouble.   Let me explain what you found and the reasoning behind it.   Keep in mind, Fitbit should not recommend those settings, except for 1 (see below).   If you found that information in our documentation, please let me know so I can clear up future confusion.

1. Application Type really determines the type of authorization flow you plan to use.   "server" uses the authorization code grant flow [with PKCE] while "client" uses the implicit grant flow.   People may recommend "client" because you'll receive a long lasting access token compared to "server" which causes less work by the application.   However, implicit grant flow is less secure.  For querying your own data, this might not be an issue for most people.   "personal" application type can support either grant flow and is designed to be used for querying your own data.   The main benefit the "personal" application type provides is access to your own intraday data.  When using "server" or "client" application types, you'll need to request access to the intraday data set.   To simplify things, when application type is "server", the authorize endpoint's "response_type=code" and when application type is "client", the authorize endpoint's "response_type=token".  When application type is "personal", the authorize endpoint's response_type can be either.

2. During redirect, the user will be sent to a place in your application code where the authorization code needs to be retrieved from the URL and exchanged for the access token and refresh token.  "https://localhost" can be used during redirection if that location has the ability to process the redirection URL we generate.   If not, then you'll need to manually do this.  When redirection occurs, you'll probably see a blank page.  If you look at the URL, you should see the authorization code.   I have sample code that uses localhost for redirection just so I can see the authorization code being generated.   For production systems, it's best to use an actual location in your code that can automatically retrieve and process the authorization code.

I hope that helps.

Gordon

[SkinnyMinnie_68]

Thank you because my Fit bit is not charging and I can't Sync. I have not
officially used since 2016 on a regular basis. What do I need to do?

[Gordon-C]

Hi @SkinnyMinnie_68 

Would you please tell me what type of Fitbit device you have so I can move your post to the correct forum?

Thanks!

Gordon

[ac_devel]

hi Gordon! I am in this process too. I used to have access tokens that should last a year but recent changes caused the tokens to expire. 
Most of the guides I read all use cherrypy to retrieve access/refresh token but I need to run the code on a remote server which cannot open the url in a web browser. Can you give an alternative for this? 
I will be using a personal app but I just can't figure a way to get the access token without having to open a web browser

[Gordon-C]

Hi @ac_devel 

You don't need to authorize on the machine where the cherrypy code is running.   Instead, open the authorization URL on a machine or device that does support a web browser.   This is a requirement to load the web form for consent.  Configure the redirect back to your machine where the cherrypy code runs which doesn't support the web browser.   I believe this will work for your use case.

Gordon

[ac_devel]

if you are wondering why I voted your solution is because I am back at this because there have been changes in the auth pipeline that I used to use. 
Before I would follow the authorization tutorial when creating the app and now I cannot use it anymore to generate the firs code and get the refresh token.