AB#268288 Federated Authentication by graciecooper · Pull Request #87 · optimove-tech/Optimove-SDK-Android

graciecooper · 2026-03-25T16:10:59Z

Description of Changes

Adds Federated JWT authentication to the Android SDK. When OptimoveConfig.Builder.enableAuth(AuthTokenProvider) is used, the SDK asks the app for a JWT per user context and attaches it as X-User-JWT on user-identified outbound traffic (anonymous / install-scoped traffic omits the JWT where applicable).

Key changes

AuthManager + enableAuth(AuthTokenProvider) on OptimoveConfig.Builder
X-Optimove-Auth-Capable: 1 on SDK HTTP traffic (HttpClient + OptimobileHttpClient)
JWT for user-identified calls: Optistream (OptiTrack), Realtime, Preference Center, Embedded Messaging, Optimobile analytics, in-app (inbox fetch)
OptistreamHandler groups batches by customer so each request has one JWT
Optimobile analytics pulls the next queue slice per userIdentifier so the JWT matches the batch
Token failures: Optistream / Realtime skip sending that attempt; blocking-JWT Optimobile paths may still send without X-User-JWT

Usage

Kotlin

OptimoveConfig.Builder(/* … */)
    .enableAuth { userId, callback ->
        MyAuthService.getJwt(userId) { jwt, error ->
            callback.onComplete(jwt, error)
        }
    }
    // …
    .build()

Breaking Changes

None

Release Checklist

Prepare:

Detail any breaking changes. Breaking changes require a new major version number, and a migration guide in wiki / README.md

Bump versions in:

CHANGELOG.md
gradle.properties
add links to newly created wiki pages to readme
Update major version numbers in wiki (basic integration + push guides)

Integration tests

T&T Only

Init SDK with only optimove credentials
Associate customer
Associate email
Track events

Mobile Only

Deferred Deep Links

With app installed, trigger deep link handler
With app uninstalled, follow deep link, install test bundle, verify deep link read from Clipboard, trigger deep link handler

Combined

Track event for T&T, verify push received
Trigger scheduled campaign, verify push received
Trigger scheduled campaign, verify In-App received

Release Procedure

Squash and merge dev to master
Delete branch once merged

k-antipochkin · 2026-04-16T14:25:28Z

                }
-                result = super.postSync(url, postBody, true);
+                String jwt = super.resolveJwt(this.customerId);
+                if (AuthJwtResolver.isMissingRequiredJwt(Optimove.getConfig().getAuthTokenProvider(), this.customerId, jwt)) {


See line 99, could this cause all visitors to start failing requests? (userId is either userId or visitor here)

k-antipochkin · 2026-04-17T02:12:25Z

@graciecooper Can we add some more test coverage for the auth flows (Embedded, grouping etc) or that would require significant refactoring?

k-antipochkin · 2026-04-17T16:05:32Z

+                                    error != null ? error.getMessage() : "null token");
+                            dispatchRequestWaitsForResponse = false;
+                            scheduleTheNextDispatch();
+                            return;


Should we abort all the remaining groups if one fails?

k-antipochkin · 2026-04-17T16:07:08Z

+
+        Runnable postOnExecutor = () -> postGroupJson(group, groups, index, null);
+
+        if (authManager != null && !customerKey.isEmpty()) {


Can we reduce the indentation here?

if (authManager == null || customerIsEmpty) { postOnExecutor.run(); return; }

// rest of auth

k-antipochkin · 2026-04-17T16:31:35Z

@graciecooper Is it possible to introduce a single dispatcher layer for RT and optistream like we did in iOS? or it would require a big refactoring?

k-antipochkin · 2026-04-17T16:36:00Z

+- Added Federated JWT authentication; OptimoveConfig.Builder.enableAuth(AuthTokenProvider) supplies tokens; the SDK adds X-User-JWT for user-identified Optistream, realtime, Preference Center, Embedded Messaging, Optimobile analytics, and in-app network calls.
+- Added Auth-capable signaling; Outbound SDK requests sent through HttpClient and OptimobileHttpClient include X-Optimove-Auth-Capable: 1 so backends can detect JWT-capable SDK versions.
+- Optistream and realtime paths now group events by customer identity so each request can carry a single JWT. Optimobile analytics drains queued events per stored user id (install/visitor-scoped batches do not attach a user JWT).
+


k-antipochkin · 2026-04-17T16:37:55Z

+        Map<String, List<OptistreamEvent>> map = new LinkedHashMap<>();
+        for (OptistreamEvent ev : events) {
+            String key = userKey(ev);
+            map.computeIfAbsent(key, k -> new ArrayList<>()).add(ev);


Does it require API 24? I think our minimum is 21?

k-antipochkin · 2026-04-17T16:40:16Z

+                }
+                httpClient.postJson(realtimeConfigs.getRealtimeGateway(), realtimeGson.toJson(group))
+                        .userJwt(token)
+                        .successListener(jsonResponse -> dispatchGroupAtIndex(groups, index + 1, allForFailure))


Should it be allForFailure or just the one group?

k-antipochkin · 2026-05-05T00:32:38Z

    }

+    @Nullable
+    public static String getAssociatedUserIdentifier(@NonNull Context context) {


Should we just add a fallback param / or something like boolean excludeFallback as a second param to getCurrentUserIdentifier ?

i've went with a separate method because think it makes the intent more obvious than a boolean flag, especially around auth vs visitor fallback? but am happy to switch if you prefer the flag approach ? :)

k-antipochkin · 2026-05-05T00:55:07Z

    private InAppMessageView view;

    private boolean interceptionInProgress = false;
-    private int lastShownByInterceptorId = -1;


Is this safe to delete? I think it was added as an idempotency key that prevented applyMessageInterception from running the second time

Think I've accidentally committed a prev version of the file stored locally, didn't intend to delete this. Reverted!

k-antipochkin · 2026-05-05T01:22:48Z

+        Map<String, List<AnalyticsEventRow>> groups = new LinkedHashMap<>();
+        for (AnalyticsEventRow row : rows) {
+            String key = analyticsUserKey(row.event);
+            groups.computeIfAbsent(key, k -> new ArrayList<>()).add(row);


Seems like computeIfAbsent requires API 24, we are still on 21

oh yeah !! 😨 replaced with an explicit get/null-check/put

k-antipochkin · 2026-05-05T01:25:21Z

+                return "";
+            }
+            String u = event.optString("userId", "");
+            return u == null ? "" : u.trim();


can just return u.trim() ?

k-antipochkin · 2026-05-05T01:38:37Z

+                        deletePersistedEventsByIds(context, ids);
+                        continue;
+                    }
+                    return false;


Do we fail all groups?

k-antipochkin · 2026-05-05T01:39:07Z

+                }
+            } catch (IOException e) {
+                e.printStackTrace();
+                return false;


Same question here - do we fail all groups in this case?

k-antipochkin · 2026-05-05T01:55:21Z

+                        .errorListener(e -> onRealtimeRequestFailed(e, groups, index, group))
+                        .destination("%s", RealtimeConstants.REPORT_EVENT_REQUEST_ROUTE)
+                        .send();
+            });


Can we return here to reduce the indentation of the else block? feel free to ignore

Yeah that's probs more readable, done!

I think now just indented back? Created a wrong indentation. I meant if we just return on the if (authManager != null && !key.isEmpty()) block. Something like:

if (authManager != null && !key.isEmpty()) { authManager.getToken(key, (token, error) -> { if (error != null || token == null) { dispatchingFailed(error != null ? error : new Exception("null token"), group); return; } httpClient.postJson(realtimeConfigs.getRealtimeGateway(), realtimeGson.toJson(group)) .userJwt(token) .successListener(jsonResponse -> dispatchGroupAtIndex(groups, index + 1)) .errorListener(e -> onRealtimeRequestFailed(e, groups, index, group)) .destination("%s", RealtimeConstants.REPORT_EVENT_REQUEST_ROUTE) .send(); }); return; } httpClient.postJson(realtimeConfigs.getRealtimeGateway(), realtimeGson.toJson(group)) .userJwt(null) .successListener(jsonResponse -> dispatchGroupAtIndex(groups, index + 1)) .errorListener(e -> onRealtimeRequestFailed(e, groups, index, group)) .destination("%s", RealtimeConstants.REPORT_EVENT_REQUEST_ROUTE) .send();

Up to you though

graciecooper · 2026-05-05T09:45:23Z

@graciecooper Is it possible to introduce a single dispatcher layer for RT and optistream like we did in iOS? or it would require a big refactoring?

It's a bit footery in that I think it would involve a lot more time retro-fitting tests ...? I think it would overcomplicate this PR but happy to revisit if we feel strongly about completely aligning with iOS.

k-antipochkin · 2026-05-05T18:55:01Z

+        if (authManager != null && !key.isEmpty()) {
+            authManager.getToken(key, (token, error) -> {
+                if (error != null || token == null) {
+                    dispatchingFailed(error != null ? error : new Exception("null token"), group);


Should we still call dispatchGroupAtIndex(groups, index + 1) here? Otherwise one user's token-fetch failure halts the whole batch (iOS's OptistreamDispatcher always advances on per-group failure). In practice, seeing the big picture, this shouldnt really happen and even if it happens, there are 2 batches - user and visitor so in worst case we might halt the visitor batch.

Yeah, let's add it so that it advances the non-failing group and bring it in line with iOS

graciecooper force-pushed the feature/268288-federated-auth branch from 7e18f19 to db27d29 Compare April 2, 2026 11:16

graciecooper marked this pull request as ready for review April 2, 2026 11:46

k-antipochkin reviewed Apr 16, 2026

View reviewed changes

Comment thread OptimoveSDK/optimove-sdk/src/main/java/com/optimove/android/realtime/RealtimeManager.java

k-antipochkin reviewed Apr 16, 2026

View reviewed changes

Comment thread ...oveSDK/optimove-sdk/src/main/java/com/optimove/android/main/tools/networking/HttpClient.java

k-antipochkin reviewed Apr 17, 2026

View reviewed changes

Comment thread OptimoveSDK/optimove-sdk/src/main/java/com/optimove/android/AuthManager.java

k-antipochkin reviewed Apr 17, 2026

View reviewed changes

Comment thread OptimoveSDK/optimove-sdk/src/main/java/com/optimove/android/AuthJwtResolver.java

Squash Commits

33558ba

graciecooper force-pushed the feature/268288-federated-auth branch from ed28f78 to 33558ba Compare May 1, 2026 09:08

add headers

6575554

k-antipochkin reviewed May 5, 2026

View reviewed changes

graciecooper added 3 commits May 5, 2026 11:12

auth failure no longer aborts the batch & clean up constructor

0fc027a

fix broken tests

eed58de

address PR comments

7ceccc4

k-antipochkin reviewed May 5, 2026

View reviewed changes

address comments

e5526ad

address comments

496d0f0


		Runnable postOnExecutor = () -> postGroupJson(group, groups, index, null);

		if (authManager != null && !customerKey.isEmpty()) {

Conversation

graciecooper commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of Changes

Key changes

Usage

Breaking Changes

Release Checklist

Integration tests

Release Procedure

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

k-antipochkin commented Apr 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

k-antipochkin commented Apr 17, 2026

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!

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!

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!

graciecooper commented May 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

graciecooper commented Mar 25, 2026 •

edited

Loading