> ## Documentation Index > Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Comprenez le principe des scopes et explorez des exemples généraux de leur utilisation. # Scopes Différents types d’informations sur l’utilisateur sont souvent stockés dans diverses 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 l’information déjà créée dans une ressource en ligne. Pour ce faire, l’application doit demander l’autorisation d’accéder à cette information au nom de l’utilisateur. Les scopes définissent les actions précises que les applications peuvent être autorisées à effectuer au nom de l’utilisateur.
## Façons d’utiliser les scopes
Lorsqu’une application demande l’autorisation d’accéder à une ressource auprès d’un serveur d’autorisation, 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 l’accès accordé diffère de celui qui avait été demandé). En général, vous utilisez les scopes de trois façons : * Depuis une application, pour vérifier l’identité d’un utilisateur et obtenir des renseignements de base à son sujet, comme son courriel ou sa photo. Dans ce scénario, les scopes à votre disposition comprennent ceux prévus par le protocole OpenID Connect (OIDC). Pour en savoir plus, consultez [OpenID Connect Scopes](/fr-CA/docs/get-started/apis/scopes/openid-connect-scopes). * Dans une [API](/fr-CA/docs/api), pour mettre en œuvre le contrôle d’accès. Dans ce cas, vous devez définir des scopes personnalisés pour votre API, puis les identifier afin que les applications appelantes puissent les utiliser. Pour en savoir plus, consultez [Scopes d’API](/fr-CA/docs/get-started/apis/scopes/api-scopes). * Depuis une application, pour appeler une API qui a mis en œuvre ses propres scopes personnalisés. Dans ce cas, vous devez connaître les scopes personnalisés définis pour l’API que vous appelez. Pour voir des exemples d’appel d’une API personnalisée depuis une application, consultez [Exemples de cas d’utilisation : Scopes et revendications](/fr-CA/docs/get-started/apis/scopes/sample-use-cases-scopes-and-claims)
## Pratiques exemplaires
Comprenez votre cas d’utilisation et choisissez les scopes les plus restrictifs possible. Si vous demandez des scopes, assurez-vous d’en demander suffisamment pour que votre application fonctionne, mais limitez-vous à ce dont vous avez absolument besoin. Cherchez-vous à établir l’identité d’un utilisateur ou à obtenir sa permission d’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 demandant uniquement ce dont vous avez besoin, vous augmentez vos chances d’obtenir le consentement de l’utilisateur lorsque requis, puisque les utilisateurs sont plus susceptibles d’accorder l’accès à des scopes limités et clairement définis. De même, lorsque vous créez des scopes personnalisés pour une API, réfléchissez au niveau de granularité de l’accès dont les applications pourraient avoir besoin et concevez-les en conséquence.
## Scopes demandés et scopes accordés
Dans certains cas, les utilisateurs peuvent consentir à l’accès demandé. Habituellement, les scopes renvoyés sont identiques à ceux qui ont été demandés, mais les utilisateurs peuvent modifier les scopes accordés (à la fois lors du consentement initial et, parfois, par la suite, selon la ressource), accordant ainsi à une application un accès plus limité que celui qu’elle avait demandé. En tant que développeur d’application, vous devriez être conscient de cette possibilité et prévoir le traitement de ces cas dans votre application. Par exemple, votre application pourrait avertir l’utilisateur que certaines fonctionnalités seront limitées. Elle pourrait aussi rediriger l’utilisateur dans le flux d’autorisation pour demander des autorisations supplémentaires. Mais, encore une fois, rappelez-vous que lorsqu’on leur demande leur consentement, les utilisateurs peuvent toujours refuser. Par défaut, Auth0 n’exige pas le consentement de l’utilisateur pour les applications de première partie, 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 de première partie. Les applications tierces, c’est-à-dire les applications externes, exigent le consentement de l’utilisateur.
## En savoir plus
* [OpenID Connect Scopes](/fr-CA/docs/get-started/apis/scopes/openid-connect-scopes) * [Scopes d’API](/fr-CA/docs/get-started/apis/scopes/api-scopes) * [Exemples de cas d’utilisation : Scopes et revendications](/fr-CA/docs/get-started/apis/scopes/sample-use-cases-scopes-and-claims) * [Activer le contrôle d’accès basé sur les rôles pour les API](/fr-CA/docs/get-started/apis/enable-role-based-access-control-for-apis)