Considérations relatives à l’autorisation des utilisateurs et à la planification connexe pour votre mise en œuvre B2C IAM.
Commençons par prendre un peu de recul pour parler du contrôle d’accès. Il n’existe pas, dans l’industrie, de définition unique et parfaitement tranchée du contrôle d’accès, mais si vous prenez le temps de faire quelques recherches, vous verrez que la plupart des sources faisant autorité s’entendent pour dire qu’il s’agit du concept global qui regroupe l’authentification, l’autorisation, le consentement et l’application des politiques afin de garantir que seules les bonnes personnes et les bons services ont accès à vos applications et à vos API. Examinons maintenant de plus près les différences entre l’authentification, l’autorisation, le consentement et l’application des politiques. Votre Auth0 (votre ) est généralement responsable de l’authentification et du consentement, ainsi que d’une partie ou de la totalité de l’autorisation et de l’application des politiques. De plus, une ou l’API elle-même est presque toujours le principal point d’application des politiques, surtout lorsqu’un accès contextuel est requis :
Authentification : le processus qui consiste à déterminer si un principal (un utilisateur ou une application) est bien celui ou celle qu’il ou elle prétend être.
Autorisation : le processus qui consiste à déterminer ce qui est permis, en fonction du principal, des permissions qui lui ont été accordées et/ou de l’ensemble des critères d’accès contextuels applicables.
Consentement : les permissions que l’utilisateur () a accordées à une application pour agir en son nom. Il s’agit généralement d’une exigence de l’autorisation déléguée. L’utilisateur doit donner au client la permission d’accéder à ses données dans un autre système.
Application des politiques : le fait d’appliquer les politiques de l’application ou de l’API en rejetant ou en autorisant l’accès selon les renseignements d’authentification et/ou d’autorisation de l’utilisateur.
De façon générale, nous regroupons les différents types de contrôle d’accès en trois catégories distinctes afin de mieux comprendre a) quel acteur est responsable de stocker l’information, b) quel acteur est responsable de prendre les décisions et c) quel acteur est responsable d’appliquer les restrictions.
La première catégorie est celle où l’accès à une application ou à une API dans son ensemble est soit accordé, soit refusé. Les données nécessaires à cette application et le processus d’application lui-même sont généralement définis dans le contexte de l’Authorization Server. Par exemple, en utilisant app_metadata associé à un utilisateur et une Action définie dans votre tenant Auth0.
La deuxième catégorie est celle où l’accès à un sous-ensemble précis des fonctionnalités d’une application ou d’une API est soit accordé, soit refusé. Les données nécessaires à cette application sont généralement stockées dans l’Authorization Server. Par exemple, en utilisant app_metadata pour un utilisateur dans votre tenant Auth0, tandis que l’application est effectuée dans l’application ou l’API elle-même. Dans ce scénario, les données sont généralement transmises sous la forme d’une ou de plusieurs claims personnalisées dans un jeton id ou access.
La troisième catégorie est celle où l’accès est soit accordé, soit refusé selon ce sur quoi le principal (subject) peut agir dans le contexte d’une application ou d’une API. Les données nécessaires à cette application, tout comme le processus d’application, sont généralement définies dans le contexte de l’application ou de l’API. Dans ce scénario, les données transmises sous la forme d’une ou de plusieurs claims personnalisées dans un jeton id ou access peuvent être utilisées avec ou sans données provenant d’une source externe autre qu’Auth0.
En outre, les mécanismes de contrôle d’accès basé sur les rôles (RBAC) et de contrôle d’accès basé sur les attributs (ABAC) peuvent être appliqués dans n’importe laquelle des catégories de contrôle d’accès décrites ci-dessus. Quel que soit votre cas d’utilisation, vous devrez tenir compte de plusieurs éléments lorsque vous évaluez les fonctionnalités et le workflow dont vous avez besoin :
Existe-t-il des scénarios où l’accès à une application ou à une API entière devrait être rejeté ?
Allez-vous fournir des API auxquelles des applications tierces pourront accéder ?
Vos API seront-elles aussi accessibles à partir de vos propres applications (première partie) ?
Votre application appellera-t-elle une API tierce ?
Vos applications et/ou vos API devraient-elles appliquer le contrôle d’accès en fonction des claims utilisateur ?
Auth0 prend en charge la restriction d’accès aux applications ou aux API selon certaines conditions. Dans certains cas, vous pourriez vouloir créer une Action qui refuse l’accès à l’aide de api.access.deny() lorsque, par exemple, un utilisateur tente d’accéder à une application ou à une API au mauvais moment (comme décrit dans cet exemple) — ou si l’utilisateur n’a pas le ou les voulus dans son app_metadata. Pour une application qui utilise OpenID Connect (OIDC), cela empêcherait l’émission du ID Token utilisé pour autoriser l’accès. De même, pour une API, l’émission de tout jeton OAuth2 jeton d’accès (utilisé lors d’une requête à l’API) pourrait être empêchée, comme décrit dans cet exemple.
De façon générale, nous avons constaté qu’OIDC est le protocole standard de l’industrie le plus couramment utilisé par les clients d’Auth0 pour l’authentification dans leurs applications. Nous avons aussi constaté que, même si OAuth2 a été conçu comme un protocole de Delegation, il est couramment utilisé dans des applications propriétaires lorsqu’une API ne partage pas de session avec l’application.
Auth0 peut aussi fournir l’information nécessaire pour qu’une application puisse appliquer des restrictions. Pour l’intégration au niveau de l’application, Auth0 vous permet d’ajouter des claims personnalisées à un , que votre application peut ensuite vérifier et utiliser pour effectuer l’application des politiques. Dans ce cas, vous devrez déterminer quelle information est nécessaire pour que votre application puisse prendre des décisions d’application. Si vous devez prendre des décisions au niveau d’une API plutôt que dans votre application, vous devrez probablement utiliser un au lieu d’un ID token. Poursuivez votre lecture pour en savoir plus.
Lorsque vous décidez quelles données inclure dans votre ID token ou votre access token, tenez compte de la taille du jeton, surtout si vous transmettez le jeton dans l’URL. Même si vous ne transmettez pas les jetons dans l’URL, vous devrez aussi tenir compte du risque d’exposer des PII (renseignements personnels identifiables) sensibles. L’information contenue dans les jetons n’est pas chiffrée; donc, même si ce n’est généralement pas un problème de sécurité qu’un ID token soit divulgué, cela peut devenir un enjeu de confidentialité selon les données incluses dans le jeton.
Pour l’intégration au niveau de l’API, Auth0 prend en charge à la fois les claims personnalisées et la reconfiguration des scope, les deux dans le contexte d’un jeton d’accès. Encore une fois, vous devrez déterminer quelle information sera nécessaire pour permettre à votre API de prendre des décisions d’accès, et votre API devra appliquer ces règles en validant le contenu du jeton d’accès.
Au moment de décider si vous devriez utiliser des permissions par l’intermédiaire de claims personnalisées ou de scopes, assurez-vous de bien comprendre la nature et l’objectif des scopes. Il existe un excellent article de blogue à ce sujet, facile à lire et utile pour clarifier la question.
Dans ce scénario, votre tenant Auth0 fournit un jeton comme preuve d’accès autorisé à une application. Pour les applications qui utilisent OpenID Connect (OIDC), le protocole standard de l’industrie que nous voyons généralement le plus souvent dans les applications destinées aux clients, il s’agirait d’un ID Token présenté sous forme de JWT.
Grâce à l’extensibilité des Actions, Auth0 vous permet d’ajouter facilement des claims personnalisées à un ID Token en fonction, par exemple, du contenu des métadonnées d’un utilisateur. Votre application peut ensuite vérifier que le ID Token contient les claims nécessaires, puis autoriser ou refuser l’accès à certaines fonctionnalités, selon le cas. Notez que, même si le processus d’ajout de claims personnalisées au moyen d’une Action est simplifié, le runtime des Actions est flexible et vous permet d’écrire du code personnalisé qui pourrait avoir des effets négatifs.
Si vous envisagez d’ajouter des claims personnalisées, nous vous recommandons de stocker dans le app_metadata de l’utilisateur toutes les données de contrôle d’accès que vous pourriez devoir inclure dans les claims. D’abord, cela vous évite d’avoir à faire une requête à une API externe pour récupérer ces données, ce qui peut nuire aux performances et à l’évolutivité de la séquence de connexion. Ensuite, app_metadatane peut pas être modifié par un utilisateur; celui-ci ne peut donc pas contourner directement les restrictions de contrôle d’accès en modifiant ses propres . N’oubliez pas non plus de consulter nos conseils sur les pratiques exemplaires en matière de métadonnées.
Les scopes OIDC sont généralement utilisés par une application pour obtenir le consentement permettant d’accéder aux renseignements d’un utilisateur pendant l’authentification. Chacun des scopes prédéfinis renvoie l’ensemble des claims standard, lorsqu’ils sont définis, comme décrit dans la spécification OIDC. Les scopes qu’une application request dépendent des attributs utilisateur dont elle a besoin. Une fois les scopes demandés autorisés par l’utilisateur, les claims sont renvoyés dans l’ID Token et sont également accessibles par l’intermédiaire du endpoint /userinfo.
Dans ce scénario, votre tenant Auth0 peut fournir un OAuth2 jeton d’accès, généralement sous la forme d’un JWT, que votre API peut utiliser pour restreindre l’accès à certaines parties. De plus, Auth0 prend en charge ce qu’on appelle généralement les applications de première partie et de tierce partie.En agissant comme serveur d’autorisation, et avec le consentement de l’utilisateur (le propriétaire de la ressource), votre tenant Auth0 peut fournir un jeton d’accès — généralement sous la forme d’un JWT — à une application (client) afin qu’elle puisse accéder à une ressource protégée hébergée par un au nom du propriétaire de la ressource. Le jeton d’accès émis est généralement transmis comme jeton Bearer dans l’en-tête HTTP Authorization envoyé à une API.Que vous ayez une seule API ou une suite d’API de microservices logiquement liées, vous pouvez tirer parti des jetons d’accès fournis par Auth0 afin de sécuriser l’accès à votre ou vos services. Même s’il est relativement facile de configurer cela dans l’Auth0 Dashboard ou au moyen de l’Auth0 Management API, il est important d’examiner les différents scénarios d’application et modèles d’API afin de déterminer l’architecture la mieux adaptée à votre système.
Les jetons d’accès OAuth2 sont principalement conçus pour sécuriser des API accessibles publiquement; lorsqu’il est présenté sous la forme d’un JWT, un jeton d’accès est une entité autonome qui peut être vérifiée sans qu’il soit nécessaire d’effectuer un appel d’API tiers supplémentaire. Si vos API n’entrent pas dans cette catégorie — c.-à-d. qu’elles font partie de l’application elle-même (autrement dit, qu’elles sont appelées uniquement par cette application) ou qu’elles se trouvent derrière votre pare-feu — alors les protéger avec des jetons pourrait être excessif, et votre workflow actuel fondé sur des témoins (et autres mécanismes) pourrait suffire.
OAuth2 a été conçu précisément pour l’accès par des tiers; par exemple, un utilisateur (propriétaire de la ressource) peut vouloir utiliser une application (un client) qui n’appartient pas à la même organisation que le service qui fournit ses données (le serveur de ressources). Dans ce cas, lorsque l’application doit accéder à des données appartenant à l’utilisateur, elle redirige vers l’organisation où se trouvent les données de l’utilisateur, laquelle authentifie alors l’utilisateur puis lui demande d’autoriser l’application à accéder à ses données. Cette demande d’autorisation correspond au consentement et constitue une grande partie de ce qu’implique la prise en charge des applications tierces. Si vous prévoyez intégrer des applications tierces, il est important de les marquer comme tierces dès le départ afin qu’Auth0 gère la demande de consentement de l’utilisateur.À l’inverse, si votre organisation possède les applications, les données utilisateur elles-mêmes et les API par lesquelles ces données sont accessibles, le consentement n’est généralement pas requis puisque les interactions sont toutes de première partie. Si vous créez uniquement des applications de première partie, vous pouvez éviter de présenter à vos utilisateurs des écrans de consentement inutiles en permettant d’ignorer le consentement de l’utilisateur dans toute définition de service de ressource.
Bien que vous puissiez configurer vos applications comme étant de première partie, puis configurer vos API pour permettre aux clients de première partie d’ignorer le consentement, si vous utilisez localhost, Auth0 ne peut pas vérifier que l’application est réellement une application de première partie; vos utilisateurs seront donc quand même invités à donner leur consentement. Pour contourner cette contrainte, lorsque vous faites des tests sur votre machine locale pendant le développement, créez un faux nom d’hôte local et utilisez-le à la place.
Comme pour les ID Tokens, vous pouvez ajouter des claims personnalisées aux jetons d’accès à l’aide du mécanisme d’extensibilité des Actions d’Auth0. Une fois ajoutés, votre API peut vérifier si un jeton d’accès contient les claims requis, puis autoriser ou refuser l’accès à certaines fonctionnalités, selon le besoin.
Si vous envisagez d’ajouter des claims personnalisées, nous vous recommandons de stocker dans l’app_metadata de l’utilisateur toutes les données d’access control que vous pourriez devoir inclure dans les claims. D’une part, cela vous évite d’avoir à effectuer une requête vers une API externe pour récupérer ces données, ce qui peut nuire aux performances et à l’évolutivité. D’autre part, l’app_metadatane peut pas être modifié par un utilisateur; celui-ci ne peut donc pas contourner directement les restrictions d’access control en modifiant ses propres metadata. N’oubliez pas non plus de consulter nos conseils sur les best practices relatives aux metadata.
Les scopes OAuth2 servent généralement de mécanisme permettant à une API de déterminer quelles peuvent être exécutées au nom d’un utilisateur. Des scopes peuvent être ajoutées pour chaque API afin de définir des permissions d’accès précises dans le ou au moyen de la d’Auth0. Les scopes peuvent aussi être modifiées au moyen de l’extensibilité d’Auth0 (p. ex. au moyen d’une Action, comme dans cet exemple). Les scopes qu’une application demande pour accéder à une API devraient dépendre des fonctionnalités pour lesquelles l’utilisateur doit autoriser l’application à les utiliser. Une fois les scopes demandées autorisées, elles seront renvoyées dans le jeton d’accès, qui pourra ensuite être validé par cette API. Un bon exemple est celui où vous vous connectez à une application qui utilise un fournisseur social pour l’authentification : l’API du fournisseur social exige que l’application précise si l’utilisateur veut lui permettre de publier du contenu en son nom. Cela permet à l’utilisateur d’accepter ou de rejeter cette requête. Cet exemple montre comment l’utilisateur délègue une permission à l’application — ce qui diffère d’une API qui restreint l’accès selon le de l’utilisateur, et qui devrait être traité différemment.
Bonne pratiqueMême si vous pouvez manipuler entièrement les scopes du jeton d’accès au moyen de l’extensibilité d’Auth0, par souci de sécurité, vous ne devriez supprimer que les scopes qui ne sont pas autorisées et vous abstenir d’ajouter des scopes qui n’ont pas été demandées.
Bien que les scopes soient souvent utilisées comme moyen d’appliquer des permissions d’accès à un utilisateur, il existe des situations où cela peut devenir délicat si vous les utilisez de cette façon. Nous vous recommandons donc d’utiliser les scopes pour l’usage auquel elles sont destinées (c.-à-d. déléguer une permission à une application) et d’utiliser des claims personnalisées pour vos scénarios fondés sur les rôles ou d’autres scénarios de contrôle d’accès.
L’autorisation fine vous permet d’accorder à des utilisateurs précis l’accès à une ressource ou à un objet donné en fonction :
du rôle d’un utilisateur au sein d’une organisation, comme editor ou admin
d’un attribut de l’utilisateur ou de l’objet, comme manager pour un utilisateur ou marketing pour un objet
d’une relation entre un utilisateur et un objet; par exemple, un utilisateur ayant accès à un dossier parent en consultation a aussi accès au dossier enfant en consultation
Avec , vous pouvez créer un modèle d’autorisation pour définir la relation à utiliser afin de déterminer l’accès d’un utilisateur.
Auth0 offre une prise en charge intégrée du contrôle d’accès basé sur les rôles (RBAC). Le RBAC consiste à attribuer des permissions aux utilisateurs selon leur rôle au sein d’une organisation, et simplifie le contrôle d’accès grâce à une approche plus facile à gérer et moins sujette aux erreurs.
Il existe de nombreux scénarios dans lesquels une application sans session utilisateur interactive doit obtenir un jeton d’accès pour effectuer une requête à une API. Dans de tels scénarios, vous devez authentifier le client plutôt que l’utilisateur, et 2 fournit le type de grant client credentials pour y parvenir facilement. Voici quelques exemples courants où cela est nécessaire :
Une tâche cron ou un autre service qui doit communiquer avec votre API (p. ex. lorsqu’un rapport quotidien doit être généré et envoyé par courriel à un administrateur).
Une API distincte qui prend en charge un accès privilégié (p. ex. l’API n’est pas exposée directement aux utilisateurs, mais uniquement à un backend).
Dans certaines architectures de microservices, où certaines couches d’API doivent communiquer avec d’autres couches d’API sans intervention d’un utilisateur, ou après l’expiration d’un jeton utilisateur.
Une API privilégiée qui peut devoir être appelée avant qu’un utilisateur soit authentifié (c.-à-d. à partir d’une action ou d’un script DB personnalisé dans votre tenant Auth0)
Traditionnellement, un « compte de service » spécial était créé pour répondre à ces scénarios : un utilisateur avec un nom d’utilisateur et un mot de passe configurés pour des services prenant en charge des cas d’utilisation non interactifs. Cette approche n’est plus recommandée pour de nombreuses raisons, et la meilleure pratique actuelle consiste à utiliser le grant Client Credentials OAuth 2.0 dans ces situations.
Nous offrons un guide de planification en format PDF que vous pouvez télécharger et consulter pour en savoir plus sur les stratégies que nous recommandons.Guide de planification de projet B2C IAM
Authentifier
Gérer les utilisateurs
Personnaliser
Plateforme