Cookies on your hosted pages

Your users sign in, manage their account, and accept organization invitations on your tenant's hosted pages. Those pages set the cookies below on your tenant's host. Your users meet them inside your product, so list them in your own privacy or cookie notice. Udibo's privacy notice covers visitors to Udibo's own site; it tells your users to read yours.

Your tenant's host is https://{tenant-id}.udibo.com, where {tenant-id} is your tenant's ID. Custom domains for hosted pages are not available, so every hosted page is served from that host.

What every cookie has in common

These hold for every cookie except theme, which is described in its own section.

• HttpOnly. Page scripts cannot read these cookies. Only Udibo's server reads them.

• Secure. The browser sends them over HTTPS only.

• Host-only. No cookie sets a Domain attribute. A cookie set on your tenant's host goes back to that host alone. Your application's domain, another tenant's host, and udibo.com never receive it.

• Set by a step, not by a visit. Each cookie is set when a person takes a step described below, such as submitting the sign-in form. None is used for advertising or analytics.

The __Host- prefix on some names tells the browser to accept the cookie only from a secure page on this exact host, with Path=/ and no Domain.

Cookies on your tenant's host

__Host-session_id

• Purpose: keeps the person signed in to your tenant, so they are not asked to sign in again for each application that sends them to your hosted pages.

• Set when: a sign-in completes by any method, or an account is created. A support session that Udibo starts in your tenant sets it in the support person's browser, never in your user's. Signing out, or visiting with a session that has ended, clears it.

• Lifetime: a password sign-in with Remember me ticked, a social sign-in, and account creation set a persistent cookie. It expires when the session does, after your tenant's remember-me lifetime (30 days unless you change it). An email code or magic-link sign-in, or a password sign-in without Remember me, sets a cookie with no expiry, which the browser deletes when it closes. That session ends after your tenant's session lifetime (24 hours unless you change it). Any session also ends after your tenant's idle timeout.

• What it holds: a random secret. Udibo stores only its hash, linked to the signed-in account, and uses it to find the session on each request.

device_id

• Purpose: recognizes a browser that has signed in to an account before, so a sign-in from an unfamiliar one can be flagged, for example with a new-device notice to the account owner.

• Set when: a sign-in completes in a browser that does not already carry one. It is not replaced on later sign-ins.

• Lifetime: 400 days.

• What it holds: a random ID with no meaning of its own. Udibo stores a hash of it for each account that signs in from the browser.

mfa_pending

• Purpose: carries a sign-in between the first step (a password, a code, or a social provider) and the second-factor challenge or enrollment that follows.

• Set when: a sign-in needs a second factor. Completing the second factor clears it.

• Lifetime: 10 minutes. The value also carries its own expiry, which Udibo checks.

• What it holds: the user's ID, the sign-in method, and where to send the person afterwards, encrypted so that only Udibo's server can read it. During enrollment it also carries the new recovery codes until they have been shown.

social_auth

• Purpose: ties the return from a social provider, such as Google or GitHub, to the browser that started it, so another site cannot complete a sign-in on someone's behalf.

• Set when: a person chooses a social provider on a hosted page, either to sign in or to link the provider to their account. The provider's return clears it.

• Lifetime: 10 minutes.

• SameSite: Lax, except for Sign in with Apple, which returns to your tenant's host with a cross-site form submission. That cookie is SameSite=None so it survives the return. The value's state check is what protects that flow.

• What it holds: the provider, the one-time values the provider's protocol needs, and where to send the person afterwards, encrypted. A link attempt also carries the user's ID, and a sign-up from a waitlist invitation carries that invitation's token.

__Host-oidc_reauthentication

• Purpose: ties a fresh sign-in to the application request that asked for it, so the evidence of that sign-in reaches that request alone.

• Set when: your application's authorization request asks for fresh authentication with prompt=login, max_age, or acr_values. The request's final response clears it. The application configuration guide describes those parameters.

• Lifetime: 10 minutes. The value also carries its own expiry.

• What it holds: your tenant and application, a one-time value, and, when the person is already signed in, the user's ID, encrypted.

__Host-step_up_reauthentication

• Purpose: ties a fresh sign-in to the account change on /security that asked for it, so a person with no password and no two-factor can confirm it's them by signing in again with a provider they already use (or, with none, by an emailed sign-in code or link), and only that change can use the proof.

• Set when: the signed-in person starts a step that confirms it's them by signing in again on /security: "Confirm by signing in with …" on a connection request or in the Two-step sign-in section, or a Connect button in the connected accounts list, which says it will ask them to sign in again first, or "Confirm by email" for an account that signs in only by email. It is SameSite=None only when that provider answers with a cross-site form post, as Sign in with Apple does. A sign-in that does not confirm it clears it; a sign-in cancelled at the provider leaves it until its 10 minutes run out.

• Lifetime: 10 minutes. The value also carries its own expiry.

• What it holds: your tenant, the user's ID, a one-time value and what the proof is for, encrypted.

__Host-passkey_sign_in, __Host-passkey_mfa, __Host-passkey_registration, and __Host-passkey_step_up

• Purpose: tie a passkey prompt to the browser that asked for it, so the signed answer is checked against the one-time challenge Udibo issued to that browser. Each step has its own cookie: signing in with a passkey, answering the two-step challenge with one, adding one on /security, and confirming an account change or an application's phishing-resistant request with one. See passkeys.

• Set when: a person starts one of those passkey steps. Finishing the step spends the challenge, whatever the outcome.

• Lifetime: 5 minutes.

• What it holds: a random ID that names the challenge on Udibo's server. It carries no user ID; the challenge it names is deleted when it is used or expires.

__Host-sign_in_link

• Purpose: tie an emailed sign-in link to the browser that asked for it, so the link signs in only there. Opened in any other browser, the link signs no one in and stays usable where it was asked for. See passwordless sign-in.

• Set when: a person asks for a sign-in email, or confirms an account change by email. It is cleared once a link signs that browser in.

• Lifetime: 25 minutes: long enough to cover a link sent up to 10 minutes after the request plus the link's own 15.

• What it holds: a random value. The emailed link carries only its hash. It carries no user ID.

__Host-passkey_sign_up

• Purpose: tie an account being created with a passkey to the browser that started it, so the emailed code and the new passkey count only there. See passkeys.

• Set when: a person asks for the code on Create an account with a passkey. It is cleared once the account is created.

• Lifetime: 15 minutes.

• What it holds: a random ID that names the pending sign-up on Udibo's server, which keeps only a hash of the email address until the account exists. It carries no user ID.

The theme cookie

• Purpose: remembers the color scheme a person picked, so every hosted page, error pages included, arrives in it, with JavaScript on or off, and never flashes the other scheme.

• Set when: a person picks Light or Dark in the theme menu on the account pages (/profile, /security, /connected-apps and /organization-invite). Picking System removes it, and the pages then follow the device's setting. A light or dark choice that an earlier version kept in local storage moves into this cookie the first time any hosted page loads with JavaScript on. A tenant that offers one color mode keeps its pages in that mode whatever the cookie holds.

• Attributes: the page's own script writes it, so it is not HttpOnly. It is Secure on your tenant's HTTPS host and host-only, with no Domain. Udibo's server reads it only to choose the scheme the page is drawn in, and ignores any value other than light or dark.

Browser storage

The hosted pages also use the browser's own storage, which never leaves the browser:

• react-router-scroll-positions in session storage. Every hosted page with JavaScript on writes it when the person leaves the page, so going back returns to the same scroll position. It holds a scroll offset for each page visited in the tab. The browser deletes it when the tab closes.

• react-router-manifest-version in session storage. Written only when a page finds that Udibo was updated after it loaded, just before it reloads itself to pick up the update. It holds the update's version, so the page reloads once rather than repeatedly. The browser deletes it when the tab closes.

Third-party content

The sign-in, sign-in code and link request, sign-up, password-reset, and waitlist pages can show a Cloudflare Turnstile challenge. They do when your tenant has its own Turnstile keys, and when your tenant has stored no CAPTCHA settings while Udibo's deployment provides default keys. A tenant that has turned CAPTCHA off shows none. The page then loads Turnstile's script from challenges.cloudflare.com. This page does not list what Turnstile stores; Cloudflare's own documentation describes it.

On Udibo's own host

Udibo's own site and dashboard, at udibo.com, set the cookies below. That includes your administrators' sign-ins to the dashboard. The first eleven work as described above for your tenant's host, but on Udibo's host they are sent to Udibo's host alone.

Every one of them is HttpOnly and Secure, with no Domain. On Udibo's host, the session and remember-me lifetimes are the ones Udibo sets for its own dashboard.

__Host-oauth2_login_state

• Purpose: makes the dashboard accept a sign-in only in the browser that started it.

• Set when: someone starts signing in to Udibo's dashboard. The return from that sign-in removes the attempt it answers.

• Lifetime: 10 minutes.

• What it holds: hashes of the dashboard's pending sign-in attempts, at most three. It holds nothing that identifies a person.

Your users never reach Udibo's dashboard sign-in from your hosted pages.

The theme cookie and the browser storage described above apply on Udibo's host too. There, the theme menu on the site and dashboard pages sets the theme cookie as well. The marketing and docs pages use:

• analytics-consent in local storage. Your explicit analytics choice, granted or denied. Automatic eligibility described below does not write a choice for you. There is no timed expiry; you can change it through Analytics choices or clear it with your browser's storage controls.

• analytics-policy-notice in local storage. The version of the Google Analytics notice you dismissed. It has no timed expiry; a new notice version can be shown again. Dismissing it does not allow analytics or change an earlier choice. Choosing Allow, Decline or Turn off also dismisses that notice.

• analytics-session-denial in session storage. A fallback value of denied when a decline cannot be saved in local storage. It preserves that choice across reloads in the tab and is cleared by a later choice or when the browser ends that session.

• analytics-choice-storage-check in local storage. A temporary value of 1, immediately removed, used to check that the browser can save an opt-out before allowing automatic analytics.

If local storage is unavailable, automatic analytics stays off. A new explicit grant or notice dismissal can only be remembered for the current document; a decline can use the session-storage fallback. If that is unavailable too, the decline lasts only in the current document.

Analytics on Udibo's marketing and docs pages

Where Google Analytics is enabled, it measures visits to Udibo's home page, pricing, Privacy Policy and documentation. It may run automatically for requests reliably identified as coming from the United States when browser storage can save an opt-out. For other or unknown locations, no Google Analytics script loads, cookie is set or request is sent until you choose Allow analytics. A saved decline applies in every location. A supported Global Privacy Control signal keeps Google Analytics off, even if you previously allowed it. The pages remain available with it off.

When Google Analytics runs, it sets two cookies:

They are set by a script, so they are not HttpOnly, and they are host-only on the host serving Udibo's public pages: your tenant's host never receives them. Browser restrictions may shorten their lifetime. Analytics never runs on Udibo's sign-in, account or dashboard pages, nor on any page of your tenant's host, so your users never meet these cookies inside your product.

Use Analytics choices in the public-page footer to change your choice. Turning it off removes these cookies and stops collection on that page. When the choice can be saved in local storage, other tabs on the same origin receive it and reload if they run the tag. If storage is blocked, a tab-only or page-only choice cannot notify other open tabs; close those public-page tabs to stop their collection too. A supported GPC signal keeps Google Analytics off wherever your browser sends it. Withdrawal does not erase information already collected by Google. Clearing browser storage removes a saved choice; eligible US visits can then run analytics automatically unless GPC is active, while other or unknown locations ask again.

Separate Cloudflare performance measurement

Udibo also uses Cloudflare performance measurement to understand page-loading speed and reliability. Where enabled, its Web Analytics beacon sends browser and page-performance information. Cloudflare describes that service as avoiding cookies, local storage and fingerprinting to track individual visitors over time. This is separate from Google Analytics and from Cloudflare's network delivery, security and Turnstile services. Analytics choices and the GPC handling described above control Google Analytics; they do not turn off these Cloudflare services.

See the Privacy Policy for information use, recipients and your rights, and Cloudflare's description of its performance service.

Last verified 2026-11-08.