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

• 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.

Browser storage

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

• theme in local storage. The account pages (/profile, /security, /connected-apps and /organization-invite) store the light or dark theme when they load and when the person switches it. Every hosted page reads it to pick its colors. It holds light or dark.

• 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 six 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 browser storage described above applies on Udibo's host too. There, the site and dashboard pages also store theme, and the marketing and docs pages store analytics-consent, the visitor's answer to the analytics question below.

Analytics on Udibo's marketing and docs pages

Where optional analytics is enabled, Udibo's home page, pricing, privacy policy and documentation ask visitors whether to allow Google Analytics. Until a visitor allows it, no Analytics script loads, no Analytics cookie is set and no Analytics request is sent to Google. A visitor who allows it gets two cookies from Google Analytics:

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. Declining removes these cookies. Withdrawal stops further collection and reloads tabs running the tag on the same origin; it does not erase information already collected by Google. See the Privacy Policy.

Last verified 2026-10-29.