How to Implement OAuth for a Multi-Wearables App

Introduction

If you are building a health, wellness, or longevity product that touches wearable data, you will eventually need to support more than one device. That moment is when the OAuth problem stops being a one-off integration ticket and starts being a structural part of your engineering roadmap.

This post walks through what it actually takes to ship OAuth for the major consumer wearables in a single app, what gets expensive when teams build it from scratch, and how Open Wearables (the open-source platform Momentum built and maintains) collapses the work into a much shorter timeline. It is written for engineering leads and product owners deciding whether to build, buy, or use open source for the wearable layer in their product.

The short version: every consumer wearable provider runs its own flavor of OAuth 2.0, getting partner-program approval is often slower than writing the code, and the maintenance burden compounds over time. Open Wearables solves the engineering side through a shared OAuth template with provider-specific subclasses, and Momentum offers a managed engagement that handles the rest (partner-program procurement, compliance posture, deployment, custom scoring, AI layers on top) for teams that want to ship in weeks rather than quarters.

The Real Cost of Multi-Wearables OAuth

Most health products that touch wearable data start with one provider, usually Apple Health or Garmin, and add the next when a customer asks. The second integration takes longer than the first. The third takes longer than the second. By the fifth, the team is rebuilding parts of the first.

This is not a tooling problem. It is a structural one.

Every consumer wearable provider implements OAuth 2.0 differently. Garmin requires PKCE. Polar uses Basic Auth in the header. Whoop and Strava put client credentials in the request body. Suunto requires an additional subscription key on every API call. The deltas per provider are not huge in isolation. They compound across an integration roadmap.

Across a typical wearable product portfolio, in our team's experience, a backend team spends several weeks per provider once you count: partner-program approval, sandbox setup, OAuth flow implementation, token refresh logic, webhook handling, scope mapping, data normalization, error handling, and the eventual provider migration. Stack that across a portfolio of providers, and the wearable plumbing alone consumes much of the backend roadmap before the product layer on top is built.

Teams who reach out to us about Open Wearables typically share one of these triggers:

• A pricing review surfaced the per-user cost of a SaaS wearable aggregator at projected scale.
• A compliance conversation flagged third-party data handling as a problem.
• An engineering review showed that maintaining half a dozen bespoke OAuth flows was consuming a quarter of the backend team's bandwidth.
• A data-science team needed access to raw, normalized cross-provider data and the existing aggregator did not expose it the right way.

In all of these, the underlying question is the same: is there a faster way to do this without giving up data ownership?

What Building Multi-Wearables OAuth Actually Looks Like

If you build the integration yourself for each provider, the work per integration includes the following:

1. Developer-account access. Apply to the provider's partner program. Get reviewed. Wait. Some providers approve in days. Some take weeks. Some block new accounts entirely.
2. OAuth credentials and redirect URIs. Configure them in the provider portal. Make sure they match your environments (local, staging, production). Each provider has its own UI for this.
3. Authorization flow. Build the redirect URL with the right scopes. Add PKCE if the provider needs it. Generate a random state token, store it server-side, validate it on callback.
4. Token exchange. POST the authorization code with the right authentication method (Basic Auth header for some providers, body credentials for others). Parse the token response. Some providers add fields beyond the standard OAuth spec.
5. Token storage and refresh. Store access tokens, refresh tokens, expiration times, and scopes per user per provider. Build a background job that refreshes tokens before they expire. Handle the case where the refresh token does not get rotated.
6. Webhook registration. Some providers require webhook registration after OAuth completes. Each has its own subscription model and verification handshake.
7. Data fetching and normalization. Map the provider's data shape to your internal model. "Sleep duration" means something slightly different to Whoop, Oura, and Garmin. Reconciling that takes weeks per provider.
8. Error handling and reconnection. When a user revokes access, when tokens expire and refresh fails, when the provider migrates their OAuth version, surface clear messages and route the user to reconnect cleanly.

Multiply that by every provider you support. Then add the maintenance burden over time: provider deprecations, scope changes, partner-program renewals, OAuth version migrations. The technical complexity is not the problem. The breadth and the drift over time are.

How Open Wearables Solves It

Open Wearables is an MIT-licensed, self-hosted wearables data platform. Momentum built it and ships it as open source on GitHub at github.com/the-momentum/open-wearables.

The OAuth piece is one part of what it does. The shape of the solution looks like this.

One shared OAuth template, every provider

Open Wearables uses a strategy pattern with a BaseOAuthTemplate class that owns the parts of OAuth that do not change per provider: state generation, Redis-backed CSRF protection, token exchange, token refresh, and connection persistence. Each provider implements only what is unique to it: its endpoints, its credentials, whether PKCE is required, and which auth method it expects.

In practice, the full Garmin OAuth class is under 50 lines:

class GarminOAuth(BaseOAuthTemplate): ""
"Garmin OAuth 2.0 with PKCE implementation."
""
@property def endpoints(self) - > ProviderEndpoints: return ProviderEndpoints(authorize_url = "https://connect.garmin.com/oauth2Confirm", token_url = "https://diauth.garmin.com/di-oauth2-service/oauth/token", ) @property def credentials(self) - > ProviderCredentials: return ProviderCredentials(client_id = settings.garmin_client_id or "", client_secret = (settings.garmin_client_secret.get_secret_value() if settings.garmin_client_secret
  else ""), redirect_uri = settings.garmin_redirect_uri, default_scope = settings.garmin_default_scope, ) use_pkce = True auth_method = AuthenticationMethod.BODY

Source: backend/app/services/providers/garmin/oauth.py

Everything else (PKCE verifier generation, state validation, token storage, refresh, error handling, structured logging) comes from the shared base. The same shape exists for Polar, Suunto, Whoop, and Strava in the current release. Because the provider-specific surface area is small, adding a new provider is typically a couple of weeks of focused engineering for the team, rather than a multi-month project.

Provider toggles in the admin UI

Once Open Wearables is running, enabling or disabling a provider is a checkbox in the developer dashboard. The platform exposes a /oauth/providers endpoint that returns the configured providers, their icons, whether they have a cloud API, and whether they are enabled. Your mobile or web app reads from that endpoint and renders the available wearables for the user to connect. No code change in your product when a new provider gets added on the backend.

A REST API your product reads from

After a user connects a wearable, the OAuth complexity disappears from your product's perspective. From that point, your product reads normalized wearable data from a single REST API (or via the included MCP server if you are building an AI assistant on top). The complexity of which provider, which scope, which webhook, which token state, stays inside Open Wearables.

Webhooks and 24/7 ingestion included

Open Wearables ships webhook handlers for the providers that support push, including Garmin and Strava in the current release, with additional provider webhooks landing across releases. Polling is supported as a fallback for providers that do not push. The platform pre-aggregates data so the API response from your product is immediate, with no waiting on vendor fetches at request time.

Self-hosted and MIT-licensed

Open Wearables runs on your infrastructure. Your patient health data never leaves your environment. The code is MIT-licensed, so you can fork it, extend it, ship it inside a regulated product, or hand it off to another team without a license conversation. There are no per-user fees.

The Developer-Account Problem Is Separate

Even with the code written, you still need developer-account access from every provider.

Garmin Health API access is gated by Garmin's partner program, with a review process that typically runs in weeks. Whoop, Polar, Suunto, and Oura each have their own partner-program flow. Some are fast. Some take weeks. Some require named business contacts and signed agreements.

This is the part that disappears when you use a SaaS aggregator like Terra, Junction, Spike, or Sahha. They handle the partner relationships and front you the access. The trade-off is per-user fees and a vendor sitting between you and your customers' health data.

It is also the part that becomes invisible work when teams build wearable integrations themselves. The engineering cost is easy to estimate. The partner-program lead time is the one that slips most product roadmaps.

For Momentum clients, this work runs in parallel with the engineering. The team starts on the code. The customer success side starts the partner-program applications. We maintain templates and named contacts on the provider side to shorten the back-and-forth. A self-hosted product gets the same partner-relationship benefit as a SaaS aggregator, without giving up data ownership.

What Momentum Adds On Top of Open Wearables

Open Wearables is the open-source baseline. It works on its own. A lot of teams clone the repo, deploy it themselves, and ship.

The teams that engage Momentum commercially are the ones where OAuth is one of several things they need handled. Once you are building a wearable-driven product, you are also building:

• A scoring layer (sleep score, recovery score, custom cohort-calibrated scores)
• An AI assistant or coaching layer that understands biometric data
• HIPAA or GDPR compliance posture, including BAA signing
• Webhook ingestion at scale, 24/7 sync monitoring, alerting
• Native mobile SDKs (Apple Health, Samsung Health Connect, Google Health Connect)
• Custom integrations with EHR, CGM, blood biomarker, or clinical-grade peripherals

What You Get With a Momentum Engagement

When you bring Momentum in to ship wearable infrastructure for your product, the engagement gets you:

Production-ready OAuth across the providers currently supported in Open Wearables. Garmin (PKCE), Polar, Suunto, Whoop, Strava, plus Apple Health and Samsung Health Connect (SDK-based). No OAuth code to write on your side.

Partner-program procurement support. We have run partner-program applications for clients across the major wearable providers, and we hold working relationships on the provider side. The review timeline is set by the provider, but we handle the application paperwork and follow-up so your team can stay focused on the product build.

Self-hosted deployment on your cloud. AWS, GCP, Azure, or regional clouds like StackIT in Germany or Etisalat in the UAE. Docker Compose deployment with hardened infrastructure templates we have shipped before for healthcare clients.

Compliance posture out of the box. HIPAA-aware architecture, BAA signing, GDPR posture, and internal compliance assets the engineering team applies during builds. Our DevSecOps function reviews every deployment.

A custom scoring layer for your user cohort. Open Wearables normalizes raw provider data into a unified schema. On top of that, Anna Zych's data science team builds scoring models (sleep quality, recovery readiness, condition-specific composites) calibrated to your user population.

An AI assistant layer when you want one. Open Wearables ships an MCP server that exposes user health data to LLM agents. A multi-agent assistant on top is a scoped engagement that reuses the same infrastructure.

Ongoing maintenance under SLA. Provider migrations, scope changes, OAuth version updates, security patches, partner-program renewals. We handle the drift so your team does not.

Direct access to the people who maintain Open Wearables. Slack channel and weekly calls with the engineering and data-science leads on the project, not a ticketing queue.

Talk to Momentum

If you are building a multi-wearables product and want the OAuth and ingestion layer handled, Momentum runs this for client teams in health, wellness, longevity, and clinical software.

Two engagement shapes:

Managed Open Wearables. We deploy and operate Open Wearables on your infrastructure under SLA. Fixed-cost setup plus a maintenance retainer. No per-user fees.

Custom wearable software development. When the product layer on top (AI coach, clinical scoring, EHR integration, regulated-environment deployment) is the actual work, we build it. Open Wearables infrastructure is included in scope.

Both start with a Discovery Workshop, and you leave with a scope and a timeline.

Talk to Momentum