Autorisation de l’utilisateur et considérations de planification connexes pour votre implémentation IAM B2C.
Commençons par prendre un peu de recul et parlons du contrôle d’accès. Il n’existe pas de définition unique et universelle du contrôle d’accès dans l’industrie, 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 général 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 distinctions 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, en particulier 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 autorisations qui lui ont été accordées et/ou de l’ensemble des critères d’accès contextuels applicables.
Consentement : les autorisations 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 à l’application l’autorisation d’accéder à ses données dans un autre système.
Application des politiques : l’application des politiques de l’application ou de l’API, qui consiste à refuser ou à autoriser l’accès selon les renseignements d’authentification et/ou d’autorisation d’un utilisateur.
En règle 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 du stockage de l’information, b) quel acteur est responsable de la prise de décisions, et c) quel acteur est responsable de l’application des restrictions.
La première catégorie correspond aux cas où l’accès à une application ou à une API est accordé ou refusé dans son ensemble. Les données nécessaires à cette application, ainsi que le processus d’application lui-même, sont généralement définis dans le contexte du serveur d’autorisation. Par exemple, en utilisant app_metadata associé à un utilisateur et une Action définie dans votre locataire Auth0.
La deuxième catégorie correspond aux cas où l’accès à un sous-ensemble précis des fonctionnalités d’une application ou d’une API est accordé ou refusé. Les données nécessaires à cette application sont généralement stockées dans le serveur d’autorisation. Par exemple, en utilisant app_metadata pour un utilisateur dans votre locataire Auth0, tandis que l’application des règles 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 forme d’une ou de plusieurs revendications personnalisées dans un jeton id ou access.
La troisième catégorie correspond aux cas où l’accès est accordé ou refusé selon ce sur quoi le principal (sujet) peut agir dans le contexte d’une application ou d’une API. Les données nécessaires à cette application, ainsi que le processus d’application lui-même, sont généralement définis dans le contexte de l’application ou de l’API. Dans ce scénario, les données transmises sous forme d’une ou de plusieurs revendications 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.
De plus, 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, il y a donc un certain nombre d’éléments à prendre en compte lorsque vous évaluez les fonctionnalités et le flux de travail dont vous avez besoin :
Existe-t-il des scénarios où l’accès à une application ou à une API entière devrait être refusé ?
Offrirez-vous des API accessibles par des applications tierces ?
Vos API seront-elles aussi accessibles par vos propres applications (de première partie) ?
Votre application appellera-t-elle une API tierce ?
Vos applications et/ou API devraient-elles appliquer le contrôle d’accès en fonction des revendications de l’utilisateur ?
Auth0 prend en charge la restriction d’accès aux applications ou aux API selon certaines conditions. Dans certains cas, vous pouvez 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 ne possède pas les appropriés dans son app_metadata. Pour une application qui utilise OpenID Connect (OIDC), cela empêcherait l’émission de l’ID Token servant à autoriser l’accès. De même, pour une API, l’émission de tout jeton OAuth2 Jeton d’accès (utilisé lors de l’appel de 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 normalisé de l’industrie le plus couramment utilisé par les clients d’Auth0 pour l’authentification dans leurs applications. Nous avons également constaté que, même si OAuth2 a été conçu comme un protocole de délégation, il est couramment utilisé dans les applications propriétaires lorsqu’une API ne partage pas de session avec l’application.
Auth0 peut aussi fournir les renseignements nécessaires 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és à un , que votre application peut ensuite vérifier et utiliser pour appliquer des politiques. Dans ce cas, vous devrez déterminer quels renseignements sont nécessaires pour que votre application puisse prendre des décisions d’application des politiques. 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 jeton d’identité. Poursuivez votre lecture pour en savoir plus.
Lorsque vous décidez quelles données inclure dans votre jeton d’identité et/ou votre jeton d’accès, tenez compte de la taille du jeton, surtout si vous le transmettez 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 renseignements personnels sensibles (PII, Personally Identifiable Information). Les renseignements contenus dans le jeton ne sont pas chiffrés; ainsi, bien qu’une fuite d’un ID Token ne constitue généralement pas un problème de sécurité, elle 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és et la reconfiguration des scopes, les deux dans le contexte d’un Jeton d’accès. Encore une fois, vous devrez déterminer quels renseignements seront nécessaires pour permettre à votre API de prendre des décisions d’accès, et votre API devra les appliquer en validant le contenu du Jeton d’accès.
Lorsque vous déterminez si vous devriez utiliser des autorisations au moyen de claims personnalisés ou de scopes, vous devez vous assurer 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 locataire 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 considérons généralement comme le plus utilisé pour les applications destinées aux clients, il s’agirait d’un ID Token présenté sous forme de JWT.
Grâce à l’extensibilité Action, Auth0 vous permet d’ajouter facilement des claims personnalisés à un ID Token en fonction, par exemple, du contenu des métadonnées d’un utilisateur. Votre application peut ensuite vérifier que l’ID Token contient les claims requis, 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és au moyen d’Action est simplifié, l’environnement d’exécution d’Action est flexible et vous permet d’écrire du code personnalisé qui peut avoir des effets négatifs.
Si vous envisagez d’ajouter des claims personnalisés, 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 à appeler une API externe pour récupérer ces données, ce qui peut nuire aux performances et à l’évolutivité du processus 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 pratiques exemplaires relatives aux métadonnées.
Les Scopes OIDC sont généralement utilisés par une application pour obtenir le consentement à l’accès autorisé aux renseignements d’un utilisateur lors de l’authentification. Chacun des scopes prédéfinis renvoie l’ensemble des claims standard, lorsqu’elles sont définies, comme il est indiqué dans la spécification OIDC. Les scopes qu’une application demande dépendent des attributs utilisateur dont elle a besoin. Une fois les scopes demandés autorisés par l’utilisateur, les claims sont renvoyées dans l’ID Token et sont également accessibles par l’intermédiaire du point de terminaison /userinfo.
Dans ce scénario, votre locataire Auth0 peut fournir un OAuth2 Jeton d’accès, généralement présenté sous la forme d’un JWT, que votre API peut utiliser pour restreindre l’accès à certaines entités. De plus, Auth0 prend en charge ce qu’on appelle généralement les applications propriétaires et tierces.En agissant comme serveur d’autorisation, et avec le consentement de l’utilisateur (le propriétaire de la ressource), votre locataire Auth0 peut fournir un Jeton d’accès - généralement présenté sous la forme d’un JWT - à une application (client) afin qu’elle puisse accéder, au nom du propriétaire de la ressource, à une ressource protégée hébergée par un . 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 un ensemble d’API de microservices liées logiquement, vous pouvez tirer parti des Jetons d’accès fournis par Auth0 pour sécuriser l’accès à vos services. Bien qu’il soit relativement simple de configurer cela dans le Auth0 Dashboard ou au moyen de la Auth0 Management API, il est important d’examiner les différents scénarios d’application et les différentes architectures d’API afin de déterminer la meilleure architecture pour votre système.
Les jetons d’accès OAuth2 sont principalement conçus pour sécuriser des API exposées 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 devoir effectuer d’appel supplémentaire à une API tierce. Si vos API n’entrent pas dans cette catégorie - c.-à-d. qu’elles font partie de l’application elle-même (autrement dit, elles ne sont appelées que par cette application) ou qu’elles se trouvent derrière votre pare-feu - les protéger à l’aide de jetons pourrait être excessif, et votre flux de travail actuel basé sur des cookies (entre autres) pourrait très bien suffire.
OAuth2 a été conçu précisément en tenant compte de l’accès 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 les données de l’utilisateur (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, qui authentifie alors l’utilisateur puis lui demande d’autoriser l’application à accéder à ses données. Cette demande d’autorisation est appelée 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.En revanche, si votre organisation possède les applications, les données utilisateur elles-mêmes et les API par lesquelles ces données sont consultées, le consentement n’est généralement pas requis, puisque les interactions sont toutes propriétaires. Si vous créez uniquement des applications propriétaires, vous pouvez vous assurer de ne pas présenter à vos utilisateurs d’écrans de consentement inutiles en autorisant l’omission du consentement de l’utilisateur dans la définition de tout serveur de ressources.
Bien que vous puissiez configurer vos applications comme propriétaires, puis configurer vos API pour permettre aux clients propriétaires d’ignorer le consentement, si vous utilisez localhost, Auth0 ne peut pas vérifier que l’application est réellement une application propriétaire; vos utilisateurs seront donc quand même invités à donner leur consentement. Pour contourner cette contrainte, lorsque vous effectuez 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és aux jetons d’accès à l’aide de l’extensibilité des Actions Auth0. Une fois ajoutés, votre API peut vérifier qu’un jeton d’accès contient les claims requis, puis autoriser ou refuser l’accès à certaines fonctionnalités, selon le cas.
Si vous envisagez d’ajouter des claims personnalisés, 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’appeler une API externe pour récupérer ces données, ce qui peut nuire aux performances et à l’évolutivité. 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 métadonnées. N’oubliez pas non plus de consulter nos conseils sur les pratiques exemplaires en matière de métadonnées.
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és pour chaque API afin de définir des autorisations d’accès précises dans le ou au moyen de la d’Auth0. Les scopes peuvent aussi être modifiés 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 doivent dépendre des fonctionnalités pour lesquelles l’utilisateur consent à ce que l’application les utilise. Une fois les scopes demandés autorisés, ils sont renvoyés dans le Jeton d’accès, qui peut ensuite être vérifié par l’API en question. Un bon exemple est lorsque vous ouvrez une session dans 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 qu’elle publie du contenu en son nom. Cela permet à l’utilisateur d’accepter ou de refuser cette demande. Cet exemple montre comment l’utilisateur délègue une autorisation à l’application — ce qui diffère d’une API qui restreint l’accès selon le de l’utilisateur, et cela doit être géré autrement.
Bonne pratiqueMême si vous pouvez manipuler entièrement les scopes du Jeton d’accès au moyen de l’extensibilité d’Auth0, comme bonne pratique de sécurité, vous devriez seulement supprimer les scopes qui ne sont pas autorisés et vous abstenir d’ajouter des scopes qui n’ont pas été demandés.
Bien que les scopes soient souvent utilisés pour appliquer des autorisations 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 conformément à leur objectif (c.-à-d. déléguer une autorisation à une application) et d’utiliser des revendications personnalisées pour vos scénarios de contrôle d’accès basé sur les rôles ou autres.
L’autorisation granulaire vous permet d’accorder à des utilisateurs individuels l’accès à une ressource ou à un objet précis en fonction de :
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 un accès en lecture à un dossier parent a aussi un accès en lecture au dossier enfant
Avec , vous pouvez créer un modèle d’autorisation pour définir quelles relations déterminent l’accès des utilisateurs.
Auth0 prend en charge nativement le contrôle d’accès basé sur les rôles (RBAC). Le RBAC consiste à attribuer des autorisations 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.
De nombreux scénarios exigent qu’une application sans session interactive utilisateur obtienne un jeton d’accès afin d’appeler une API. Dans ce type de scénario, vous devez authentifier l’application plutôt que l’utilisateur, et 2 offre le type d’octroi client credentials, ce qui facilite grandement la tâche. Voici quelques exemples courants où cela s’avère nécessaire :
Une tâche cron ou un autre service qui doit communiquer avec votre API (par 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é (par ex. l’API n’est pas exposée directement aux utilisateurs, mais uniquement au 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 du jeton d’un utilisateur.
Une API privilégiée qui peut devoir être appelée avant qu’un utilisateur ne se soit authentifié (c.-à-d. à partir d’une Action ou d’un script DB personnalisé dans votre locataire Auth0)
Traditionnellement, un « compte de service » spécial était créé pour répondre à ces scénarios : un utilisateur doté d’un nom d’utilisateur et d’un mot de passe, configuré 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 pratique exemplaire actuelle consiste à utiliser l’octroi Client Credentials d’OAuth 2.0 dans ces situations.
Nous offrons un guide de planification au 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
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme