---
title: "Authentification hébergée"
description: "Configurez le flux unifié de connexion et de création d’utilisateur."
locale: "fr"
---

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

# Authentification hébergée

## Flux unifié

XID ne propose pas de produits distincts pour l'inscription et la connexion des utilisateurs finaux. Hosted Auth commence par la même étape d'identification et choisit entre la connexion et la création d'un utilisateur selon la politique de la Organization et l'état du compte. Ensuite, un invité ou une inscription avec des identifiants et intent=sign-up crée un Tenant de premier niveau avec Email, Organization name et URL slug. L'Email de l'invité reste en attente sans réserver d'adresse de compte; le nouveau propriétaire peut lire les données de Console et vérifie cet Email avant la première modification métier. Le même Email dans un autre Tenant reste un compte distinct.

Les valeurs par défaut de démarrage activent uniquement le lien magique par e-mail et l'OTP par e-mail. Mot de passe, WhatsApp OTP, SMS OTP, clé d'accès, OAuth social et SSO entreprise restent masqués tant que la politique de l'organisation et les identifiants requis ne les activent pas.

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

## Point de terminaison de configuration

`GET /auth/config` renvoie la configuration publique de l'authentification hébergée pour l'organisation. Les secrets des fournisseurs et les fournisseurs désactivés ne sont pas renvoyés au navigateur.

| Méthode | Affiché lorsque |
| --- | --- |
| Lien magique | Activé et autorisé pour la connexion ou la création d'utilisateur. |
| OTP par e-mail | Activé et autorisé pour la connexion ou la création d'utilisateur. |
| OTP par téléphone | Le fournisseur WhatsApp ou SMS est configuré, activé et autorisé pour la connexion ou la création d'utilisateur. |
| Mot de passe | La politique de mot de passe active la connexion ou la création d'utilisateur. |
| OAuth social | Le fournisseur est activé, les identifiants existent et la politique autorise l'action. |
| SSO entreprise inbound | La découverte de domaine correspond à un domaine d'organisation vérifié. |

## Politique d'identifiants

- Les organisations peuvent exiger des identifiants e-mail, des identifiants utilisateur ou les deux.
- Les listes de domaines e-mail autorisés et bloqués s'appliquent avant la création d'utilisateur.
- Le SSO forcé masque les méthodes locales lorsqu'une connexion entreprise est requise.

## Limites WebAuthn et passkey

- La connexion par clé d’accès est l’authentification AAL2 principale. Les sessions mot de passe ou OTP peuvent terminer la MFA via `/auth/mfa/passkey/*` avec vérification utilisateur requise.
- La politique d’organisation `attestationMode` sélectionne aucune, indirecte ou directe attestation entreprise lors de l’enregistrement des clés d’accès.
- Les paramètres d’identifiants WebAuthn annoncent ES256, RS256 et EdDSA. Les clés d’accès synchronisables restent AAL2 même après MFA.
- `urn:xid:aal3` n’est émis que lorsque la MFA passkey répond à une assurance matérielle mono-appareil non sauvegardée. Les clés synchronisables ne qualifient pas pour AAL3.

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