Portée (scope) OAuth

Un scope OAuth est une portée d’autorisation : il décrit une permission demandée ou accordée à une application. Le service définit ses propres scopes et leur signification. Certains donnent accès à un profil ; d’autres permettent de consulter des documents, de lire une messagerie ou de réaliser des opérations. Le nom du scope doit être interprété avec la documentation du fournisseur.

Un scope ne représente pas toujours un dossier ou une liste de personnes. Il peut décrire une famille d’opérations sur toutes les ressources accessibles au compte. Deux services peuvent utiliser des noms proches avec des effets différents. Copier une configuration d’une application vers une autre sans revoir ces permissions peut donc créer un accès inattendu.

Les permissions de l’application se combinent avec celles du compte connecté et les règles du service. Une application autorisée à lire des fichiers ne peut pas nécessairement lire tous les fichiers de l’organisation. Le rôle de l’utilisateur, le partage des documents et les politiques administratives interviennent également.

À l’inverse, utiliser un compte très privilégié peut élargir fortement les ressources accessibles à un scope de lecture. Pour comprendre le résultat, examinez la permission, le compte et la ressource visée. Un test sur un seul document autorisé ne suffit pas à démontrer que les documents sensibles sont exclus.

Le scope décrit un accès délégué. Le rôle indique ce que le compte peut faire dans le service. La fonction visible dans un assistant correspond à un outil proposé à l’utilisateur. Ces trois niveaux peuvent être différents. Masquer un bouton ne retire pas forcément une permission du jeton.

Une demande de consentement doit pouvoir être reliée au besoin. Si un outil de synthèse demande une permission d’écriture, examinez sa justification. Une intégration peut avoir une contrainte réelle, mais elle doit être connue et acceptée dans le périmètre retenu. « Nécessaire pour connecter » est une explication insuffisante sans détail.

Imaginons une équipe qui veut retrouver les réunions d’un compte pour préparer un planning. La fonction attendue est la lecture des événements. Elle examine les scopes demandés et vérifie que l’intégration n’obtient pas inutilement le droit de créer ou de supprimer des rendez-vous.

Le test compare un calendrier autorisé et un calendrier qui ne doit pas être accessible. Il contrôle aussi les champs récupérés : titre, participants et description ne présentent pas le même niveau de confidentialité. L’équipe peut limiter les informations remontées lorsque certains détails ne servent pas au planning.

Si le produit ajoute ensuite une fonction de réservation, une nouvelle permission peut devenir nécessaire. Cette évolution doit être traitée comme un changement de périmètre. Le premier consentement ne vaut pas approbation générale de toutes les fonctions futures. L’exemple est illustratif et les noms des permissions varient selon le fournisseur.

Appliquez un accès adapté à la tâche. Préférez une permission précise lorsqu’elle existe et évitez de demander un ensemble de droits simplement parce qu’il simplifie la configuration. Conservez la liste des scopes accordés, le compte associé et la date du contrôle.

Revoyez les autorisations lors d’un départ, d’un changement de logiciel ou d’une évolution des fonctions. Un accès devenu inutile doit pouvoir être retiré. Vérifiez ensuite le comportement de l’intégration : certains services disposent de caches ou de copies qu’il faut traiter séparément.

Un scope n’indique pas à lui seul la durée de conservation des données, l’endroit où elles sont stockées ni la qualité des réponses. Une permission de lecture peut fournir des informations sensibles à une application qui les conserve. Il faut examiner les conditions d’utilisation en plus de l’autorisation.

La lecture de la documentation évite aussi de confondre un scope demandé avec un scope réellement accordé. Une réponse d’autorisation peut contenir un périmètre différent ; l’application doit gérer les droits manquants sans contourner la politique du service.

Préparez un tableau avec la fonction attendue, la permission nécessaire, le compte utilisé et les ressources concernées. Faites valider le périmètre par la personne qui administre le service. Pour chaque permission large, notez la raison et les mesures qui limitent son usage.

Testez une ressource autorisée et une ressource exclue. Vérifiez une opération d’écriture si votre objectif est la lecture seule, avec un environnement adapté. Documentez les refus autant que les succès : ils permettent de comprendre les limites de la connexion.

Enfin, précisez comment réduire les droits et révoquer l’accès. Une procédure utilisable par l’équipe est plus utile qu’une configuration connue seulement de son installateur. Conservez les références du fournisseur pour revoir le réglage lorsqu’une permission change de nom ou de fonctionnement.

La portée d’autorisation est décrite dans la section 3.3 de la RFC 6749.

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