Product · Hand off setup and watch it
Offline Operation
What happens when a customer’s identity provider cannot be reached
Ships, plants, clinics and field sites lose the network, and a customer’s identity provider can be unreachable while everything local keeps working. Live now: the server half. A per-connection offline policy is set through the API, and sessions that already exist run to their configured lifetime during an outage. A fresh login is never possible while the provider is unreachable. Building now: the device half. A user who has already signed in on a device would keep working on a token sealed into that device, released only behind the device’s own unlock, for a window the customer sets. That window is the shortest delay the customer accepts on offboarding: a user disabled at their provider would keep working at least until it ends. The mobile SDK is not released, so no device enforces any of this. Scope is native mobile applications; browsers and progressive web apps are out.
The server half, through the API
The server half exists, and it is enforced on no device, because the mobile SDK is not released. You reach it through the API. No screen sets it, and RealmSSO does not present it as enforced policy.
A per-connection offline policy, set through the API
For each connection, you set an offline policy through the API. It holds whether offline is enabled, the longest window a device may run disconnected, and whether a device lock is required. The window and the device-lock setting reach a mobile client as signed claims. No device enforces them, because no released SDK reads them yet. Treat them as a contract waiting for its enforcer, not as live policy.
A window longer than the realm allows is refused
When you set the window, the API refuses a value longer than the realm allows. A realm is the separate sign-in space RealmSSO keeps for each account. The refusal happens when you set the window, not when a device later tries to use it.
During a provider outage, existing sessions run on
While a customer’s identity provider is unreachable, sessions that already exist run to their configured lifetime. A fresh login is never possible. Nothing can mint a new identity for a user while the only party able to vouch for that user cannot be reached. Offline operation never changes that.
Continuity on a device
We are building this now. None of it is available yet: the mobile SDK is not released, so no device does any of it. Each row says what would happen. If disconnected operation is the problem you have, tell us.
Continuity, never a fresh login
Offline here means one thing: the customer’s own identity provider is unreachable. The design would keep a user who is already signed in working, on a token that was issued and sealed while their provider was reachable. It would not sign anybody in. While the only party able to vouch for a user cannot be reached, nothing can honestly mint new identity for them — that is the cost of customers owning their own identity, and it is not a gap a later release closes.
The window is the customer’s to set
The customer would set how long a device may run disconnected, for each connection. There is no platform default: the risk being priced is theirs, so the number is theirs. The one bound is the realm’s: the API already refuses a window longer than the realm allows. The window is designed to be set deliberately. An unconfigured window does not mean a window with no end: it would mean offline is not configured, and offline would stay off.
The window is the customer’s offboarding latency
Stated plainly, because it is the first thing a security team asks: a user disabled at the customer’s provider would keep working offline at least until the window elapses. The check-in that reconnects the device is the only moment revocation would be re-evaluated, so the window the customer chooses is the shortest delay they accept on offboarding. The delay can be longer: the realm learns that a user was disabled at the provider only when something writes that change, and today only SCIM does. A short window means more frequent connectivity; a long one means longer-lived access after a departure. The design would make that trade explicit at the point where the number is set, rather than burying it in documentation.
Device unlock gates the sealed token
The token would be sealed into the device keystore and released only behind the operating system’s own unlock — biometric or device PIN. Possession of the enrolled device plus that unlock is what the customer would accept in place of a fresh challenge at their provider, for the length of the window and no longer. Neither would ever be presented to a server: the unlock would decide only whether the client uses the token it already holds. It would be a local gate the customer accepts, and nothing more than that — no challenge reaches the customer’s provider while their provider is unreachable, and this page will not pretend otherwise.
No device lock, no offline
If a device has no lock configured, it has nothing standing in for that challenge, so the design would refuse it offline rather than degrade quietly. Past the end of the window, the client is designed to stop and force an online sign-in, where the connection’s full provider-side authentication policy applies again.
Native applications only
Scope is native mobile applications, through an SDK RealmSSO would ship. Browsers and progressive web apps are excluded — not scheduled for later. The design depends on a hardware-backed key released only after an OS-verified unlock, and on storage that is not evicted; neither is something web platforms reliably provide today. That exclusion would be revisited only if both become genuinely available, and measured rather than assumed.
Talk to the people who build it.
We run RealmSSO for you. Tell us which identity providers your customers use and how many customers you have, and we will tell you what fits today.