Permissions
Différentes informations utilisateur sont souvent stockées sur un certain nombre de ressources en ligne. Les utilisateurs peuvent téléverser et stocker des photos avec un service comme Flickr, conserver des fichiers numériques sur Dropbox et stocker des contacts et des événements dans Google Calendar ou sur Facebook.
Souvent, les nouvelles applications ont tendance à utiliser les informations qui ont déjà été créées dans une ressource en ligne. Dans ce cas, l’application devra demander l’autorisation d’accéder à ces informations au nom de l’utilisateur. Les permissions définissent les actions spécifiques que les applications peuvent être autorisées à effectuer au nom d’un utilisateur.
Comment utiliser les permissions
Lorsqu’une application sollicite l’autorisation d’accéder à une ressource via un serveur d’autorisation, elle utilise le paramètre scope pour définir les droits d’accès nécessaires. Le serveur d’autorisation, à son tour, se sert du paramètre scope pour indiquer les droits effectivement accordés, en particulier si ceux-ci diffèrent de la demande initiale.
En général, vous utilisez les permissions de trois manières :
À partir d’une application, pour vérifier l’identité d’un utilisateur et obtenir des informations de profil de base sur l’utilisateur, telles que son courriel ou sa photo. Dans ce scénario, les permissions à votre disposition incluent celles implémentées par le protocole OpenID Connect (OIDC). Pour en savoir plus, veuillez consulter Permissions OpenID Connect.
Dans une API, pour mettre en œuvre le contrôle d’accès. Dans ce cas, vous devez définir des permissions personnalisées pour votre API, puis identifier ces permissions afin que les applications appelantes puissent les utiliser. Pour en savoir plus, veuillez consulter Permissions des API.
Depuis une application, pour appeler une API qui a implémenté ses propres permissions personnalisées. Dans ce cas, vous devez savoir quelles permissions personnalisées sont définies pour l’API que vous appelez. Pour voir des exemples d’appel d’une API personnalisée à partir d’une application, veuillez consulter Exemples de cas d’utilisation : Permissions et demandes
Meilleures pratiques
Analysez votre cas d’utilisation et sélectionnez les permissions les plus restrictives possibles.
Si vous demandez des permissions, assurez-vous de demander un accès suffisant pour que votre application fonctionne, mais limitez-vous strictement à ce qui est indispensable. Est-ce que vous authentifiez l’identité d’un utilisateur ou lui demandez-vous de vous autoriser à accéder et interagir avec ses données? Il y a une grande différence entre importer les informations de profil d’un utilisateur de Facebook et publier sur son mur. En sollicitant uniquement les accès nécessaires, vous augmentez vos chances d’obtenir le consentement de l’utilisateur lorsque requis, car ces derniers sont plus enclins à accepter des permissions limitées et clairement définies.
De même, lors de la création de permissions personnalisées pour une API, réfléchissez aux niveaux d’accès granulaires dont les applications pourraient avoir besoin, et concevez-les en conséquence.
Permissions demandées et permissions accordées
Dans certains cas, les utilisateurs doivent consentir à l'accès demandé. Bien que les permissions retournées soient généralement identiques à celles demandées, les utilisateurs peuvent ajuster les autorisations accordées (aussi bien lors du consentement initial que parfois ultérieurement, selon la ressource), accordant ainsi à une application un accès plus restreint que celui initialement sollicité.
En tant que développeur d’applications, vous devez être conscient de cette possibilité et gérer ces cas dans votre application. Par exemple, votre application pourrait avertir l’utilisateur que certaines de ses fonctionnalités seront limitées. Elle pourrait également rediriger l’utilisateur vers le flux d’autorisation afin de demander des permissions supplémentaires. Cependant, gardez à l’esprit qu’au moment de solliciter leur consentement, les utilisateurs ont toujours la possibilité de le refuser.
Par défaut, Auth0 ne demande pas le consentement de l’utilisateur pour les applications de première partie, c’est-à-dire celles qui sont 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 même pour les applications de première partie. Les applications de tiers, qui sont des applications externes, nécessitent le consentement de l’utilisateur.