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

OAuth est un standard ouvert qui permet à un utilisateur d'accorder à une app un accès limité à son compte sur un autre service, sans lui communiquer son mot de passe. Lorsque vous cliquez sur « Connecter Google Agenda » et voyez un écran demandant « Autoriser cette app à voir vos événements ? », c'est OAuth. L'app 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, est à la base des boutons « Se connecter avec Google » et similaires.

Pourquoi OAuth compte quand on crée avec l'IA

OAuth apparaît dans deux situations courantes lorsqu'on construit une app :

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

Dans les deux cas, votre créateur d'apps IA peut écrire le code, mais certaines étapes ne reviennent qu'à vous : créer une application développeur auprès du fournisseur, obtenir un client ID et un client secret, enregistrer les URL de rappel et, pour certaines autorisations, passer la validation du fournisseur. Comprendre OAuth rend ces étapes, et les erreurs qu'elles produisent, beaucoup moins mystérieuses. Pour la vue d'ensemble de la connexion, voir qu'est-ce que l'authentification.

Une analogie du quotidien

Pensez à la carte magnétique d'un hôtel. À l'arrivée, la réception vérifie qui vous êtes, puis vous remet une carte qui ouvre votre chambre et la salle de sport, mais pas les autres chambres ni les espaces 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 fournit une nouvelle.

• La réception est le serveur d'autorisation (la page de connexion de Google).
• La vérification de votre identité correspond à votre connexion à Google.
• La carte magnétique est le jeton d'accès.
• « Chambre et salle de sport uniquement » correspond aux périmètres que vous avez approuvés.
• Le départ correspond à l'expiration du jeton, ou à sa révocation par vous.

L'app que vous utilisez ne voit jamais votre mot de passe Google, seulement la carte.

Comment fonctionne OAuth, étape par étape

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

1. Clic. L'utilisateur clique sur « Connecter Google Agenda ».
2. Redirection vers le fournisseur. L'app envoie le navigateur vers Google avec son client ID, les périmètres demandés (lecture des événements de l'agenda) et l'URI de redirection vers laquelle Google doit renvoyer l'utilisateur.
3. Connexion et consentement. L'utilisateur se connecte à Google (s'il ne l'est pas déjà) et voit un écran de consentement listant ce que l'app demande. Il clique sur Autoriser.
4. Retour avec un code. Google redirige le navigateur vers l'URI de redirection de l'app, avec un code d'autorisation à usage unique et de courte durée.
5. Échange côté serveur. Le serveur de l'app envoie ce code, accompagné de son secret client, directement à Google et reçoit un jeton d'accès (et souvent un jeton de rafraîchissement).
6. Utilisation de l'API. Le serveur appelle l'API de Google Agenda avec le jeton d'accès et récupère 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 de cette forme :

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

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

OAuth, OpenID Connect ou votre propre connexion

Beaucoup d'apps combinent ces approches : connexion par e-mail 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 fausses 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 vrais bugs de sécurité.
• « L'app reçoit mon mot de passe. » Ce n'est jamais le cas. C'est justement le principe.
• « Demander plus de périmètres est sans conséquence. » Les utilisateurs se méfient des demandes larges, et des fournisseurs comme Google peuvent exiger une validation de l'app pour les périmètres sensibles ou restreints. Ne demandez que ce dont vous avez besoin.
• « Le secret client peut figurer dans le frontend. » Tout ce qui se trouve dans le code du navigateur est public. Gardez-le dans des secrets côté serveur.
• « Ça marche en test, donc ça marchera en production. » Les fournisseurs limitent souvent les apps 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 app doit gérer ces deux cas proprement.

Que demander à votre créateur d'apps IA

• « Ajoute « Se connecter avec Google » via OpenID Connect avec une bibliothèque d'authentification bien entretenue : ne réécris pas le flux OAuth à la main. »
• « Utilise le flux par code d'autorisation avec PKCE et vérifie le paramètre state. »
• « Lis le client ID et le client secret depuis des variables d'environnement côté serveur. »
• « Ne demande que les périmètres nécessaires : lecture seule de l'agenda. »
• « Indique-moi toutes les URL de redirection à enregistrer dans la console du fournisseur : pour l'aperçu, l'URL publiée et mon domaine personnalisé. »
• « Stocke les jetons de rafraîchissement 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 native pour les utilisateurs finaux des apps que vous créez ; sa documentation décrit une approche « apportez votre propre solution » : vous choisissez une bibliothèque d'authentification ou un fournisseur hébergé, vous stockez ses clés comme secrets du projet, et l'agent écrit le code. La recette d'ajout d'authentification propose un prompt 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 des dépôts utilise OAuth GitHub, et les assistants IA qui se connectent à Mythex via MCP passent par une page de consentement OAuth. Pour aller plus loin, voir qu'est-ce que l'authentification et qu'est-ce que l'authentification à deux facteurs.

Questions