Fitbit supports the Authorization Code Grant and Implicit Grant flows as defined in RFC 6749.
The Authorization Code Grant flow is recommended for applications that have a web service. This flow requires server-to-server communication using an application’s client secret.
Applications that do not have a web service should use the Implicit Grant flow.
WARNING – DO NOT embed the Authorization Page
Any attempt to embed the OAuth 2.0 authentication page will result in your application being banned from the Fitbit API.
For security consideration, the OAuth 2.0 authorization page must be presented in a dedicated browser view. Fitbit users can only confirm they are authenticating with the genuine Fitbit.com site if they have they have the tools provided by the browser, such as the URL bar and Transport Layer Security (TLS) certificate information.
For native applications, this means the authorization page must open in the default browser. Native applications can use custom URL schemes as callback URIs to redirect the user back from the browser to the application requesting permission.
iOS applications may use the SFSafariViewController class instead of app switching to Safari. Use of the WKWebView or UIWebView class is prohibited.
Android applications may use Chrome Custom Tabs instead of app switching to the default browser. Use of WebView is prohibited.
For web applications, do not use an iframe. Web applications may use a pop-up window, so long as the URL bar is visible.
Authorization Code Grant Flow