OAuth en lecture seule

OAuth est un cadre d’autorisation qui permet à une application d’accéder à certaines ressources pour le compte d’un utilisateur. L’application reçoit un accès délégué, au lieu de recevoir directement le mot de passe du compte. « En lecture seule » décrit les droits accordés à cet accès. OAuth peut également autoriser des opérations de création, de modification ou de suppression.

La lecture seule doit donc se vérifier dans les permissions demandées, les fonctions exposées et les contrôles du service. Elle ne se déduit ni du bouton de connexion ni de la présence du mot OAuth. Une application peut présenter une fonction de lecture tout en conservant un jeton plus large que nécessaire.

L’utilisateur ou l’administrateur est dirigé vers le service qui détient les données. Il examine la demande d’accès, puis l’autorise selon les règles du fournisseur. L’application utilise ensuite un jeton d’accès pour appeler les opérations permises. Certaines configurations utilisent aussi un jeton permettant de renouveler cet accès.

Les détails varient selon le service et le type d’application. La durée des jetons, le mode de révocation et le consentement administratif doivent être consultés dans la documentation du fournisseur. Une autorisation approuvée une fois peut rester utilisable : fermer la conversation ne signifie pas forcément couper la connexion.

Un accès en lecture seule empêche les opérations d’écriture couvertes par les permissions concernées. Il peut toutefois permettre de consulter ou de copier des informations. Un outil peut lire un document sensible sans jamais le modifier. Il faut donc vérifier le périmètre des dossiers, les utilisateurs concernés et les conditions de conservation.

La lecture seule n’est pas non plus une garantie de qualité de la réponse. Un assistant peut interpréter incorrectement des données qu’il lit correctement. La protection de l’application source et la vérification de l’analyse sont deux sujets distincts, à traiter ensemble dans un projet.

Imaginons une équipe qui souhaite poser des questions sur ses opportunités sans autoriser la modification du CRM. Elle choisit une connexion limitée aux fonctions nécessaires : lister les opportunités et lire leurs champs utiles. Elle vérifie les scopes accordés et les droits du compte connecté.

Pendant le test, l’équipe demande une synthèse de ses dossiers. Elle contrôle aussi une demande de modification, dans un environnement adapté : l’opération doit être indisponible ou refusée. Si un connecteur propose un outil d’écriture malgré la promesse de lecture seule, le périmètre doit être revu avant utilisation.

Le responsable vérifie ensuite la révocation. Il supprime l’autorisation et confirme qu’une nouvelle consultation ne fonctionne plus avec l’ancien accès. Cet exemple décrit une démarche de contrôle, pas une propriété automatique de tous les connecteurs.

Conservez le nom de l’application, le fournisseur d’identité, le compte utilisé et les permissions accordées. Notez les opérations accessibles et la personne qui peut révoquer l’accès. Une capture du consentement peut être utile, mais elle ne remplace pas la liste technique des droits réellement appliqués.

Vérifiez aussi où le jeton est stocké et qui peut l’utiliser. Le jeton est une information sensible : il ne doit pas apparaître dans un journal accessible à tous ni dans un document de support. Les erreurs de connexion doivent être compréhensibles sans exposer ce secret.

Accorder toutes les permissions pour éviter une difficulté de configuration augmente inutilement le périmètre. Utiliser le compte d’un administrateur pour une simple consultation peut exposer davantage de données que prévu. Enfin, retirer un outil visible de l’interface ne prouve pas que les permissions du jeton ont été réduites.

Prévoir une liste de connexions actives facilite le suivi lors d’un départ, d’un changement de fournisseur ou d’un incident. Vérifiez les accès à chaque changement important, car le besoin initial et les fonctions du produit peuvent évoluer.

Définissez d’abord les questions auxquelles la connexion doit répondre. Faites correspondre chaque besoin à une opération de lecture documentée. Si une permission plus large est demandée, demandez pourquoi et examinez une alternative avant de l’accorder.

Utilisez un compte au périmètre approprié et un environnement de test lorsqu’il est disponible. Contrôlez la consultation d’une ressource autorisée, le refus d’une ressource hors périmètre et l’impossibilité d’une écriture. Le compte rendu doit préciser ce qui a été testé et ce qui reste inconnu.

Préparez la révocation avant la mise en service. Identifiez l’administrateur, l’emplacement du réglage et la manière de vérifier le résultat. Révocation, conservation des données déjà copiées et fermeture du compte sont des actions différentes : documentez chacune selon le fonctionnement du fournisseur.

Le cadre d’autorisation et les scopes sont définis dans la RFC 6749 de l’IETF.

Référence consultée le 10 octobre 2026.