The Google Health API utilizes a robust and standardized framework for managing
user data access and security. A central component of this modernization is the
transition from legacy Fitbit Authorization (FOT) to Google OAuth 2.0. This
shift allows developers to leverage standard Google authentication libraries,
simplifying implementation while providing users with a familiar and
centralized interface for managing their permissions.

## App Registration

All Google Health API apps must be registered using the [Google Cloud
console](https://console.cloud.google.com/), which serves as a central hub
for managing all of your Google apps.

For instructions on how to register your app, follow the steps at
[Getting Started](https://developers.google.com/health/get-started). Here are the differences you'll
notice when registering your apps.

|---|---|---|
|   | **Fitbit Web API** | **Google Health API** |
| **Public link(s)** | <https://dev.fitbit.com/apps> | <https://console.cloud.google.com> |
| Adding a new app | Press **Register a new app** | 1. Create a Google Cloud Project 2. Enable **Google Health API** |
| **Basic Info** | Fields to complete: - Application Name - Description - Application Website URL - Organization - Organization Website URL - Terms of Service URL - Privacy Policy URL | Fields to complete: - Application name - Support email - Audience (internal or external) - Contact email - Logo icon - Application website URL - Privacy policy URL - Terms of Service URL - Authorized Domain |
| **Application Types** | A developer is required to select: - Server - Client - Personal | - Web application - Android - Chrome Extension - iOS - TVs - Desktop app - Universal Windows platform |
| Client ID | Registered when the application settings are saved | Registered separately |
| Access Type | Read and Write access is controlled at the app level | Read and Write access is controlled at the scope level |
| Additional URLs | - **Redirect URL**: Site where users are redirected to after the authorize the scopes | - **Authorized JavaScript Origins**: HTTP origin that hosts the web application - **Redirect URL**: Site where users are redirected to after the authorize the scopes |

## OAuth Implementation

Google Health API apps only support the
[Google OAuth2 Client libraries](https://developers.google.com/identity/protocols/oauth2#libraries).
Client libraries are available for popular frameworks, which makes
implementing OAuth 2.0 simpler.
**Authentication best practices --- Use system
browsers, not embedded WebViews:** Always launch Google OAuth flows using system browser contexts such as **Chrome Custom Tabs** (Android) or **ASWebAuthenticationSession** (iOS) to support passkeys and Google Identity Services protections. Don't use embedded WebViews, which create security vulnerabilities, block passkeys, and are disallowed by Google OAuth policies. For full details, see [Sign in
with Google best practices](https://developers.google.com/identity/siwg/best-practices).

The differences between the Google OAuth2
libraries and the open source OAuth2 libraries are as follows:

|---|---|---|
|   | **Fitbit Web API** | **Google Health API** |
| **OAuth2 library support** | Open Source | [Google OAuth2 Client libraries](https://developers.google.com/identity/protocols/oauth2#libraries) |
| **Functionality** | Inconsistent across platforms | Consistent across platforms |
| **Authorization URL** | https://www.fitbit.com/oauth2/authorize | https://accounts.google.com/o/oauth2/v2/auth |
| **Token URL** | https://api.fitbit.com/oauth2/token | https://oauth2.googleapis.com/token |
| **Access Token Lifetime** | 8 hours | 1 hour |
| **Access Token Size** | 1024 bytes | 2048 bytes |
| **Refresh Token** | Refresh tokens are generated when using the Authorization Code Grant Flow. Only 1 refresh token can be generated for a user. Tokens never expire and can only be used once. | To generate a refresh token, the authorization string must contain the query parameter "access_type=offline". Multiple refresh tokens can be created for a single user. Refresh tokens can be timed-based. They will expire if they have not been used in 6 months, the user granted time- based access, or the app is in "Testing" mode. See [Refresh token expiration](https://developers.google.com/identity/protocols/oauth2) for more details. |
| **Token Response** | JSON response contains: - access token - access token expiration - scopes - token type - refresh token - user ID | JSON response contains: - access token - access token expiration - scopes - token type - refresh token <br /> To obtain the user id, use the **users.getIdentity** endpoint. |

## User Re-authentication (Mandatory Re-consent)

Fitbit users must re-consent to your new integration, because your app
is using a different OAuth library. It is not possible for access tokens and
refresh tokens to be transferred to the Google Health API and work.

Each user who re-consents counts toward your Google Cloud project's OAuth token
grant rate limit.

Google Cloud enforces a rate limit on OAuth token grants to control how quickly
your app can onboard or re-authenticate users. If you expect to exceed 10,000
user sign-ups or re-authentications within a 24-hour sliding window, request a
higher quota in advance. For more information, see
[OAuth application rate limits](https://support.google.com/cloud/answer/9028764).