Obtaining Consent

目录 性能, 数据库-Database

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.

Note: Never put your client secret in distributed code, such as apps downloaded through an app store or client-side JavaScript.

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

暂无评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注