Sessions

Part of Authio Lobby

Lobby’s SDK session helpers handle the parts of auth that aren’t the sign-in flow itself: token refresh, cookie storage, server-side JWT verification at the edge, kind-aware route gating, and the multi-org switch primitive.

Cookies and refresh

Sessions are stored in HttpOnly, Secure, SameSite=Lax cookies scoped to your custom domain. The refresh token rotates on every refresh; old refresh tokens are revoked atomically in a single transaction.

Read the cookie shape and refresh contract: Sessions and JWT/JWKS.

Edge-runtime JWT verification

The @authio/nextjs middleware verifies session JWTs at the edge with a cached JWKS. No round-trip to auth-core on the hot path. @authio/edge and @authio/cloudflare-workers wrap the same verifier for non-Next.js edge platforms.

Kind-aware route gating

Authio JWTs carry a kind claim: customer (your end-user sessions), platform (Authio HQ admin), and widget (P0-A widget tokens scoped to a single org). The SDK refuses any JWT whose kind doesn’t match the surface — so a leaked widget token can never authenticate a customer-tenant request, and a platform JWT can never reach a customer surface.

Silent refresh in the browser

When the access token nears expiry, the SDK calls /v1/sessions/refresh in the background and replaces the cookie atomically. No flash; no re-auth; no prompt. If the refresh fails (e.g. revoked, expired, or the org policy now requires step-up), the SDK redirects to the hosted UI with a return_to parameter so the user lands back where they were.

Lifetime + timeouts

Per-project access token TTL (default 1 hour, tunable down to minutes) and per-org policy timeouts: Session lifecycle and timeouts.