Compatibility and Constraints

This page answers the question every engineering team asks first: will this work with our stack, and what does it do to our application?

​

1. What Observe requires

The frontend integration requires no backend integration or changes to your authentication logic. Hosted login pages may require an administrator to add the snippet and update CSP in the identity provider. Observe works the same whether you run a commercial IdP, an open-source WebAuthn library or a custom in-house implementation. See what Observe is not. Observe is telemetry only. It is not in the authentication path and cannot grant, deny, delay or alter a login. An SDK failure, a blocked request or a missing configuration costs you telemetry, never an authentication.

​

2. Platform support

Autocapture Light combines automatic capture on native platforms with custom events for your authentication flows. The native SDKs automatically collect device-specific information, relevant OS and SDK versions and other available platform signals. Your custom events add the journey steps and outcomes. JavaScript-based mobile frameworks such as React Native with Expo, Ionic or Capacitor authenticate through a web surface and are covered by the web integration wherever the login runs in a web context. Where a framework routes passkeys through a native platform API instead, use the native SDK for that platform. Native SDKs send into the same data model as the web SDK, so web and app journeys are comparable in the same project. Keep them apart with applications. App authentication behaves differently enough from web that the metrics worth tracking differ too: see Native app authentication analytics.

​

3. Iframes and RP IDs

If your authentication runs inside an iframe, which is common for embedded login and embedded wallets, two things matter:

• The SDK must run in the frame that performs the ceremony. navigator.credentials calls are observed in the document that makes them, not in the parent.
• The iframe must be permitted to perform WebAuthn. A cross-origin iframe needs the publickey-credentials-get and publickey-credentials-create permissions policy for passkeys to work at all. That is a requirement of your own implementation, not of Observe, but it is the first thing to check when ceremonies appear to be missing.

See the guide on relying party IDs for background on RP ID scoping.

​

4. Data handling

Observe can analyze authentication journeys without clear-text identifiers or user IDs. Choose whether to send each value in clear text or already hashed, and review the values you add to custom events, tags and contexts before sending them. For built-in protections, hashing and deletion per purpose, see privacy and data policies. Do not include passwords, session tokens or other credentials in values you explicitly send. Page URL metadata needs the same review. Collected: The web SDK reports the page path and query in meta.trackingSourcePath. By default, it keeps query keys and their order but replaces nonempty values with *. Empty values and keys without values remain. If a query value is safe and needed for analysis, add its key to sdkConfig.sourcePathQueryAllow when initializing the tracker; matching is case-insensitive, and a trailing * matches a prefix. Setting sdkConfig.sourcePathQuery to "all" sends the full query. Review paths and any allowed keys for sensitive data; this masking does not inspect their contents. Query-value masking is available in web SDK 0.16.7 and later. Upgrade older installed versions before relying on it; older SDKs can report full query values. You control account references. Hash identifiers and user IDs before sending when Corbado should never receive their clear values. Alternatively, send clear values for recent investigations and use a data policy to hash them later or delete their references when retention ends. Hashing preserves matching; deletion removes the corresponding links.

​

Password-manager evidence

Observe can record sightings of 1Password, Bitwarden, Dashlane, Kaspersky, Keeper, LastPass, NordPass and Proton Pass. Browser-extension detection is off by default and controlled by your project’s SDK configuration. For custom events, you can override it for a tracker with sdkConfig: { pmd: true } in init(). The override persists across server configuration refreshes. When enabled at the sample time, the web SDK samples at initialization, around window load and after the first focus of up to six fields registered with operation helpers. It sends manager names with a subsequent tracked event when the detected set grows. A detection after the page’s last tracked event is not reported. For a local diagnostic, the web SDK also exports detectPasswordManagerExtensions(). It returns the managers visible at call time, with an optional signedIn: true where that state can be observed. The tracker reports names only; it does not send this sign-in flag. Detection does not use extension IDs or extension messaging. A recognized password-manager passkey can also establish a sighting during enrollment or login, independently of browser-extension detection. Cross-platform ceremonies are excluded because the passkey may be on another device; missing attachment metadata is treated as same-device. A login needs a resolved credential with a known AAGUID before it can add this evidence. Sightings accumulate for the client environment and appear in User Search with first and last seen times. They are evidence collected over time, not a live installation inventory. A missing manager means it was not observed; it may still be installed. An autofilled field alone does not identify its provider.

​

5. Autocapture limitations

Autocapture observes the browser surfaces listed under what Autocapture actually does. Where it stops:

​

6. Browser and OS support

If you need a documented floor for older Android WebViews, legacy Edge or specific enterprise browser versions, ask us. The tested matrix is expanding and we would rather give you a precise answer than a marketing one.

​

Device information and private browsing

The web SDK collects device information with a fast snapshot within 300 ms and at most one later update for fields still running, up to 6 seconds after collection starts. Private-browsing detection runs at most once per page. A result ready early is included in the first snapshot; a failed or unfinished detection leaves the flag unknown. On a page that tracked events, a snapshot can travel with an event or in a separate request, including on unload. Separate snapshot delivery is best effort: it is neither persisted nor retried. Late values can fill missing fields for the same session environment; they do not overwrite conflicting reported values. Missing device information is still possible, especially on short visits. The deviceInfoCollectorTimeoutMs server setting and deviceInfoCollectorTimeout initialization option no longer change collection deadlines. Check reported collection errors and Technology when investigating missing fields.

​

7. Storage and consent

SDK storage and cross-tab locks are scoped by project ID. The storage option selects storage for device identity; it does not move all SDK state into cookies: Session storage holds the per-tab session. Local storage holds configuration, pending events and, when server-controlled session continuity is enabled, the shared session and sequence counter. Cookie mode still uses these browser stores and does not make sessions shared across origins. With local storage selected, the web SDK also caches a definite private-browsing result for up to seven days, scoped to the project and detector version. An expired, unreadable or incompatible cache entry triggers detection again. Cookie mode does not cache this flag between pages. The SDK checks inactivity when it initializes. A dated per-tab session that has reached its inactivity window gets a new ID at that point; continuity sessions also expire at initialization. Tracking refreshes activity, but inactivity alone does not rotate the ID within a running page. A long-lived page can therefore outlive the inactivity window. With continuity enabled, a tab can adopt a shared session ID changed by another tab. The inactivity window is server-controlled, not an initialization option. An Observe session is a telemetry grouping, independent of your application’s authenticated session. If a flow continues across page loads, its inactivity window must span that journey. On upgrade, a valid legacy bare session ID is preserved and dated when first read, rather than immediately split. Follow the upgrade instructions when introducing multiple projects. Observe stores no advertising identifiers and does no cross-site tracking. To align retention with your users’ privacy choices, select a data policy per session. If your assessment requires gating the SDK entirely, initialize Observe after the user’s choice; journeys before that point are not recorded.

​

8. Projects, environments and hosting

Keep environments in separate projects. Production, staging and development should not share a project, because mixed data makes funnels meaningless. Use applications to separate channels of the same product and tags for further dimensions. Observe runs on Corbado’s public cloud by default. Dedicated instances in a specific region are available for enterprise deployments, which matters if you have data residency requirements. Contact us to discuss options.

​

9. Next steps