Skip to main content
Différents types de renseignements sur l’utilisateur sont souvent stockés dans plusieurs ressources en ligne. Les utilisateurs peuvent téléverser et stocker des photos sur un service comme Flickr, conserver des fichiers numériques dans Dropbox et stocker des contacts et des événements dans Google Calendar ou sur Facebook. Souvent, de nouvelles applications veulent utiliser les renseignements déjà créés dans une ressource en ligne. Pour ce faire, l’application doit demander l’autorisation d’y accéder au nom de l’utilisateur. Les portées définissent les actions précises que les applications peuvent être autorisées à effectuer au nom de l’utilisateur.

​
Façons d’utiliser les portées

Lorsqu’une application demande l’autorisation d’accéder à une ressource par l’intermédiaire d’un , elle utilise le paramètre scope pour préciser l’accès dont elle a besoin, et le serveur d’autorisation utilise le paramètre scope pour indiquer l’accès qui a réellement été accordé (si cet accès diffère de celui qui avait été demandé). En général, vous utilisez les portées de trois façons :
  • À partir d’une application, pour vérifier l’identité d’un utilisateur et obtenir des renseignements de base sur son profil, comme son courriel ou sa photo de profil. Dans ce scénario, les portées offertes comprennent celles mises en œuvre par le protocole Connect (OIDC). Pour en savoir plus, consultez Portées OpenID Connect.
  • Dans une API, pour mettre en œuvre le contrôle d’accès. Dans ce cas, vous devez définir des portées personnalisées pour votre API, puis les identifier afin que les applications appelantes puissent les utiliser. Pour en savoir plus, consultez Portées d’API.
  • À partir d’une application, pour faire une requête à une API qui a mis en œuvre ses propres portées personnalisées. Dans ce cas, vous devez savoir quelles portées personnalisées sont définies pour l’API que vous appelez. Pour voir des exemples d’appel à une API personnalisée à partir d’une application, consultez Exemples de cas d’utilisation : portées et claims

​
Bonnes pratiques

Comprenez votre cas d’utilisation et choisissez les portées les plus restrictives possible. Si vous demandez des portées, assurez-vous de demander suffisamment d’accès pour que votre application fonctionne, mais ne demandez que ce dont vous avez absolument besoin. Cherchez-vous à établir l’identité d’un utilisateur ou à obtenir son autorisation pour interagir avec ses données? Il y a une grande différence entre importer les renseignements du profil Facebook d’un utilisateur et publier sur son mur. En ne demandant que ce dont vous avez besoin, vous augmentez vos chances d’obtenir le consentement de l’utilisateur lorsque c’est nécessaire, puisque les utilisateurs sont plus enclins à accorder l’accès à des portées limitées et clairement définies. De même, lorsque vous créez des portées personnalisées pour une API, tenez compte du niveau d’accès granulaire dont les applications pourraient avoir besoin et concevez-les en conséquence.

​
Portées demandées par rapport aux portées accordées

Dans certains cas, les utilisateurs doivent consentir à l’accès demandé. Bien qu’habituellement les portées renvoyées soient identiques à ceux qui ont été demandés, les utilisateurs peuvent modifier les portées accordées (au moment du consentement initial et parfois par la suite, selon la ressource), accordant ainsi à une application moins d’accès que ce qu’elle a demandé. En tant que développeur d’application, vous devriez être conscient de cette possibilité et gérer ces cas dans votre application. Par exemple, votre application pourrait avertir l’utilisateur qu’il aura accès à moins de fonctionnalités. Elle pourrait aussi renvoyer l’utilisateur dans le pour demander des permissions supplémentaires. Mais encore une fois, n’oubliez pas que lorsqu’on leur demande leur consentement, les utilisateurs peuvent toujours refuser. Par défaut, Auth0 ne demande pas le consentement de l’utilisateur pour les applications first-party, c’est-à-dire les applications enregistrées sous le même domaine Auth0 que l’API qu’elles appellent; toutefois, vous pouvez configurer votre API dans Auth0 pour exiger le consentement de l’utilisateur pour les applications first-party. Les applications third-party, qui sont des applications externes, exigent le consentement de l’utilisateur.

​
En savoir plus