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

Pour ajouter une connexion à une application, choisissez une méthode (courriel et mot de passe, liens magiques, c'est-à-dire un lien de connexion unique envoyé par courriel, 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 vous-même. Décidez ensuite ce que chaque type d'utilisateur peut faire (rôles), et faites-le respecter sur le serveur pour chaque page et chaque requête d'API. Les sessions doivent utiliser des témoins sécurisés, expirer, et se terminer correctement à la déconnexion.

Ce guide parcourt chaque choix et les détails qui distinguent une connexion qui fonctionne d'une connexion sûre. Pour les concepts sous-jacents, consultez qu'est-ce que l'authentification.

Décidez 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, leurs documents, leurs factures)
• Les utilisateurs peuvent modifier des choses que d'autres verront
• Vous facturez l'accès
• Différentes personnes ont besoin de permissions différentes (propriétaire, employé, client)

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

Les quatre méthodes de connexion courantes

Beaucoup d'applications combinent deux méthodes : la connexion Google plus les liens magiques par courriel est un duo populaire qui couvre la plupart des gens sans stocker de mots de passe.

Courriel et mot de passe

Si vous proposez des mots de passe, ces éléments sont non négociables :

• Hachez les mots de passe avec un algorithme de hachage lent. Les directives de l'OWASP sur le stockage des mots de passe recommandent Argon2id, avec scrypt, bcrypt ou PBKDF2 comme alternatives. Ne stockez jamais les mots de passe en clair ni avec un hachage rapide et général.
• Les réinitialisations utilisent un lien aléatoire, à usage unique et qui expire, envoyé à l'adresse courriel vérifiée.
• Ne révélez pas quels courriels ont un compte. « Si ce courriel est enregistré, 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 les devinettes de mots de passe.
• Autorisez les longs mots de passe et les gestionnaires de mots de passe; abandonnez 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 courriel à l'utilisateur. Cliquer dessus le connecte. Un code à usage unique est la même idée, mais saisi au lieu d'être cliqué.

• Les liens et les codes expirent rapidement et ne fonctionnent qu'une 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 de statistiques.
• Vous avez besoin d'un envoi de courriels fiable; voir comment envoyer des courriels depuis votre application. Testez avec Gmail et Outlook, et vérifiez les dossiers de pourriels.

Se connecter avec Google (et autres fournisseurs OAuth)

« Se connecter avec Google » utilise OAuth et OpenID Connect : Google confirme qui est l'utilisateur et transmet à votre application son courriel et son nom. La configuration, en septembre 2026, se fait dans la section Google Auth Platform de la console Google Cloud :

1. Créez ou sélectionnez un projet, puis remplissez la page Image de marque : ce que voient les utilisateurs sur l'écran de consentement (nom de l'application, courriel de soutien, 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, c'est-à-dire les adresses exactes où votre application s'exécute et où Google renvoie les utilisateurs après la connexion.
4. Enregistrez l'identifiant client et le secret client dans les secrets de votre application.

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 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 vous protéger contre la falsification de requête intersite. Les bonnes bibliothèques le font pour vous.

Si vous ne demandez que les renseignements de base de connexion (nom, courriel, profil), Google indique que la vérification de l'application 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.

Construire ou utiliser un fournisseur?

Les deux premières options sont raisonnables. Les fournisseurs hébergés en font davantage pour vous, mais ajoutent une dépendance et coûtent parfois selon le nombre d'utilisateurs actifs; vérifiez les tarifs actuels sur leurs sites. Les bibliothèques gardent tout dans votre base de données, mais vous laissent plus à configurer correctement. Quel que soit votre choix, demandez à l'IA d'utiliser ce dernier plutôt que de recoder 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. Gardez cela simple au début :

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

• Vérifiez sur le serveur, à chaque fois. Cacher un bouton dans la page n'empêche pas quelqu'un d'appeler directement l'API.
• Limitez par propriétaire. Un membre qui demande « réservation 123 » ne doit l'obtenir que si elle lui appartient.
• Les utilisateurs ne peuvent pas se promouvoir eux-mêmes. 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 l'un, notez l'identifiant d'un dossier, puis connectez-vous avec l'autre et essayez de l'ouvrir. Notre liste de contrôle de sécurité contient le test complet.

Sécurité des sessions

Après la connexion, l'application reconnaît l'utilisateur grâce à une session, généralement un témoin. Les directives de l'OWASP sur la gestion des sessions recommandent :

• Des témoins de session 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
• Une expiration après inactivité et une durée de vie maximale absolue, appliquées sur le serveur
• Une déconnexion qui termine la session sur le serveur, et non seulement qui supprime le témoin
• Des sessions invalidées quand un utilisateur change son mot de passe

Stocker les jetons de connexion dans le stockage local du navigateur est courant dans les tutoriels, mais cela les expose à tout script qui s'exécute sur la page; des témoins sécurisés sont généralement le meilleur choix par défaut pour les applications web.

Une consigne qui couvre l'essentiel

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

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

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

• Une protection seulement 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 les URL d'aperçu et en ligne. L'URI de redirection de Google ou le lien de réinitialisation du courriel pointe vers l'aperçu, donc la connexion casse après la publication.
• Aucune vérification du courriel. N'importe qui peut s'inscrire comme anyone@entreprise.com. Vérifiez le courriel avant d'accorder quoi que ce soit lié à cette adresse.
• Ne tester que le cas idéal. Essayez les mots de passe erronés, les liens expirés et un second compte.

Ajouter une connexion dans Mythex

Dans Mythex, la connexion pour les utilisateurs de votre application est quelque chose que vous ajoutez à votre application; elle est distincte de votre propre compte Mythex. Mythex n'offre 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 courriel et mot de passe stockés dans votre propre base de données, ou le SDK d'un fournisseur hébergé.
2. Si vous stockez vous-même les utilisateurs, l'application a besoin d'une base de données; demandez-la dans le clavardage ou utilisez /database.
3. Mettez les clés du fournisseur dans les secrets du projet (/secrets ou les paramètres du projet).
4. Utilisez une consigne comme celle ci-dessus, puis testez dans l'aperçu. Pour la connexion Google, ajoutez des URI de redirection pour votre aperçu et votre adresse en ligne.

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

Questions