Connexion sans mot de passe

Lien magique et code e-mail à usage unique : courte durée de vie, protection contre l'énumération, et opt-in par organisation.

La connexion sans mot de passe permet à un utilisateur de s'authentifier par la preuve de possession de sa boîte e-mail plutôt que par un mot de passe. Obexal propose deux méthodes, toutes deux en opt-in par organisation et toutes deux soumises aux mêmes règles MFA que n'importe quel facteur primaire.

Le fonctionnement

Dans les deux cas, le serveur ne stocke qu'un hachage du token ou du code, jamais la valeur brute, et le consomme atomiquement à la vérification : un lien ou un code ne sert exactement qu'une fois.

Activer pour votre organisation

La connexion sans mot de passe est coupée par défaut et fail-closed : tant que votre organisation ne l'a pas explicitement activée, les requêtes start sont refusées avec 403 passwordless_disabled (une réponse de politique qui ne révèle rien sur les comptes).

• Console : ouvrez les réglages de votre organisation et activez l'interrupteur « Autoriser la connexion sans mot de passe ».
• API : l'interrupteur est la clé allowPasswordless de l'objet branding de l'organisation. Lisez d'abord l'objet courant, puis renvoyez-le mis à jour :

# Lire l'objet branding courant.
curl -sS https://accounts.obexal.com/v1/admin/tenant \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN"

# Le renvoyer avec allowPasswordless à true.
curl -sS -X PATCH https://accounts.obexal.com/v1/admin/tenant \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" -H 'Content-Type: application/json' \
  -d '{"branding":{"allowPasswordless":true}}'

Demander un lien ou un code

curl -sS -X POST https://accounts.obexal.com/v1/auth/passwordless/start \
  -H "X-CSRF-Token: $CSRF" -H 'Content-Type: application/json' \
  -d '{"email":"a@b.eu","method":"link"}'
# 202 -> {"status":"ok"}

method vaut link (défaut) ou otp. La réponse est toujours 202, que le compte existe ou non : si l'adresse est inconnue, inactive ou mal formée, rien n'est envoyé et la réponse est identique (anti-énumération). Les requêtes sont limitées en débit par adresse e-mail et par IP (429 rate_limited).

Le lien magique pointe vers l'interface de connexion hébergée (/passwordless/verify?token=...), qui soumet le token pour vous.

Vérifier et se connecter

La vérification prend soit le token du lien, soit l'e-mail et le code :

# Lien magique.
curl -sS -X POST https://accounts.obexal.com/v1/auth/passwordless/verify \
  -H "X-CSRF-Token: $CSRF" -H 'Content-Type: application/json' \
  -d '{"token":"dGhpc0lzVGhlVG9rZW4..."}'

# Ou code e-mail.
curl -sS -X POST https://accounts.obexal.com/v1/auth/passwordless/verify \
  -H "X-CSRF-Token: $CSRF" -H 'Content-Type: application/json' \
  -d '{"email":"a@b.eu","code":"429188"}'
# 200 -> {"user":{...}} et le cookie de session est posé

Tout échec (token invalide, expiré, déjà utilisé, tentatives épuisées) renvoie le même 401 invalid_or_expired générique. Deux effets de bord en cas de succès :

• L'adresse e-mail est marquée vérifiée : une connexion sans mot de passe prouve la possession de la boîte.
• Si le compte a un facteur MFA actif, aucune session n'est ouverte ; vous recevez {"mfaRequired":true,"mfaToken":"...",...} à compléter via le point de passage MFA, comme tout facteur primaire.

Le modèle de sécurité

• Opt-in, fail-closed : désactivé tant que branding.allowPasswordless de l'organisation ne vaut pas explicitement true ; un réglage absent ou mal formé signifie coupé.
• Haché au repos : tokens et codes sont stockés hachés et consommés au premier usage.
• Courte durée de vie : 15 minutes pour les liens, 10 minutes pour les codes.
• Anti-énumération : start répond toujours 202 ; verify échoue toujours avec la même erreur générique.
• Limité en débit : par e-mail et par IP sur start, par IP sur verify.
• MFA préservée : le sans mot de passe est un facteur primaire et ne contourne jamais un second facteur enrôlé. Pour une alternative résistante au phishing et sans aller-retour e-mail, voyez les passkeys.