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.

Les demandes sans mot de passe par lien magique e-mail et OTP figent l’intention d’inscription, la continuation contrôlée par le serveur, le client d’application et l’identifiant de la ligne d’invitation lors de la création du défi. L’autorisation d’une invitation Social OAuth valide également la capacité brute avant la redirection vers le fournisseur externe, ne conserve que l’identifiant de la ligne d’invitation dans son état à usage unique et ignore au callback les routes de jeton contrôlées par le client. La vérification ne peut pas modifier ces champs. Les capacités d’invitation brutes ne sont jamais stockées dans ces contextes de flux. Lorsque la MFA interrompt l’acceptation, XID utilise une continuation signée de courte durée liée au Tenant, à l’utilisateur, à la session et à l’invitation.

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.

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 pas émis actuellement. Les indicateurs UV et BE/BS de WebAuthn ne démontrent pas la présence de la clé matérielle non exportable exigée par NIST. Les requêtes AAL3 échouent explicitement et le niveau maximal actuellement associé est AAL2.