---
title: "Hosted Auth"
description: "Configure the unified sign-in and user creation flow."
locale: "en"
---

> Documentation Index
> Fetch the locale documentation index at: https://xid.dev/en/llms.txt
> Use this file to discover all available pages before exploring further.

# Hosted Auth

## Unified flow

XID does not expose separate end-user registration and login products. Hosted Auth starts from the same identifier step and decides login or user creation from organization policy and account state. A guest or credential sign-up with intent=sign-up then creates a top-level Tenant with an Email, Organization name, and URL slug. A guest Email stays pending without reserving an account address; the new owner can read Console data, and verifies that Email before the first business change. The same Email in another Tenant remains a separate account.

Bootstrap defaults enable email magic link and email OTP only. Password, WhatsApp OTP, SMS OTP, passkey, social OAuth, and enterprise SSO stay hidden until the organization policy and required credentials enable them.

```mermaid
flowchart TD
  Browser --> authorize["/authorize"]
  authorize --> signIn["/sign-in"]
  signIn --> config["/auth/config"]
  config --> methods["WebAuthn / Password / OTP / SSO"]
  config --> signup["guest or intent=sign-up"]
  signup --> createOrg["/create-organization"]
  createOrg --> readOnly["Console reads"]
  readOnly --> verifyEmail["Verify Email"]
  verifyEmail --> mutations["Business mutations"]
  methods --> code["code"]
  methods --> mfa["/auth/mfa/passkey/*"]
  mfa --> code
```

## Configuration endpoint

`GET /auth/config` returns the public Hosted Auth configuration for the organization. Provider secrets and disabled providers are not returned to the browser.

| Method | Displayed when |
| --- | --- |
| Magic link | Enabled and allowed for login or user creation. |
| Email OTP | Enabled and allowed for login or user creation. |
| Phone OTP | WhatsApp or SMS provider is configured, enabled, and allowed for login or user creation. |
| Password | Password policy enables login or user creation. |
| Social OAuth | Provider is enabled, credentials exist, and policy allows the action. |
| Inbound enterprise SSO | Domain discovery matches a verified organization domain. |

## Identifier policy

- Organizations can require email identifiers, username identifiers, or both.
- Allowed and blocked email domain lists apply before user creation.
- Force SSO hides local methods when an enterprise connection is required.

## WebAuthn and passkey boundaries

- Passkey sign-in is primary AAL2 authentication. Password or OTP sessions can complete MFA through `/auth/mfa/passkey/*` with user verification required.
- Organization policy `attestationMode` selects none, indirect, or direct enterprise attestation during passkey registration.
- WebAuthn credential parameters advertise ES256, RS256, and EdDSA. Syncable passkeys remain AAL2 even after MFA.
- `urn:xid:aal3` is issued only when passkey MFA meets hardware single-device, non-backed-up assurance. Syncable passkeys do not qualify for AAL3.

Source: https://xid.dev/hosted-auth/index.mdx