Autenticación alojada

Flujo unificado

XID no ofrece productos separados para el registro y el inicio de sesión de usuarios finales. Hosted Auth comienza en el mismo paso de identificación y decide entre iniciar sesión o crear un usuario según la política de la Organization y el estado de la cuenta. Después, un invitado o un registro con credenciales y intent=sign-up crea un Tenant de nivel superior con Email, Organization name y URL slug. La Email del invitado queda pendiente sin reservar una dirección de cuenta; el nuevo propietario puede leer los datos de Console y verifica esa Email antes del primer cambio de negocio. La misma Email en otro Tenant sigue siendo una cuenta separada.

Los valores iniciales habilitan solo enlace mágico por correo y OTP por correo. Contraseña, OTP de WhatsApp, OTP por SMS, llave de acceso, OAuth social y SSO empresarial permanecen ocultos hasta que la política de la organización y las credenciales requeridas los habiliten.

Las solicitudes sin contraseña mediante enlace mágico de correo electrónico y OTP fijan la intención de registro, la continuación controlada por el servidor, el cliente de aplicación y el ID de la fila de invitación al crear el desafío. La autorización de invitaciones de Social OAuth también valida la capacidad original antes de redirigir al proveedor externo, conserva solo el ID de la fila de invitación en su estado de un solo uso e ignora en el callback las rutas de token controladas por el cliente. La verificación no puede modificar estos campos. Las capacidades de invitación originales nunca se almacenan en estos contextos de flujo. Cuando MFA interrumpe la aceptación, XID usa una continuación firmada de corta duración vinculada al Tenant, usuario, sesión e invitación.

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

Punto de conexión de configuración

GET /auth/config devuelve la configuración pública de Hosted Auth para la organización. Los secretos de proveedores y los proveedores deshabilitados no se devuelven al navegador.

Política de identificadores

• Las organizaciones pueden requerir identificadores de correo, identificadores de usuario o ambos.
• Las listas de dominios de correo permitidos y bloqueados se aplican antes de crear usuarios.
• El SSO forzado oculta los métodos locales cuando se requiere una conexión empresarial.

Límites de WebAuthn y passkey

• El inicio de sesión con passkey es la autenticación AAL2 principal. Las sesiones con contraseña u OTP pueden completar MFA mediante /auth/mfa/passkey/* con verificación de usuario requerida.
• La política de organización attestationMode selecciona atestación empresarial ninguna, indirecta o directa durante el registro de passkey.
• Los parámetros de credenciales WebAuthn anuncian ES256, RS256 y EdDSA. Las passkeys sincronizables siguen siendo AAL2 incluso después de MFA.
• urn:xid:aal3 no se emite actualmente. Los indicadores UV y BE/BS de WebAuthn no demuestran la clave de hardware no exportable exigida por NIST. Las solicitudes AAL3 fallan explícitamente y la asignación máxima actual es AAL2.