Gehostete Authentifizierung

Einheitlicher Ablauf

XID stellt keine getrennten Produkte für Registrierung und Anmeldung von Endbenutzern bereit. Hosted Auth beginnt mit demselben Kennungsschritt und entscheidet anhand der Richtlinie der Organization und des Kontostatus über Anmeldung oder Benutzererstellung. Ein Gast oder eine Registrierung mit Zugangsdaten und intent=sign-up erstellt anschließend einen Top-Level Tenant mit Email, Organization name und URL slug. Die Email eines Gastes bleibt ausstehend, ohne eine Kontoadresse zu reservieren; der neue Eigentümer kann Console-Daten lesen und bestätigt diese Email vor der ersten geschäftlichen Änderung. Dieselbe Email in einem anderen Tenant bleibt ein separates Konto.

Initiale Standardwerte aktivieren nur magischen Link per E-Mail und E-Mail-OTP. Passwort, WhatsApp-OTP, SMS-OTP, Passkey, soziales OAuth und Enterprise SSO bleiben verborgen, bis Organisationsrichtlinie und erforderliche Zugangsdaten sie aktivieren.

Bei passwortlosen E-Mail-Magic-Link- und OTP-Anfragen werden die Registrierungsabsicht, die serverseitig kontrollierte Fortsetzung, der Anwendungsclient und die Einladungszeilen-ID beim Erstellen der Challenge festgeschrieben. Die Autorisierung einer Social-OAuth-Einladung validiert ebenso die ursprüngliche Berechtigung vor der Weiterleitung zum externen Anbieter, speichert in ihrem einmaligen Zustand nur die Einladungszeilen-ID und ignoriert beim Callback clientseitig kontrollierte Token-Routen. Die Verifizierung kann diese Felder nicht ändern. Ursprüngliche Einladungsberechtigungen werden nie in diesen Ablaufkontexten gespeichert. Wenn MFA die Annahme unterbricht, verwendet XID eine kurzlebige signierte Fortsetzung, die an Tenant, Benutzer, Sitzung und Einladung gebunden ist.

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

Konfigurationsendpunkt

GET /auth/config gibt die öffentliche Konfiguration der Hosted Auth für die Organisation zurück. Anbieter-Geheimnisse und deaktivierte Anbieter werden nicht an den Browser zurückgegeben.

Methode	Angezeigt wenn
Magischer Link	Aktiviert und für Anmeldung oder Benutzererstellung erlaubt.
E-Mail-OTP	Aktiviert und für Anmeldung oder Benutzererstellung erlaubt.
Telefon-OTP	WhatsApp- oder SMS-Anbieter ist konfiguriert, aktiviert und für Anmeldung oder Benutzererstellung erlaubt.
Passwort	Passwortrichtlinie aktiviert Anmeldung oder Benutzererstellung.
Soziales OAuth	Anbieter ist aktiviert, Zugangsdaten existieren, und die Richtlinie erlaubt die Aktion.
Inbound Enterprise SSO	Domain-Erkennung gleicht eine verifizierte Organisationsdomain ab.

Kennungsrichtlinie

Organisationen können E-Mail-Kennungen, Benutzernamen-Kennungen oder beides verlangen.
Listen erlaubter und blockierter E-Mail-Domains werden vor der Benutzererstellung angewendet.
SSO-Erzwingung blendet lokale Methoden aus, wenn eine Enterprise-Verbindung erforderlich ist.

WebAuthn- und Passkey-Grenzen

Passkey-Anmeldung ist die primäre AAL2-Authentifizierung. Passwort- oder OTP-Sitzungen können MFA über /auth/mfa/passkey/* mit erforderlicher Benutzerverifizierung abschließen.
Die Organisationsrichtlinie attestationMode wählt bei der Passkey-Registrierung keine, indirekte oder direkte Enterprise-Attestierung.
WebAuthn-Credential-Parameter bewerben ES256, RS256 und EdDSA. Synchronisierbare Passkeys bleiben auch nach MFA AAL2.
urn:xid:aal3 wird derzeit nicht ausgestellt. WebAuthn UV sowie die BE/BS-Flags belegen nicht den von NIST geforderten, nicht exportierbaren Hardwareschlüssel. AAL3-Anfragen schlagen ausdrücklich fehl; die derzeit höchste Zuordnung ist AAL2.