Mailmus
Auth

Connexion par téléphone (SMS)

OTP par SMS — zéro compte fournisseur à créer côté développeur, testable sur Free avec votre propre numéro.

Comme pour l'email, Mailmus génère et vérifie lui-même le code à 6 chiffres — le SMS n'est qu'un transport. Aucun compte fournisseur SMS à créer ou configurer de votre côté : Mailmus héberge et facture l'envoi.

Pourquoi un comportement différent selon le palier

Contrairement à l'email (quasi gratuit) et à OAuth (aucun coût par connexion), le SMS a un vrai coût par message envoyé.

  • Palier Pro : PHONE_CODE fonctionne sans restriction, vers n'importe quel numéro.
  • Palier Free : PHONE_CODE est activable, mais les envois sont restreints à un unique numéro de test, que vous vérifiez vous-même depuis le dashboard — voir ci-dessous. C'est pensé pour tester le flow en conditions réelles avant de passer en production, pas pour servir de vrais utilisateurs finaux.

Activer

App → Authentification → Méthodes de connexion, activez "SMS / code par téléphone".

Numéro de test (palier Free)

Une fois PHONE_CODE activé sur une app Free, une carte "Numéro de test (palier Free)" apparaît dans les réglages Auth :

  1. Entrez votre propre numéro et cliquez "Envoyer le code" — vous recevez un SMS avec un code à 6 chiffres.
  2. Entrez ce code pour vérifier le numéro.

Une fois vérifié, requestPhoneOtp/verifyPhoneOtp (SDK ou API brute) ne fonctionnent que vers ce numéro — toute autre demande échoue avec 403 "Palier Free : seul le numéro de test vérifié peut recevoir un code...". Cette vérification passe uniquement par le dashboard authentifié, jamais par l'API publique de sign-up — un visiteur anonyme de votre app ne peut donc pas s'en servir pour se faire envoyer des SMS gratuits.

Contraintes du numéro de test :

  • Modifiable jusqu'à 3 fois après la vérification initiale (4 vérifications au total), puis verrouillé jusqu'au passage au palier Pro.
  • Plafonné à 20 envois par mois, indépendamment du throttle standard des routes publiques.

Passez au palier Pro pour lever ces deux restrictions et ouvrir PHONE_CODE à vos utilisateurs finaux.

SDK navigateur

// 1. Demande un code — envoyé par SMS.
await auth.requestPhoneOtp({ phone: "+33612345678" }); // Format E.164 obligatoire ("+" requis)

// 2. Vérifie le code saisi par l'utilisateur.
const result = await auth.verifyPhoneOtp({ phone: "+33612345678", code: "123456" });

if (isMfaChallenge(result)) {
  // Comme pour tout autre provider — MFA s'applique aussi au téléphone.
  const { endUser } = await auth.mfa.verify({ challengeToken: result.challengeToken, code: "654321" });
} else {
  console.log(result.endUser);
}

Même contrat que requestOtp/verifyOtp (email) : requestPhoneOtp ne renvoie rien (fire-and-forget), verifyPhoneOtp renvoie soit une session, soit un défi MFA.

Avec @mailmus/auth-react / @mailmus/auth-react-native

<SignIn>/<SignUp> détectent automatiquement PHONE_CODE dans la config de l'App et ajoutent le mode SMS aux méthodes disponibles — aucun code supplémentaire à écrire, même défi MFA géré en interne que pour les autres providers.

Suivant

On this page