Qu'est-ce que l'authentification ? Connexions, sessions et OAuth expliqués

L'authentification permet à une appli de confirmer qui est un utilisateur — en général en vérifiant quelque chose qu'il connaît (un mot de passe), quelque chose qu'il possède (un code envoyé sur son téléphone ou par e-mail) ou une identité fournie par un autre service de confiance (comme « Se connecter avec Google »). Une fois l'utilisateur authentifié, l'appli le reconnaît grâce à une session ou à un jeton, pour qu'il n'ait pas à se reconnecter à chaque page. Décider de ce que cet utilisateur connu a le droit de faire est une étape distincte, appelée autorisation.

Pourquoi c'est important quand on construit avec l'IA

Ajouter une connexion fait partie des demandes les plus fréquentes adressées à un créateur d'applis par IA, et l'une des plus faciles à mal faire. Une page de connexion est simple à générer. La partie difficile, c'est tout ce qui l'entoure :

• Les mots de passe sont-ils stockés de façon sûre ?
• Chaque page privée et chaque point de terminaison d'API vérifie-t-il vraiment qui fait la demande ?
• Un client connecté peut-il voir les données d'un autre client en modifiant un numéro dans l'URL ?
• Que se passe-t-il quand quelqu'un oublie son mot de passe ?

Une appli peut paraître parfaitement sûre tout en échouant sur chacun de ces points. Comprendre les rouages permet de poser les bonnes questions et de tester les bonnes choses.

Une analogie du quotidien

Pensez à l'enregistrement dans un hôtel.

À la réception, vous montrez une pièce d'identité. C'est l'authentification : prouver qui vous êtes. Le réceptionniste vous remet ensuite une carte magnétique. Cette carte est votre session : pendant tout votre séjour, vous n'avez plus à montrer de pièce d'identité ; vous passez la carte.

La carte ouvre votre chambre, la salle de sport et l'ascenseur de votre étage — mais pas les chambres des autres clients ni le bureau du personnel. C'est l'autorisation : à quoi votre identité a le droit d'accéder. Si vous perdez la carte, l'hôtel peut la désactiver à la réception (révoquer une session). Au départ, elle cesse de fonctionner (déconnexion, ou expiration).

« Se connecter avec Google », c'est comme un hôtel qui accepte une lettre d'un partenaire de confiance disant « voici qui est cette personne », au lieu de vérifier votre pièce d'identité lui-même.

Les principales méthodes de connexion

Comment les mots de passe doivent être stockés

Une appli sûre ne stocke jamais votre mot de passe réel. Elle stocke un hachage : le résultat d'une fonction à sens unique qui transforme le mot de passe en une chaîne de longueur fixe. Quand vous vous connectez, l'appli hache ce que vous avez tapé et compare le résultat au hachage stocké.

Deux détails rendent cela sûr :

• Un sel — une valeur aléatoire ajoutée à chaque mot de passe avant le hachage, pour que deux personnes ayant le même mot de passe obtiennent des hachages différents et que les tables de correspondance précalculées soient inutiles.
• Un algorithme lent conçu pour les mots de passe — comme Argon2, bcrypt ou scrypt. Les hachages généralistes comme MD5 ou SHA-256 sont bien trop rapides : un attaquant peut tester des milliards de suppositions.

Le hachage n'est pas le chiffrement. Une donnée chiffrée peut être déchiffrée avec une clé ; un hachage de mot de passe est conçu pour ne pas être réversible du tout.

Sessions ou jetons

Après la connexion, l'appli doit vous reconnaître à chaque requête. Il existe deux approches courantes.

Pour les cookies, trois réglages comptent : HttpOnly (le JavaScript de la page ne peut pas lire le cookie), Secure (envoyé uniquement en HTTPS) et SameSite (limite l'envoi lors de requêtes provenant d'autres sites). Stocker des jetons dans le localStorage du navigateur est courant, mais cela les expose à tout script qui s'exécute sur la page.

OAuth et « Se connecter avec Google »

OAuth 2.0 est une norme d'autorisation déléguée : elle permet à une appli d'obtenir un accès limité à votre compte sur un autre service — par exemple lire votre Google Agenda — sans jamais voir votre mot de passe Google. Vous êtes redirigé vers Google, vous approuvez des permissions précises (appelées scopes), et Google donne à l'appli un jeton pour ces seules permissions.

À l'origine, OAuth a été conçu pour accorder un accès, et non pour dire qui vous êtes. OpenID Connect (OIDC) est une couche ajoutée à OAuth 2.0 qui apporte l'identité, et c'est ce qu'utilisent « Se connecter avec Google » ou « Se connecter avec Apple ». Pour le configurer, vous enregistrez votre appli auprès du fournisseur et obtenez un identifiant client et un secret client ; le secret reste sur votre serveur.

Un exemple concret : connexion pour un portail client

Imaginons que vous construisez un portail où les clients d'une agence de design voient leurs projets et leurs factures.

• Authentification : les clients se connectent avec leur e-mail et un lien magique, il n'y a donc aucun mot de passe à gérer. Le personnel de l'agence se connecte avec des comptes Google Workspace.
• Rôles : chaque utilisateur a un rôle — client ou staff.
• Règles d'autorisation :

• Où c'est appliqué : côté serveur, pour chaque requête. Le serveur recherche l'utilisateur connecté, puis ne renvoie que les projets où project.company_id correspond à l'entreprise de l'utilisateur. Masquer le bouton « Marquer payée » ne suffit pas — le point de terminaison lui-même doit refuser.

Termes courants expliqués

Erreurs courantes et idées reçues

• Vérifier les permissions uniquement dans la page. Si le navigateur masque un bouton mais que l'API ne vérifie rien, n'importe qui peut appeler l'API directement.
• Faire confiance aux identifiants présents dans l'URL. /invoices/1042 doit vérifier que la facture 1042 appartient à l'utilisateur connecté.
• Inventer sa propre cryptographie. Utilisez des bibliothèques connues ou des fournisseurs reconnus ; ne laissez pas l'IA inventer un schéma de hachage.
• Réinitialisation de mot de passe faible. Les liens de réinitialisation doivent être à usage unique, expirer rapidement et ne pas révéler si un e-mail correspond à un compte.
• Confondre votre connexion avec celle de votre outil de création. Les utilisateurs de votre appli sont distincts de votre compte chez l'outil avec lequel vous la construisez.
• Aucune limitation des tentatives de connexion. Sans elle, un attaquant peut tester des mots de passe sans fin.

Quoi demander à votre créateur d'applis par IA

• « Ajoute l'inscription et la connexion avec [une bibliothèque ou un fournisseur bien connu]. N'écris pas de hachage de mot de passe maison. »
• « Stocke les mots de passe hachés avec bcrypt ou Argon2. »
• « Utilise des cookies HttpOnly et Secure pour la session. »
• « Ajoute des rôles : admin et membre. Liste chaque point de terminaison et les rôles autorisés à l'appeler. »
• « Impose côté serveur que les utilisateurs ne puissent lire et modifier que leurs propres enregistrements. Montre-moi ensuite comment tu l'as vérifié. »
• « Ajoute la réinitialisation de mot de passe avec des liens à usage unique qui expirent au bout d'une heure. »
• « Limite le nombre de tentatives de connexion. »

Testez ensuite vous-même : créez deux comptes et essayez d'accéder aux données de l'un en étant connecté avec l'autre. Notre guide pour ajouter une connexion et notre liste de contrôle de sécurité vont plus loin.

L'authentification dans Mythex

Mythex ne fournit pas de produit d'authentification intégré pour les utilisateurs de votre appli ; vous choisissez une approche — e-mail et mot de passe stockés dans la base de données de votre projet, ou le SDK d'un fournisseur hébergé — et vous demandez à l'agent de l'ajouter. Les clés des fournisseurs vont dans les secrets du projet, pas dans le chat. Ceci est distinct de la façon dont vous vous connectez à Mythex lui-même. La recette de la documentation sur l'ajout d'une connexion à votre appli propose un prompt de départ que vous pouvez adapter, et qu'est-ce qu'une API explique où vivent ces vérifications côté serveur.

Questions