---
title: "Gehostete Authentifizierung"
description: "Konfigurieren Sie den einheitlichen Anmelde- und Benutzererstellungsablauf.Benutzererstellung."
locale: "de"
---

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

# 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.

```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
```

## 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 nur ausgestellt, wenn Passkey-MFA Hardware-Einzelgerät- und Nicht-Backup-Sicherheit erfüllt. Synchronisierbare Passkeys qualifizieren nicht für AAL3.

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