Add Google Health API authorization support by this-Aditya · Pull Request #332 · RADAR-base/RADAR-Rest-Source-Auth

this-Aditya · 2026-05-01T09:04:24Z

A new authorization service handles Google's oauth2 flow.
Because the same participant may already have a Fitbit account from before the Google Health migration, the identity payload also carries an optional legacy Fitbit user ID, so we can keep both linked to the same RestSourceUser without losing history.

PKCE is enabled for Google as an extra security layer on top of the standard oauth2 flow. If it turns out Google's auth servers don't play nicely with the PKCE flow in , I'll drop it and fall back to the plain oauth2 path.

…cading

yatharthranjan

Thanks @this-Aditya, looks nice. Has this been tested working? If so, can we release this soon (so at least we can authorise new participants on this, we can always pull the data later)

yatharthranjan · 2026-06-02T09:58:59Z

+    clientId: <GOOGLE_CLIENT_ID>
+    clientSecret: <GOOGLE_CLIENT_SECRET>
+    scope: https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly https://www.googleapis.com/auth/googlehealth.health_metrics_and_measurements.readonly https://www.googleapis.com/auth/googlehealth.sleep.readonly https://www.googleapis.com/auth/googlehealth.profile.readonly
+    oauthVersion: oauth2


is this required config? should it not be oauth2 by default?

Yeah, it is OAuth 2.0 by default. I only kept it here to highlight it.

likely remove it if that is the default and does not require configuration

Should I do it now, or after the Garmin migration? We might be able to remove this configuration completely then, since we'll only be left with oauth 2.0.

yes i think for garmin, it should still be configurable if needed (especially for legacy deployments and until Garmin forces use of OAuth2.0)

yatharthranjan · 2026-06-02T10:05:58Z

+    tokenEndpoint: https://oauth2.googleapis.com/token
+    clientId: <GOOGLE_CLIENT_ID>
+    clientSecret: <GOOGLE_CLIENT_SECRET>
+    scope: https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly https://www.googleapis.com/auth/googlehealth.health_metrics_and_measurements.readonly https://www.googleapis.com/auth/googlehealth.sleep.readonly https://www.googleapis.com/auth/googlehealth.profile.readonly


what about other scopes like - nutrition, irn, ecg, location (some studies have been explicitly requesting location records for activities recently so would be good to include if possible)?

Yeah, we can add these, but google docs says that we can only request the scopes for which we are collecting data. So, if we want to increase the number of data points, we can add them

yes shoudl at least add nutrition, irn and ecg

this-Aditya · 2026-06-02T10:53:53Z

Has this been tested working?

Yeah, I've tested it. If you'd like, you can also verify it on staging.

If so, can we release this soon (so at least we can authorise new participants on this, we can always pull the data later)

I think that even if we release it soon, we still need to pass google's verification process and CASA, which I think will take some time.

One more thing -- when participants authorize google, the current flow deregisters them from fitbit. If we initially add this to the rest sources only, I think it would be nice if they could choose a start date later, and the historical data would then be covered by backfill. Otherwise, we'll only receive data from the start date onward through push notifications.

yatharthranjan · 2026-06-02T11:23:21Z

I think that even if we release it soon, we still need to pass google's verification process and CASA, which I think will take some time.

I think for new deployments it would work up to 100 users without verification?

One more thing -- when participants authorize google, the current flow deregisters them from fitbit. If we initially add this to the rest sources only, I think it would be nice if they could choose a start date later, and the historical data would then be covered by backfill. Otherwise, we'll only receive data from the start date onward through push notifications.

If the updated push endpoint is not deployed yet (only authorise in updated rest-source-auth), then when we are ready and do deploy push-endpoint, should it not backfill from the start date?

yatharthranjan · 2026-06-02T11:36:01Z

-        if (sourceTypeOauthMap[GARMIN_AUTH].equals("oauth2", ignoreCase = true)) {
+        // Bind Garmin service based on configured oauthVersion: "oauth2" → PKCE flow, "oauth1" → legacy flow.
+        val garminUsesPkce = restSourceClients.clients.firstOrNull { it.sourceType == GARMIN_AUTH }?.usesPkce == true
+        if (garminUsesPkce) {


I think more readable to just use oauthVersion from config here

I've updated this in PR #333. As this PR derives usesPkce from the RestSourceClient, I think that's a better place to handle it than doing it here.

yatharthranjan · 2026-06-02T11:36:28Z


        bind(OAuth2RestSourceAuthorizationService::class.java)
            .to(RestSourceAuthorizationService::class.java)
            .named(FITBIT_AUTH)


should we somehow mark this as deprecated?

It would be nice if we could do this after september 2026, as they will still receive data from the fitbit app until september if they signed up using their google account.

I think ok to mark as deprecated (not decomissioned), with details on when it will be non-functional (sept 2026)

this-Aditya · 2026-06-02T11:51:13Z

I think for new deployments it would work up to 100 users without verification?

Yeah, there are 100 users in testing, but while the app is in testing, we need to manually add users' email addresses. (Alternatively, could you try making the user internal? I can't do that)

If we publish the app without verification, users can still select the advanced options and proceed with authorization, although they will see this warning:

this-Aditya · 2026-06-02T11:55:29Z

If the updated push endpoint is not deployed yet (only authorise in updated rest-source-auth), then when we are ready and do deploy push-endpoint, should it not backfill from the start date?

Sorry, I meant that the push endpoint is also deployed. But this version explicitly handles the inconsistencies between the documentation and the actual responses. Based on the real responses, we are only rejecting some data that contains partial information, otherwise, it is working perfectly fine on stage.

yatharthranjan · 2026-06-02T15:02:38Z

I think for the new deployments we can live with the warning as it will be better than asking participants to authorise again. But i will confirm with the study team what they prefer.

how long does CASA review take?

this-Aditya · 2026-06-02T15:37:09Z

I think for the new deployments we can live with the warning, as it will be better than asking participants to authorise again. But I will confirm with the study team what they prefer.

Yeah, but we can only recruit 100 participants, and we are now aiming for one client ID (I assume), so it would be across all projects. Is it sufficient before we get verified?

how long does CASA review take?

It depends on which third-party assessor lab we pick, and also varies by tier (we need at least Tier 2, or maybe Tier 3). But I think it is going to take substantial time. Some mention it takes 1-3 weeks once testing starts (or 2-4 weeks for Tier 3). And as we request restricted scopes, it can take longer (Google says this).

yatharthranjan

LGTM, please merge the base branch (outdated atm)

mpgxvii

Thanks! LGTM.

this-Aditya added 6 commits April 16, 2026 19:10

Starting with the google health configs

fe1275d

API class for storing both the leagcy fitbit and new google user id

0a0f3d9

Authorization service to handle google oauth2 flows

afddd1d

Bind google servics and use pkce

f5388cb

Add Google Auth const

b4ffd95

Use correct source type

4310e3d

this-Aditya requested review from mpgxvii and yatharthranjan May 1, 2026 09:04

this-Aditya linked an issue May 1, 2026 that may be closed by this pull request

Migrate source authorization from Fitbit OAuth to Google Health API OAuth #331

Open

this-Aditya added 2 commits May 27, 2026 09:48

Remove unused scopes

3594ef4

Revoke the fitbit tokens and also delete by external user id when cas…

8226937

…cading

yatharthranjan reviewed Jun 2, 2026

View reviewed changes

More scopes and format code

954e55a

yatharthranjan previously approved these changes Jun 2, 2026

View reviewed changes

mpgxvii reviewed Jun 2, 2026

View reviewed changes

Comment thread ...nd/src/main/java/org/radarbase/authorizer/service/DelegatedRestSourceAuthorizationService.kt Outdated

Updaye google auth to 'GoogleHealth'

f2ff137

this-Aditya dismissed yatharthranjan’s stale review via f2ff137 June 3, 2026 06:17

Merge branch 'dev' into google-health-api

4765f2b

mpgxvii self-requested a review June 4, 2026 07:51

mpgxvii approved these changes Jun 4, 2026

View reviewed changes

this-Aditya merged commit 2906310 into dev Jun 4, 2026
11 of 14 checks passed

this-Aditya deleted the google-health-api branch June 4, 2026 07:53

this-Aditya mentioned this pull request Jun 8, 2026

Rename source type to GoogleHealth in configs #336

Merged

Conversation

this-Aditya commented May 1, 2026

Uh oh!

yatharthranjan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

this-Aditya commented Jun 2, 2026

Uh oh!

yatharthranjan commented Jun 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

this-Aditya Jun 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

this-Aditya commented Jun 2, 2026

Uh oh!

this-Aditya commented Jun 2, 2026

Uh oh!

yatharthranjan commented Jun 2, 2026

Uh oh!

this-Aditya commented Jun 2, 2026

Uh oh!

yatharthranjan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mpgxvii left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

this-Aditya Jun 2, 2026 •

edited

Loading