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

L'authentification est la façon dont une app confirme l'identité d'un utilisateur — habituellement en vérifiant quelque chose qu'il connaît (un mot de passe), quelque chose qu'il possède (un code envoyé à son téléphone ou à son courriel) ou une identité provenant d'un service de confiance (comme « Se connecter avec Google »). Une fois l'utilisateur authentifié, l'app 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 vous construisez avec l'IA

Ajouter une connexion est l'une des demandes les plus courantes adressées à un créateur d'apps 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 en toute sécurité?
• Chaque page privée et chaque point d'accès API vérifie-t-il vraiment qui 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 app peut sembler parfaitement sécurisée tout en échouant sur chacun de ces points. Comprendre les pièces en mouvement vous 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. La réceptionniste vous remet ensuite une carte-clé. Cette carte est votre session : pendant tout votre séjour, vous ne montrez plus votre identité; vous utilisez la carte.

La carte ouvre votre chambre, le gym et l'ascenseur jusqu'à votre étage — mais pas les chambres des autres clients ni le bureau du personnel. C'est l'autorisation : ce à quoi votre identité a le droit d'accéder. Si vous perdez la carte, l'hôtel peut la désactiver au comptoir (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 app sécurisée ne stocke jamais votre mot de passe réel. Elle stocke plutôt un condensé (hash) : le résultat d'une fonction à sens unique qui transforme le mot de passe en une chaîne fixe. Quand vous vous connectez, l'app condense ce que vous avez tapé et compare le résultat au condensé stocké.

Deux détails rendent ce procédé sûr :

• Un sel — une valeur aléatoire ajoutée à chaque mot de passe avant le condensé, pour que deux personnes ayant le même mot de passe obtiennent des condensés 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 condensés généralistes comme MD5 ou SHA-256 sont bien trop rapides; les attaquants peuvent tester des milliards de suppositions.

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

Sessions contre jetons

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

Pour les témoins, trois réglages comptent : HttpOnly (le JavaScript de la page ne peut pas lire le témoin), Secure (envoyé seulement en HTTPS) et SameSite (limite son 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 app d'obtenir un accès limité à votre compte sur un autre service — par exemple lire votre agenda Google — sans jamais voir votre mot de passe Google. Vous êtes redirigé vers Google, vous approuvez des permissions précises (appelées portées, ou scopes) et Google donne à l'app un jeton pour ces seules permissions.

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

Un exemple concret : la connexion à un portail client

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

• Authentification : les clients se connectent par courriel avec un lien magique, donc il n'y a 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é : sur le serveur, pour chaque requête. Le serveur retrouve l'utilisateur connecté, puis ne renvoie que les projets dont project.company_id correspond à l'entreprise de l'utilisateur. Cacher le bouton « Marquer payée » ne suffit pas — le point d'accès lui-même doit refuser.

Termes courants expliqués

Erreurs courantes et idées fausses

• Vérifier les permissions seulement dans la page. Si le navigateur cache un bouton mais que l'API ne vérifie rien, n'importe qui peut appeler l'API directement.
• Faire confiance aux identifiants 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 condensé.
• 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 courriel possède un compte.
• Confondre votre connexion avec celle de votre créateur. Les utilisateurs de votre app sont distincts de votre compte chez l'outil que vous utilisez pour construire.
• Aucune limitation du nombre de connexions. Sans elle, des attaquants peuvent essayer des mots de passe sans fin.

Quoi demander à votre créateur d'apps IA

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

Ensuite, testez-le vous-même : créez deux comptes et essayez d'atteindre les 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 app; vous choisissez une approche — courriel et mot de passe stockés dans la base de données de votre projet, ou le SDK d'un fournisseur hébergé — et demandez à l'agent de l'ajouter. Les clés des fournisseurs vont dans les secrets du projet, pas dans le chat. Cela 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 app contient une consigne de départ que vous pouvez adapter, et qu'est-ce qu'une API explique où vivent ces vérifications côté serveur.

Questions