Where hosted authentication should stop

Hosted authentication removes sensitive login code from each customer application. That benefit weakens when the hosted page also accepts arbitrary scripts, redirects, and theme code. ZKAuth keeps customization inside a smaller contract.

ZKAuth hosted pages are built with that line in mind. The project can enable or disable hosted entry points, set bounded branding, and configure where verified users are allowed to return. It cannot inject custom JavaScript into the hosted login surface, widen the Content Security Policy by accident, or redirect users to a URL that was never allowlisted.

{  "hostedPagesEnabled": true,  "primaryRedirectUrl": "https://app.example.com/auth/callback",  "allowedRedirectUrls": [    "https://app.example.com/auth/callback",    "https://staging.example.com/auth/callback"  ],  "allowedBrowserOrigins": [    "https://app.example.com",    "https://staging.example.com"  ]}

The callback is part of authentication

A hosted auth page is only as safe as its handoff. If a verification link or hosted sign-in can bounce to any URL, the auth provider has become an open redirect with better typography. ZKAuth stores exact redirect URLs and exact browser origins per project, then validates requests against those lists before completing the flow.

The dashboard accepts no wildcard domains, query-string shortcuts, or path guessing. Production and staging can both be configured, but each destination remains visible and reviewable.

Branding cannot become page code

Projects can select a logo and bounded visual tokens while retaining the hosted layout and Content Security Policy. They cannot inject custom JavaScript into the page that asks a user to authenticate. This keeps visual identity separate from execution authority.

What hosted auth does today

• Project-hosted sign-in, sign-up, password recovery, reset, and passkey helper pages.
• Bounded logo and color branding that keeps the secure ZKAuth layout and CSP intact.
• Runtime controls for enabling hosted pages and individual hosted entry points.
• Callback and browser-origin allowlists for verification, recovery, device approval, and handoff flows.

Project keys stay outside the browser

Hosted pages and application-owned proxy routes exist partly so a browser never needs the project API key. The key authenticates one project environment to the engine; it does not represent the person signing in. Exposing it to the browser would collapse those two trust boundaries.

Current coverage and missing account-management features are listed on the limitations page so teams can evaluate the hosted path before integration.