Passer au contenu principal
Commençons par prendre du recul et parler du Contrôle d’accès. Il n’existe pas de définition unique du Contrôle d’accès dans l’industrie, mais si vous prenez le temps de chercher et de lire, vous constaterez que la plupart des sources autorisées s’accordent à dire qu’il s’agit du concept global qui rassemble l’authentification, l’autorisation, le consentement et l’application des politiques pour garantir que seules les personnes habilitées et les services appropriés ont accès à vos applications et API. Ensuite, examinons de plus près les distinctions entre l’authentification, l’autorisation, le consentement et l’application des politiques. Votre locataire Auth0, (votre serveur d’autorisations), est généralement responsable de l’authentification et du consentement, ainsi que de tout ou partie des autorisations et de l’application des politiques. De plus, une application ou une API est presque toujours le principal responsable de l’application des politiques, surtout lorsque un accès contextuel est requis :
  • Authentification : processus visant à déterminer si une entité principale (un utilisateur ou une application) est bien celle ou ce qu’elle prétend être.
  • Autorisation : le processus de détermination de ce qui est autorisé, en fonction des règles principales, des permissions qui lui ont été accordées et/ou de l’ensemble des critères d’accès spécifiques en contexte.
  • Consentement : les permissions que l’utilisateur (propriétaire des ressources) 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 la permission au Client pour qu’il accède aux données de l’utilisateur dans un autre système.
  • Application des politiques : L’acte d’appliquer les politiques de l’application ou de l’API, en rejetant ou en autorisant l’accès en fonction des informations d’authentification et/ou d’autorisation d’un utilisateur.
En général, nous regroupons différents types de contrôle d’accès en trois catégories distinctes dans le but de faciliter la compréhension : a) quel acteur est responsable du stockage des informations, 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 est celle où l’accès est soit accordé, soit refusé à une application ou une API dans son intégralité. Les données nécessaires pour appliquer cette catégorie et le processus d’application sont généralement définis dans le contexte du serveur d’autorisations, par exemple, en utilisant app_metadata associée à un utilisateur et une règle définie dans votre locataire Auth0.
  • La deuxième catégorie est celle où l’accès est soit accordé, soit refusé à un sous-ensemble spécifique des fonctionnalités de l’application ou de l’API. Les données nécessaires pour l’application de cette catégorie sont généralement stockées dans le serveur d’autorisations. Par exemple, en utilisant app_metadata sur un utilisateur dans votre locataire Auth0, avec le processus d’application s’exécutant dans l’application ou l’API elle-même. Dans ce scénario, les données sont généralement communiquées sous forme d’une ou de plusieurs demandes personnalisées dans un id ou un jeton d’access
  • La troisième catégorie est celle où l’accès est soit accordé, soit refusé en fonction de ce sur quoi le principal (sujet) peut agir dans le contexte d’une application ou d’une API. Les données nécessaires pour appliquer cette catégorie, ainsi que le processus d’application, sont généralement définis dans le contexte de l’application ou de l’API. Dans ce scénario, les données communiquées sous forme d’une ou de plusieurs demandes dans un id ou un jeton d’access peuvent être utilisées avec ou sans données provenant d’une source externe autre que 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 chacune des catégories de contrôle d’accès décrites ci-dessus. Quoi qu’il en soit, il y a plusieurs éléments que vous voudrez prendre en compte lorsque vous examinez les fonctionnalités et le flux de travail dont vous avez besoin :
  • Y a-t-il des cas où l’accès à une application ou une API entière devrait être refusé ?
  • Fournirez-vous des API qui peuvent être accessibles par des applications tierces ?
  • Vos API seront-elles également accessibles par vos propres applications (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 demandes des utilisateurs ?
Auth0 prend en charge les restrictions d’accès pour les applications ou les API en fonction de certaines conditions. Dans certains scénarios, vous pourrez vouloir créer une règle qui renvoie une UnauthorizedError lorsque, par exemple, un utilisateur tente d’accéder à une application ou à une API à un moment inapproprié (comme décrit dans cet exemple), ou si l’utilisateur ne possède pas les bonnes demandes contenues dans ses app_metadata. Pour une application utilisant OpenID Connect (OIDC), cela empêcherait l’attribution du jeton d’ID utilisé pour autoriser l’accès. De même, pour une API, l’attribution de tout jeton d’accès OAuth2 (utilisé lors de l’appel de l’API), pourrait être empêchée, comme décrit dans cet exemple.

​
Meilleure pratique Dans l’ensemble, nous avons constaté que OIDC est le protocole standard le plus couramment utilisé par les clients d’Auth0 lorsqu’il s’agit d’authentification dans leurs applications. Nous avons également constaté que, même si [OAuth2] (protocols/oauth2) a été créé en tant que protocole de délégation, il est couramment utilisé dans les applications de première partie lorsqu’il existe une API qui n’a pas de session partagée avec l’application. :::

Auth0 peut également fournir les informations 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 demandes personnalisées à un jeton d’ID, que votre application peut ensuite vérifier et utiliser pour appliquer des politiques. Dans ce cas, vous allez devoir décider quelles informations sont nécessaires pour que votre application prenne des décisions d’application. Si vous devez prendre des décisions au niveau de l’API plutôt que dans votre application, vous allez devoir probablement utiliser un jeton d’accès au lieu d’un jeton d’ID. Poursuivez la lecture pour plus d’informations.
Au moment de décider des données à inclure dans votre jeton d’ID et/ou votre jeton d’accès, tenez compte de la taille du jeton, en particulier si vous transmettez le jeton dans l’URL. Même si vous ne transmettez pas de jetons dans l’URL, vous devez également prendre en compte le risque d’exposer des informations personnelles identifiables (Personally Identifiable Information/PII) sensibles. Les informations contenues dans le jeton ne sont pas chiffrées. Par conséquent, bien que la fuite d’un jeton d’ID ne pose généralement pas de problème de sécurité, elle peut devenir un problème de confidentialité en fonction des données incluses dans le jeton.
Pour l’intégration au niveau de l’API, Auth0 prend en charge à la fois les demandes personnalisées et la reconfiguration des permissions , le tout dans le contexte d’un jeton d’accès. Encore une fois, vous allez devoir décider quelles informations seront nécessaires pour que votre API prenne des décisions d’accès, et votre API devra appliquer cela en validant le contenu du jeton d’accès.

​
Meilleure pratique

Lorsque vous décidez d’utiliser des permissions par le biais de demandes personnalisées ou de permissions, assurez-vous de bien comprendre la nature et l’objectif des permissions. Il y a un bon [article de blog] (https://auth0.com/blog/on-the-nature-of-oauth2-scopes/) à ce sujet, qui est facile à lire et qui permet de clarifier le sujet.

​
Intégration de l’application

Dans ce scénario, votre locataire Auth0 fournit un jeton comme indicateur d’accès autorisé à une application. Pour les applications utilisant OpenID Connect (OIDC), le protocole standard de l’industrie généralement le plus utilisé pour les applications destinées aux clients serait un jeton d’ID exprimé sous forme de JWT.

​
Demandes relatives aux jetons d’ID

En utilisant l’extensibilité des règles, Auth0 vous permet de facilement ajouter des demandes personnalisées à un jeton d’ID en fonction, par exemple, du contenu des métadonnées d’un utilisateur. Votre application peut ensuite vérifier le jeton d’ID pour les demandes nécessaires et soit autoriser, soit empêcher l’accès à certaines fonctionnalités selon les besoins. Notez que, bien que le processus d’ajout de revendications personnalisées via les règles soit simplifié, le moteur des règles est flexible et vous permet d’élaborer du code personnalisé qui peut avoir des effets négatifs. Il est donc important de suivre nos conseils sur les meilleures pratiques en matière de règles chaque fois que vous utilisez cette fonctionnalité d’extensibilité.

​
Meilleure pratique Lorsque vous envisagez d’ajouter des demandes personnalisées, nous vous conseillons de stocker toutes les données de contrôle d’accès que vous pourriez avoir besoin d’inclure dans les demandes de la [app_metadata] de l’utilisateur (/users/concepts/overview-user-metadata). Tout d’abord, cela vous évite d’avoir à appeler une API externe pour récupérer les données, ce qui peut avoir un impact négatif sur les performances et l’évolutivité de la séquence de connexion. Ensuite, les app_metadata ne peuvent pas être modifiées par un utilisateur - l’utilisateur 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 [meilleures pratiques en matière de métadonnées] (/architecture-scenarios/b2c/profile-management#metadata). :::

​
Permissions relatives aux jetons d’ID

Lespermissions OIDC sont généralement utilisées par une application pour obtenir le consentement pour un accès autorisé aux détails d’un utilisateur lors de l’authentification. Chacune des permissions prédéfinies renvoie l’ensemble des revendications standard là où elles sont définies, comme décrit dans la spécification OIDC. Les permissions qu’une application demande dépendent des attributs de l’utilisateur dont l’application a besoin. Une fois que les permissions demandées sont accordées par l’utilisateur, les demandes sont renvoyées dans le jeton d’ID et sont également accessibles via le point de terminaison /userinfo

​
Intégration de l’API

Dans ce scénario, votre locataire Auth0 peut fournir un jeton d’accèsOAuth2, généralement exprimé sous forme de JWT, qui peut être utilisé par votre API pour restreindre l’accès à certaines parties. De plus, Auth0 prend en charge ce qui est théoriquement décrit comme Applications de première et de tierce parties. Agissant comme serveur d’autorisations, et avec le consentement de l’utilisateur (le propriétaire des ressources), votre locataire Auth0 peut être utilisé pour fournir un jeton d’accès (généralement exprimé sous forme de JWT ) à une application (client) afin qu’elle puisse accéder à des ressources protégées hébergées par un serveur de ressources au nom du propriétaire des ressources. Le jeton d’accès émis est généralement transmis en tant que jeton du porteur dans l’en-tête d’autorisation HTTP envoyé à une API. Que vous ayez une seule API ou peut-être une suite de microservices API liés de manière logique, 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 facile de configurer cela dans Auth0 Dashboard ou via la Management API Auth0, il est important d’examiner les différents scénarios d’application et les structures des API pour déterminer la meilleure architecture pour votre système.
Les jetons d’accès OAuth2 sont principalement conçus pour sécuriser les API publiques; lorsqu’il est exprimé 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 supplémentaire à une API tierce. Si vos API n’entrent pas dans cette catégorie – par exemple, si elles font partie d’une application (c’est-à-dire qu’elles ne sont appelées que par cette application) ou qu’elles sont placées derrière votre pare-feu – alors les protéger avec des jetons peut s’avérer excessif, et votre flux de travail actuel basé sur les témoins (et autres) peut suffire.
OAuth2 a été conçu spécifiquement en tenant compte de l’accès de tiers. Par exemple, un scénario pourrait être qu’un utilisateur (propriétaire des ressources) souhaite 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 a besoin d’accéder aux données que possède l’utilisateur, elle redirige vers l’organisation où se trouvent les données de l’utilisateur, qui authentifie ensuite l’utilisateur et l’invite à donner à l’application la permission d’accéder à ses données. Cette demande de permission est appelée fourniture de consentement et constitue une grande partie de ce que signifie apporter un soutien aux applications tierces. Si vous prévoyez d’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 accessibles, alors le consentement n’est généralement pas nécessaire, car toutes les interactions sont de première partie. Si vous ne créez que des applications de première partie, vous pouvez vous assurer de ne pas présenter à vos utilisateurs des écrans de consentement inutiles en permettant d’omettre la partie réservée au consentement de l’utilisateur dans le cadre de toute définition de service de ressources.
Bien que vous puissiez configurer vos applications pour qu’elles soient de premier niveau et ensuite configurer vos API pour permettre aux clients de premier niveau d’ignorer le consentement, si vous utilisez localhost , Auth0 ne peut pas vérifier que l’application est réellement une application de premier niveau : vos utilisateurs seront donc tout de 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.
Alternativement, vous pouvez avoir des données relatives à un utilisateur pour lesquelles des fonctionnalités supplémentaires sont fournies et pour lesquelles un consentement d’utilisateur explicite ne peut pas être obtenu (c’est-à-dire qu’il n’y a pas d’utilisateur authentifié qui puisse le fournir). Dans ce scénario, une liste d’applications pour lesquelles l’octroi des identifiants client est activé peut être définie.

​
Demandes relatives aux jetons d’accès

Comme c’est le cas avec les jetons d’ID, vous pouvez ajouter des demandes personnalisées aux jetons d’accès en utilisant l’extensibilité des règles Auth0. Une fois ajoutée, votre API peut ensuite vérifier un jeton d’accès pour les demandes nécessaires et soit autoriser, soit empêcher l’accès à certaines fonctionnalités selon les besoins.

​
Meilleure pratique Lorsque vous envisagez d’ajouter des demandes personnalisées, nous vous conseillons de stocker toutes les données de contrôle d’accès que vous pourriez avoir besoin d’inclure dans les demandes des [app_metadata] de l’utilisateur (/users/concepts/overview-user-metadata). Tout d’abord, cela vous évite d’avoir à appeler une API externe pour récupérer les données, ce qui peut avoir un impact négatif sur les performances et l’évolutivité. Ensuite, les app_metadata ne peuvent pas être modifiées par un utilisateur : l’utilisateur 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 [meilleures pratiques en matière de métadonnées] (/architecture-scenarios/b2c/profile-management#metadata) :::

​
Permissions des jetons d’accès

Lespermissions OAuth2 sont généralement utilisées comme le mécanisme par lequel une API peut déterminer les actions susceptibles d’être effectuées au nom d’un utilisateur. Les permissions peuvent être ajoutées pour chaque API afin de définir des permissions d’accès spécifiques dans le ou via Auth0. Les permissions peuvent également être manipulées via l’extensibilité d’Auth0 (par exemple, via une règle, comme dans cet exemple). Les permissions qu’une application nécessite pour accéder à une API devraient dépendre des fonctionnalités pour lesquelles l’application a besoin que l’utilisateur donne l’autorisation de les utiliser. Une fois que les permissions demandées sont autorisées, elles seront renvoyées dans le jeton d’accès qui pourra ensuite être vérifié par ladite API. Un bon exemple de cela est lorsque vous vous connectez à une application qui utilise un fournisseur social pour la connexion : l’API du fournisseur social exige que l’application précise si l’utilisateur souhaite que l’application publie des éléments en son nom. Cela permet à l’utilisateur d’accepter ou de refuser cette demande. Cet exemple présente comment l’utilisateur délègue une autorisation à l’application, ce qui est différent de l’API qui restreint l’accès en fonction du rôle d’un utilisateur, et cela devrait être géré différemment.

​
Meilleure pratique

Même si vous avez la possibilité de manipuler entièrement les permissions des jetons d’accès grâce à l’extensibilité d’Auth0, la meilleure pratique en matière de sécurité consiste à ne supprimer que les permissions qui ne sont pas autorisées et à ne pas ajouter de permissions qui n’ont pas été demandées. Bien que les permissions soient souvent utilisées comme un moyen d’appliquer des permissions d’accès pour un utilisateur, il existe des situations où cela peut devenir problématique lorsque vous les utilisez de cette manière. Nous recommandons donc d’utiliser les permissions pour leur usage prévu (c’est-à-dire déléguer des autorisations à une application) et d’utiliser des demandes personnalisées pour vos scénarios de contrôle d’accès basés sur les rôles ou autres.

​
Autorisation affinée

L’autorisation affinée vous permet d’accorder à des utilisateurs individuels l’accès à une ressource ou un objet spécifique en fonction de ce qui suit :
  • Le rôle d’un utilisateur au sein d’une organisation, tel qu’un editor ou un admin
  • Un attribut de l’utilisateur ou de l’objet, tel que manager pour un utilisateur ou marketing pour un objet
  • Une relation entre un utilisateur et un objet, par exemple un utilisateur disposant d’un accès en visualisation à un dossier parent dispose également d’un accès en visualisation au dossier enfant
Avec , vous pouvez créer un modèle d’autorisation pour déterminer la relation avec laquelle vous souhaitez déterminer l’accès des utilisateurs.

​
RBAC (Contrôle d’accès basé sur les rôles)

Auth0 permet le contrôle d’accès basé sur les rôles(RBAC). RBAC fait référence à l’attribution d’autorisation aux utilisateurs en fonction de leur rôle au sein d’une organisation, et offre un contrôle d’accès plus simple en proposant une approche plus gérable, moins sujette à erreur.

​
Autorisation machine-machine (M2M)

Il existe de nombreux scénarios qui nécessitent qu’une application sans session utilisateur interactive obtienne un jeton d’accès afin d’appeler une API. Dans de tels scénarios, vous devez authentifier le client au lieu de l’utilisateur, et 2 fournit le type d’octroi des identifiants client pour faciliter le processus. Quelques exemples courants où cela est nécessaire :
  • Un job cron ou un autre service qui doit communiquer avec votre API (par exemple, lorsqu’un rapport quotidien doit être généré et envoyé par courriel à un administrateur).
  • Une API distincte qui prend en charge l’accès privilégié (par exemple, l’API n’est pas exposée directement aux utilisateurs, mais uniquement à un système dorsal).
  • Dans certaines architectures de microservices, où certaines couches d’API doivent communiquer avec d’autres sans l’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 ne se soit authentifié (c’est-à-dire à partir d’une règle ou d’un script de base de données personnalisé dans votre locataire Auth0).

​
Meilleure pratique Traditionnellement, un « compte de service » spécial aurait été créé pour répondre à ces scénarios : un utilisateur avec un nom d’utilisateur et un mot de passe configurés pour les services qui prenaient en charge des cas d’utilisation non interactifs. Cette approche n’est plus conseillée pour de nombreuses raisons, et la meilleure pratique actuelle est d’utiliser le OAuth 2.0 Client Credentials Grant (Octroi d’identifiant client OAuth 2.0 dans ces situations. :::

​
Guide de planification de projet

Nous fournissons un guide de planification en format PDF que vous pouvez télécharger; vous pouvez vous y référer pour de plus amples détails concernant nos stratégies recommandées. B2C IAM Project Planning Guide