Comment ajouter une connexion à votre app : mots de passe, liens magiques, Google et rôles

Pour ajouter une connexion à une app, choisissez une méthode — e-mail et mot de passe, liens magiques (un lien de connexion à usage unique envoyé par e-mail), ou « Se connecter avec Google » — et implémentez-la avec une bibliothèque d'authentification éprouvée ou un fournisseur hébergé, plutôt que de tout écrire à partir de zéro. Décidez ensuite ce que chaque type d'utilisateur peut faire (les rôles), et appliquez-le côté serveur pour chaque page et chaque requête API. Les sessions doivent utiliser des cookies sécurisés, expirer, et se terminer correctement à la déconnexion.

Ce guide détaille chaque choix et les points qui distinguent une connexion fonctionnelle d'une connexion sûre. Pour les concepts sous-jacents, voir qu'est-ce que l'authentification.

À décider d'abord : avez-vous vraiment besoin d'une connexion ?

La connexion ajoute de la friction et des responsabilités. Vous en avez besoin lorsque :

• Les utilisateurs ont des données privées (leurs réservations, documents, factures)
• Les utilisateurs peuvent modifier des éléments que d'autres verront
• Vous faites payer l'accès
• Différentes personnes ont besoin de permissions différentes (propriétaire, collaborateur, client)

Vous n'en avez peut-être pas besoin pour un site marketing, un annuaire public ou un formulaire qui vous envoie simplement un e-mail. Une liste d'attente n'a pas besoin de comptes ; un champ e-mail suffit.

Les quatre méthodes de connexion courantes

De nombreuses apps combinent deux méthodes : la connexion Google plus les liens magiques par e-mail est une association populaire qui couvre la plupart des personnes sans stocker aucun mot de passe.

E-mail et mot de passe

Si vous proposez des mots de passe, ces points ne sont pas négociables :

• Hachez les mots de passe avec un algorithme de hachage lent. Les recommandations de stockage de l'OWASP privilégient Argon2id, avec scrypt, bcrypt ou PBKDF2 comme alternatives. Ne stockez jamais de mots de passe en clair ni avec un hachage général rapide.
• La réinitialisation des mots de passe utilise un lien aléatoire, à usage unique et à expiration, envoyé à l'adresse e-mail vérifiée.
• Ne révélez pas quelles adresses ont un compte. « Si cette adresse est enregistrée, nous avons envoyé un lien de réinitialisation » vaut mieux que « Aucun compte trouvé ».
• Limitez le débit des tentatives de connexion et de réinitialisation pour ralentir la devinette de mots de passe.
• Autorisez les mots de passe longs et les gestionnaires de mots de passe ; évitez les règles qui imposent des combinaisons de caractères bizarres.

Liens magiques et codes à usage unique

Un lien magique est un lien de connexion envoyé par e-mail à l'utilisateur. Cliquer dessus le connecte. Un code à usage unique repose sur le même principe, mais se saisit au lieu de se cliquer.

• Les liens et les codes expirent rapidement et ne fonctionnent qu'une seule fois.
• Le lien doit connecter l'utilisateur sur l'appareil où il a cliqué, et le jeton ne doit pas rester dans les journaux ni dans les outils d'analytics.
• Vous avez besoin d'un envoi d'e-mails fiable — voir comment envoyer des e-mails depuis votre app. Testez avec Gmail et Outlook, et vérifiez les dossiers spam.

Se connecter avec Google (et autres fournisseurs OAuth)

« Se connecter avec Google » utilise OAuth et OpenID Connect : Google confirme l'identité de l'utilisateur et transmet à votre app son e-mail et son nom. La configuration, à la date de septembre 2026, se fait dans la section Google Auth Platform de la console Google Cloud :

1. Créez ou sélectionnez un projet, puis renseignez la page Branding — ce que voient les utilisateurs sur l'écran de consentement (nom de l'app, e-mail d'assistance, logo).
2. Sur la page Clients, créez un client de type « Application web ».
3. Ajoutez vos origines JavaScript autorisées et vos URI de redirection — les adresses exactes sur lesquelles votre app fonctionne et vers lesquelles Google renvoie les utilisateurs après la connexion.
4. Stockez l'ID client et le secret client dans les secrets de votre app.

Les problèmes fréquents, selon la documentation OAuth de Google :

• redirect_uri_mismatch : l'adresse de redirection doit correspondre exactement, y compris http ou https, les majuscules et une éventuelle barre oblique finale. Ajoutez-en une pour votre adresse d'aperçu et une pour votre domaine en ligne.
• HTTPS obligatoire : les URI de redirection doivent utiliser HTTPS, sauf localhost pendant le développement.
• Le paramètre state doit être vérifié au retour pour protéger contre la falsification de requête inter-sites. Les bonnes bibliothèques le font pour vous.

Si vous ne demandez que les informations de connexion de base (nom, e-mail, profil), Google indique que la vérification de l'app n'est pas obligatoire. Demander l'accès au Gmail, au Drive ou à l'agenda des utilisateurs est différent et exige une vérification.

Créer soi-même ou utiliser un fournisseur ?

Les deux premières options sont raisonnables. Les fournisseurs hébergés prennent en charge davantage de choses, mais ajoutent une dépendance et facturent parfois par utilisateur actif ; vérifiez les tarifs actuels sur leurs sites. Les bibliothèques conservent tout dans votre base, mais vous laissent davantage à configurer correctement. Quelle que soit votre option, demandez à l'IA de l'utiliser plutôt que de coder vous-même la logique des mots de passe ou des sessions.

Rôles et permissions

La connexion indique qui est une personne. Les permissions déterminent ce qu'elle peut faire. Restez simple au départ :

Les règles qui comptent davantage que les noms de rôles :

• Vérifiez côté serveur, à chaque fois. Masquer un bouton dans la page n'empêche pas quelqu'un d'appeler directement l'API.
• Limitez au propriétaire. Un membre qui demande « réservation 123 » ne doit l'obtenir que si elle lui appartient.
• Les utilisateurs ne peuvent pas s'auto-promouvoir. Ignorez les champs de rôle envoyés par le navigateur lors des mises à jour de profil.
• Par défaut, aucun accès. Les nouvelles routes doivent exiger une connexion, sauf décision contraire de votre part.

Testez avec deux comptes : connectez-vous avec le premier, notez l'ID d'un enregistrement, connectez-vous avec le second et essayez de l'ouvrir. Notre checklist de sécurité contient le test complet.

Sécurité des sessions

Après la connexion, l'app mémorise l'utilisateur grâce à une session — généralement un cookie. Les recommandations de l'OWASP sur la gestion des sessions préconisent :

• Cookies de session définis avec Secure (HTTPS uniquement), HttpOnly (illisibles par les scripts de la page) et SameSite
• Un nouvel identifiant de session émis à la connexion, et à nouveau lorsque les privilèges changent
• Un délai d'inactivité et une durée de vie maximale absolue, appliqués côté serveur
• Une déconnexion qui met fin à la session côté serveur, et pas seulement qui supprime le cookie
• Sessions invalidées lorsqu'un utilisateur change son mot de passe

Stocker les jetons de connexion dans le localStorage du navigateur est courant dans les tutoriels, mais les expose à tout script qui s'exécute sur la page ; les cookies sécurisés constituent généralement un meilleur choix par défaut pour les apps web.

Un prompt qui couvre l'essentiel

Ajoute des comptes utilisateurs à cette app. Les utilisateurs peuvent s'inscrire et se connecter avec un e-mail et un mot de passe, ou avec Google. Utilise [bibliothèque ou fournisseur] plutôt que du code d'authentification sur mesure. Hache les mots de passe avec Argon2id ou bcrypt. Ajoute une réinitialisation de mot de passe par e-mail avec un lien à usage unique qui expire au bout d'une heure. Garde les sessions dans des cookies sécurisés et HttpOnly. Protège /dashboard et toutes les routes /api pour que seuls les utilisateurs connectés puissent les utiliser, et assure-toi que chaque utilisateur ne voit que ses propres projets. Ajoute un rôle « admin » qui peut voir tous les utilisateurs ; seuls les admins peuvent accéder à /admin, vérifié côté serveur.

Puis testez : inscrivez-vous, déconnectez-vous, reconnectez-vous, réinitialisez le mot de passe, essayez une URL privée en étant déconnecté, et essayez l'enregistrement d'un autre utilisateur.

Erreurs courantes dans une connexion créée avec l'IA

• Protection uniquement dans la page. La page redirige les utilisateurs déconnectés, mais l'API renvoie les données à n'importe qui.
• Des secrets dans le navigateur. Les secrets clients OAuth et les clés d'administration du fournisseur d'authentification doivent rester sur le serveur.
• Confusion entre URL d'aperçu et URL en ligne. L'URI de redirection de Google ou le lien de réinitialisation par e-mail pointe vers l'aperçu, et la connexion casse après publication.
• Aucune vérification de l'e-mail. N'importe qui peut s'inscrire en tant que anyone@company.com. Vérifiez l'e-mail avant d'accorder quoi que ce soit lié à cette adresse.
• Ne tester que le cas idéal. Essayez de mauvais mots de passe, des liens expirés et un second compte.

Ajouter une connexion dans Mythex

Dans Mythex, la connexion pour les utilisateurs de votre app est une fonctionnalité que vous ajoutez à votre app — elle est distincte de votre propre compte Mythex. Mythex ne fournit pas de produit d'authentification intégré : vous apportez donc une bibliothèque ou un fournisseur d'authentification et ses clés :

1. Choisissez une approche — par exemple e-mail et mot de passe stockés dans votre propre base, ou le SDK d'un fournisseur hébergé.
2. Si vous stockez vous-même les utilisateurs, l'app a besoin d'une base de données ; demandez-la dans le chat ou utilisez /database.
3. Placez les clés du fournisseur dans les secrets du projet (/secrets ou paramètres du projet).
4. Utilisez un prompt semblable à celui ci-dessus, puis testez dans l'aperçu. Pour la connexion Google, ajoutez des URI de redirection pour votre aperçu et pour votre adresse publiée.

Voir Ajouter une connexion à votre app dans la documentation. Si vous construisez un produit payant, comment créer un MVP SaaS couvre à la fois les comptes et la facturation.

Questions