feat: capture MaxMind tracking token at signup#77
Merged
Conversation
Move the browser-side device fingerprint out of user metadata and onto the Zitadel session created during signup. Device fingerprinting is intrinsically session-scoped: a single user can have many sessions across many devices, and keeping the token on the session avoids polluting a long-lived User resource with a transient signal. Key features/changes: - New client component MaxMindTracker initialises window.__mmapiws, injects device.js once, and polls the __mmapiwsid cookie until the token is available, persisting it to sessionStorage so the value survives the /register -> /register/password route transition - Layout gates the tracker on NEXT_PUBLIC_MAXMIND_ACCOUNT_ID, mirroring the existing Fathom and Marker.io toggles, so dev and preview deployments never contact MaxMind - All three register forms (password, passkey-only, IDP-incomplete) read the token from sessionStorage and pass it through registerUser / registerUserAndLinkToIDP - registerUser / registerUserAndLinkToIDP forward the token as Zitadel session metadata (key maxmind/tracking-token) via the new metadata parameter on createSessionAndUpdateCookie / createSessionForIdpAndUpdateCookie / createSessionFromChecks / createSessionForUserIdAndIdpIntent. addHumanUser is unchanged - Document NEXT_PUBLIC_MAXMIND_ACCOUNT_ID in next-env-vars.d.ts auth-provider-zitadel's session apiserver surfaces the metadata entry on the milo Session annotation iam.miloapis.com/maxmind-tracking-token which the fraud service reads when constructing the minFraud request. Token capture is best-effort: if device.js hasn't returned the cookie before submit, the user proceeds without it and the fraud check falls back to IP/email/UA signals only.
mattdjenkinson
force-pushed
the
feat/maxmind-device-tracking
branch
from
0c8f9f7 to
3168e91
Compare
ecv
approved these changes
May 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge order (4 of 5)
Part of a cross-repo rollout enabling MaxMind device fingerprinting in the signup fraud check.
Safe to merge in isolation: the tracker is gated on `NEXT_PUBLIC_MAXMIND_ACCOUNT_ID` and the env var is only set by the infra PR, so until infra rolls out this is a pure no-op.
Summary
Attach the MaxMind tracking token to the Zitadel session created at signup (not to the user) — device fingerprinting is intrinsically per-session, and keeping the token off the long-lived User resource avoids leaking a transient signal where it doesn't belong.
Key features/changes:
Token capture is best-effort: if `device.js` hasn't returned the cookie before submit, the user proceeds without it and the fraud check falls back to IP/email/UA signals only.
Test plan