Qu'est-ce qu'OAuth? « Se connecter avec Google » et accès délégué expliqués

OAuth est une norme ouverte qui permet à un utilisateur d'accorder à une application un accès limité à son compte sur un autre service, sans lui communiquer son mot de passe. Quand vous cliquez sur « Connecter Google Agenda » et voyez un écran demandant « Autoriser cette application à voir vos événements? », c'est OAuth. L'application reçoit un jeton pour exactement ce que vous avez approuvé, que vous pouvez révoquer à tout moment. Le même mécanisme, avec une couche supplémentaire appelée OpenID Connect, alimente le bouton « Se connecter avec Google » et les boutons semblables.

Pourquoi OAuth est important quand on crée avec l'IA

OAuth apparaît dans deux situations courantes lorsque vous créez une application :

1. La connexion sociale. Vous voulez que vos utilisateurs puissent « Se connecter avec Google » (ou Apple, Microsoft, GitHub) au lieu de créer un autre mot de passe. Voir comment ajouter une connexion à votre application.
2. La connexion aux comptes des utilisateurs sur d'autres services. Votre application doit lire l'agenda d'un utilisateur, publier dans son compte de réseau social, récupérer des fichiers de son espace infonuagique ou synchroniser ses données comptables.

Dans les deux cas, votre générateur d'IA peut écrire le code, mais certaines étapes ne peuvent être faites que par vous : créer une application de développeur auprès du fournisseur, obtenir un identifiant client et un secret client, enregistrer les URL de rappel et, pour certaines autorisations, passer l'examen du fournisseur. Comprendre le fonctionnement d'OAuth rend ces étapes — et les erreurs qu'elles produisent — beaucoup moins mystérieuses. Pour une vue d'ensemble de la connexion, voir qu'est-ce que l'authentification.

Une analogie du quotidien

Pensez à une carte-clé d'hôtel. À l'enregistrement, la réception confirme qui vous êtes, puis vous remet une carte qui ouvre votre chambre et le gym — pas les autres chambres, ni les zones du personnel — et qui cesse de fonctionner au départ. La carte ne contient pas votre passeport. Si vous la perdez, la réception l'annule et en émet une nouvelle.

• La réception correspond au serveur d'autorisation (la page de connexion de Google).
• La vérification de votre identité correspond à votre connexion à Google.
• La carte-clé correspond au jeton d'accès.
• « Chambre et gym seulement » correspond aux portées que vous avez approuvées.
• Le départ correspond à l'expiration du jeton, ou à la révocation de l'accès par vous.

L'application que vous utilisez ne voit jamais votre mot de passe Google, seulement la carte-clé.

Fonctionnement d'OAuth, étape par étape

Le flux le plus courant pour les applications web est le flux de code d'autorisation. Voici ce qui se passe lorsqu'un utilisateur relie son Google Agenda à une application de planification :

1. Clic. L'utilisateur clique sur « Connecter Google Agenda ».
2. Redirection vers le fournisseur. L'application envoie le navigateur vers Google avec son identifiant client, les portées demandées (lecture des événements de l'agenda) et l'URI de redirection où Google doit renvoyer l'utilisateur.
3. Connexion et consentement. L'utilisateur se connecte à Google (si ce n'est pas déjà fait) et voit un écran de consentement qui énumère ce que l'application demande. Il clique sur Autoriser.
4. Retour avec un code. Google redirige le navigateur vers l'URI de redirection de l'application avec un code d'autorisation à usage unique et de courte durée.
5. Échange côté serveur. Le serveur de l'application envoie ce code, ainsi que son secret client, directement à Google et reçoit un jeton d'accès (et souvent un jeton d'actualisation).
6. Utilisation de l'API. Le serveur appelle l'API de Google Agenda avec le jeton d'accès et obtient les événements de l'utilisateur.

Le rappel de l'étape 4 ressemble à ceci :

https://votreapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

Et la réponse contenant le jeton, à l'étape 5, est du JSON qui ressemble à ceci :

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Le point de conception important : l'échange du jeton se fait de serveur à serveur, de sorte que le secret client et les jetons n'ont jamais à transiter par le navigateur.

OAuth, OpenID Connect ou votre propre connexion

De nombreuses applications combinent ces approches : connexion par courriel et mot de passe, plus « Se connecter avec Google » via OIDC, plus des connexions OAuth distinctes vers d'autres services.

Termes clés

Idées reçues courantes

• « OAuth est un système de connexion. » OAuth seul accorde un accès; OpenID Connect gère l'identité. Utiliser un simple jeton d'accès comme preuve de l'identité de quelqu'un a causé de véritables failles de sécurité.
• « L'application obtient mon mot de passe. » Ce n'est jamais le cas. C'est tout l'intérêt.
• « Demander plus de portées est sans danger. » Les utilisateurs se méfient des demandes larges, et des fournisseurs comme Google peuvent exiger un examen de l'application pour les portées sensibles ou restreintes. Demandez seulement ce dont vous avez besoin.
• « Le secret client peut aller dans l'interface. » Tout ce qui se trouve dans le code du navigateur est public. Gardez-le dans les secrets côté serveur.
• « Ça fonctionne en test, donc ça fonctionnera en production. » Les fournisseurs limitent souvent les applications non vérifiées — par exemple, à une liste d'utilisateurs de test — et l'URI de redirection de votre domaine en ligne doit être enregistrée séparément.
• « Les jetons durent éternellement. » Les jetons d'accès expirent rapidement, et les utilisateurs peuvent révoquer l'accès. Votre application doit gérer ces deux cas avec souplesse.

Quoi demander à votre générateur d'IA

• « Ajoute « Se connecter avec Google » en utilisant OpenID Connect avec une bibliothèque d'authentification bien entretenue — n'écris pas le flux OAuth à la main. »
• « Utilise le flux de code d'autorisation avec PKCE et vérifie le paramètre state. »
• « Lis l'identifiant client et le secret client depuis des variables d'environnement, côté serveur. »
• « Demande seulement les portées dont nous avons besoin : accès en lecture seule à l'agenda. »
• « Dis-moi chaque URL de redirection que je dois enregistrer dans la console du fournisseur, pour l'aperçu, l'URL publiée et mon domaine personnalisé. »
• « Stocke les jetons d'actualisation chiffrés dans la base de données, et gère les jetons expirés ou révoqués en demandant à l'utilisateur de se reconnecter. »
• « Permets aux utilisateurs de déconnecter l'intégration depuis leur page de paramètres. »

OAuth et Mythex

Mythex n'intègre pas de connexion pour les utilisateurs finaux des applications que vous créez; sa documentation décrit une approche où vous apportez votre propre solution — vous choisissez une bibliothèque d'authentification ou un fournisseur hébergé, vous stockez ses clés comme secrets de projet, et l'agent écrit le code. La recette d'ajout d'authentification contient une demande de départ pour cela. Vous rencontrerez aussi OAuth dans Mythex lui-même : vous pouvez vous inscrire avec Google, la connexion de GitHub pour la synchronisation de dépôts utilise OAuth GitHub, et les clients d'IA qui se connectent à Mythex par MCP passent par une page de consentement OAuth. Pour en savoir plus, voir qu'est-ce que l'authentification et qu'est-ce que l'authentification à deux facteurs.

Questions