Autorisation des utilisateurs et considérations de planification connexes pour votre mise en œuvre de B2B IAM.
Commençons par prendre un peu de recul et parler du contrôle d’accès. Il n’existe pas de définition unique et parfaitement tranchée 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 global qui regroupe l’authentification, l’autorisation, le consentement et la mise en 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 la mise en application des politiques. Votre locataire 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 la mise en application des politiques. De plus, une application ou une API 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 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 propres au contexte.
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 autoriser l’application à accéder à ses données dans un autre système.
Mise en application des politiques : l’application des politiques de l’application ou de l’API, en refusant ou en autorisant l’accès selon les renseignements d’authentification et/ou d’autorisation d’un utilisateur.
En général, nous regroupons les différents types de contrôle d’accès en trois catégories distinctes afin qu’il soit plus facile de comprendre a) quel acteur est responsable du stockage de l’information, b) quel acteur est responsable de la prise de décision, et c) lequel est responsable de l’application des restrictions.
La première catégorie est celle où l’accès à une application ou à une API est accordé ou refusé dans son ensemble. Les données requises pour l’appliquer et 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 est celle 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 requises pour l’appliquer 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 le processus d’application est exécuté dans l’application ou l’API elle-même. Dans ce scénario, les données sont généralement communiquées 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 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 requises pour l’appliquer, 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 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.
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, vous voudrez donc tenir compte d’un certain nombre d’éléments lorsque vous évaluerez les fonctionnalités et le flux de travail dont vous avez besoin :
Existe-t-il des scénarios où l’accès à une application entière ou à une API devrait être refusé ?
Allez-vous fournir des API auxquelles des applications tierces pourront accéder ?
Vos API seront-elles aussi accessibles à vos propres applications (de première partie) ?
Votre application appellera-t-elle une API tierce ?
Vos applications et/ou API devraient-elles appliquer un contrôle d’accès en fonction des claims de l’utilisateur ?
Que faire si j’ai besoin de savoir à quelle organisation un ou un est associé ?
Auth0 prend en charge la restriction d’accès aux applications ou aux API en fonction de certaines conditions. Dans certains cas, vous pouvez vouloir créer une Action qui renvoie une UnauthorizedError 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 les bons claims 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é pour appeler l’API) pourrait être bloquée, comme décrit dans cet exemple.
De façon générale, nous avons constaté que 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 é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 de première partie lorsqu’une API ne partage pas de session avec l’application.
Auth0 peut également 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 ID Token, que votre application peut ensuite vérifier et utiliser pour appliquer des politiques. Dans ce cas, vous devrez déterminer de quels renseignements votre application a besoin pour 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 Jeton d’accès plutôt qu’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 identifiables sensibles (PII, Personally Identifiable Information). Les renseignements contenus dans le jeton ne sont pas chiffrés. Ainsi, même si la divulgation d’un jeton d’identité ne pose 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 ainsi que la reconfiguration des scopes, dans le contexte d’un Jeton d’accès. Encore une fois, vous devrez décider de quels renseignements votre API aura besoin pour 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 billet de blogue à ce sujet, facile à lire et utile pour clarifier la question.
Dans les scénarios impliquant plusieurs organisations, il est souvent important de savoir à quelle organisation un jeton d’accès (ou même un jeton d’identité) s’applique. Le respect des bonnes pratiques peut vous faire gagner du temps et des efforts.
Dans ce scénario, votre locataire Auth0 fournit un jeton attestant l’accès autorisé à une application. Pour les applications qui utilisent OpenID Connect (OIDC), le protocole standard de l’industrie généralement le plus utilisé pour les applications destinées aux clients, il s’agirait d’un ID Token exprimé sous forme de JWT.
Grâce à l’extensibilité d’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 l’ID Token contient les claims requises, 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’Actions est simplifié, Actions restent flexibles et vous permettent d’écrire du code personnalisé qui peut 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 à 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 métadonnées. N’oubliez pas non plus de consulter nos conseils sur les pratiques exemplaires relatives aux métadonnées.
Si vous créez différentes instances de votre application pour les organisations de vos clients, une pratique courante consiste à créer une claim personnalisée dans votre jeton d’identité pour représenter l’organisation de l’utilisateur. Par exemple :
Les Scopes OIDC sont généralement utilisés par une application pour obtenir le consentement nécessaire à l’accès autorisé aux renseignements sur un utilisateur pendant l’authentification. Chaque scope prédéfini renvoie l’ensemble des claims standard, lorsqu’ils sont définis, comme 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és dans l’ID Token et sont également disponibles via le point de terminaison /userinfo.
Dans ce scénario, votre locataire Auth0 peut fournir un jeton d’accès OAuth2, généralement présenté sous la forme d’un JWT, que votre API peut utiliser pour restreindre l’accès à certains acteurs. De plus, Auth0 prend en charge ce qu’on appelle généralement les applications propriétaires et les applications tierces.En agissant comme serveur d’autorisation, et avec le consentement de l’utilisateur (le propriétaire de la ressource), votre locataire Auth0 peut servir à 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, à des ressources protégées hébergées 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 peut-être un ensemble 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 à vos services. Bien qu’il soit relativement facile de configurer cela dans l’Auth0 Dashboard ou au moyen de la Auth0 Management API, il est important d’examiner les différents scénarios d’application et architectures d’API pour déterminer l’architecture la mieux adaptée à votre système.
Les jetons d’accès OAuth2 sont principalement conçus pour sécuriser les API exposées publiquement ; lorsqu’il est présenté sous forme de JWT, un jeton d’accès est une entité autonome qui peut être vérifiée sans avoir à effectuer d’appel API supplémentaire à un tiers. Si vos API ne correspondent pas à 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 au moyen de jetons pourrait s’avérer excessif, et votre flux de travail actuel fondé sur des témoins (et autres mécanismes semblables) pourrait suffire.
OAuth2 a été conçu précisément en tenant compte de l’accès par des tiers. Par exemple, un scénario possible est qu’un utilisateur (propriétaire de la ressource) veuille 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ù résident les données de l’utilisateur, qui authentifie alors l’utilisateur, puis l’invite à autoriser l’application à accéder à ses données. Cette demande d’autorisation est appelée consentement et constitue une part importante 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 consultées, 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 d’afficher à vos utilisateurs des é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 applications 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, donc vos utilisateurs seront quand même invités à donner leur consentement. Pour contourner cette contrainte, lorsque vous testez 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 des Actions d’Auth0. Une fois ajoutées, votre API peut vérifier qu’un Jeton d’accès contient les claims requises, puis autoriser ou empêcher 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 de contrôle d’accès que vous pourriez devoir inclure dans ces 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 à la capacité de mise à l’échelle. 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 bonnes pratiques relatives aux métadonnées.
Les scopes OAuth2 sont généralement utilisés comme mécanisme permettant à une API de déterminer quelles actions peuvent être effectué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 ). 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 devraient dépendre des fonctionnalités pour lesquelles l’utilisateur doit accorder son autorisation à l’application. 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 le cas où vous ouvrez une session dans 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 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 rôle d’un utilisateur et doit être traité différemment.
Même si vous pouvez manipuler entièrement les scopes du Jeton d’accès au moyen de l’extensibilité d’Auth0, par bonne pratique de sécurité, vous ne devriez retirer que les scopes non autorisés et vous abstenir d’ajouter des scopes qui n’ont pas été demandés.
Bien que les scopes soient souvent utilisés comme moyen d’appliquer des autorisations d’accès pour un utilisateur, il existe des situations où cela peut devenir délicat lorsqu’ils sont utilisés de cette façon. Nous recommandons donc d’utiliser les scopes conformément à leur objectif (c.-à-d. déléguer une autorisation à une application) et d’utiliser des claims personnalisées pour vos scénarios de contrôle d’accès fondé 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 ce qui suit :
le rôle d’un utilisateur au sein d’une organisation, comme editor ou admin
un attribut de l’utilisateur ou de l’objet, comme manager pour un utilisateur ou marketing pour un objet
une relation entre un utilisateur et un objet; par exemple, un utilisateur ayant accès en lecture à un dossier parent a aussi accès en lecture au dossier enfant
Avec , vous pouvez créer un modèle d’autorisation pour définir les relations qui déterminent l’accès des utilisateurs.
Auth0 offre une prise en charge prête à l’emploi du contrôle d’accès basé sur les rôles (RBAC). Le RBAC consiste à attribuer des autorisations aux utilisateurs en fonction de leur rôle au sein d’une organisation et simplifie le contrôle d’accès en proposant une approche plus facile à administrer et moins sujette aux erreurs.La fonctionnalité RBAC de base peut être utilisée dans de nombreux scénarios multi-organisations. Consultez les données d’organisation dans un jeton d’accès pour en savoir plus sur la façon de vous assurer que votre configuration peut répondre à vos besoins en matière de RBAC.
De nombreux scénarios exigent qu’une application sans session utilisateur interactive 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 fournit le type d’octroi client credentials, ce qui simplifie grandement les choses. Voici quelques exemples courants où cela s’applique :
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 doit parfois être appelée avant qu’un utilisateur soit authentifié (c.-à-d. à partir d’une Action ou d’un script de base de données 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 sans interaction. Cette approche n’est plus recommandée pour de nombreuses raisons, et la bonne pratique actuelle consiste à utiliser OAuth 2.0 Client Credentials Grant dans ces situations.
Si vous avez dans votre système une API distincte de votre application qui prend en charge votre application multi-organisation, il est important de limiter les opérations uniquement à l’organisation pour laquelle le jeton a été généré. Cela signifie que le jeton d’accès doit contenir une forme d’information permettant d’indiquer à l’API pour quelle organisation il a été émis. Vous pouvez le faire de différentes façons, selon les réponses à quelques questions simples :
Les utilisateurs finaux de cette organisation pourraient-ils appartenir à plus d’une organisation, ou chaque utilisateur final est-il rattaché à une seule organisation précise ?
Autoriserez-vous un accès Machine-to-Machine (M2M) à votre API ?
Si vous autorisez un accès Machine-to-Machine (M2M) à votre API, aurez-vous des développeurs qui ont besoin d’un seul ID client et secret pour accéder à plusieurs organisations (mais pas à toutes les organisations) ?
Autoriserez-vous la création d’applications tierces qui exigent un consentement ?
Si les utilisateurs finaux sont rattachés à une seule organisation et que vous n’autoriserez pas l’accès M2M à votre API, ou que vous aurez un /secret distinct pour chaque organisation qui a besoin d’un accès et que vous n’autoriserez pas les applications tierces qui exigent un consentement, alors l’approche la plus simple consiste à créer une revendication personnalisée dans le jeton d’accès à l’aide d’Actions pour les jetons basés sur l’utilisateur et à l’aide du hook client credentials pour les appels M2M. Vous pouvez stocker le nom de l’organisation dans les métadonnées de l’application et l’extraire à partir d’Actions ou de hooks afin de l’inclure dans access_token comme revendication personnalisée. Le RBAC fonctionnera également tel quel avec cette approche, tant que chaque utilisateur final ne peut appartenir qu’à une seule organisation.Si les utilisateurs finaux peuvent appartenir à plus d’une organisation, ou si vous pourriez fournir à un même développeur un ID client et un secret pour des appels M2M vers plus d’une organisation, la meilleure approche consiste à créer une distincte (une instance d’API distincte dans votre locataire Auth0) pour chaque organisation. Cela vous donne quelques avantages intéressants :
D’abord, cela vous permet de transmettre l’audience comme paramètre natif à Auth0 sans avoir à créer de paramètre personnalisé. L’avantage, c’est qu’Auth0 vous aidera à en valider la présence et la transmettra à vos Actions. Cela garantit aussi qu’un jeton d’actualisation émis ne fonctionnera que pour l’audience précise à laquelle il a été initialement émis.
Cela vous permet de restreindre les client grants à certaines organisations, sans configuration supplémentaire. L’autre option consiste à créer un hook client credentials plus complexe pour tenter de récupérer ces restrictions ailleurs, tout en exigeant une façon beaucoup plus complexe et potentiellement problématique d’indiquer à l’appel client credentials pour quelle organisation émettre le jeton d’accès.
Cela vous permet aussi d’utiliser la fonctionnalité RBAC de base avec Auth0 et de vous assurer que les utilisateurs finaux qui ont accès à plus d’une organisation peuvent avoir un rôle différent pour chaque organisation.
Nous mettons à votre disposition 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 du projet B2B IAM
De nombreuses plateformes B2B mettent en place une forme d’isolation et/ou d’image de marque pour les organisations de leurs clients, ce qui peut complexifier tout système de gestion des identités et des accès (IAM). Si c’est votre cas, nous vous recommandons de prendre le temps de consulter nos conseils et nos pratiques exemplaires pour ce type d’environnement.Architecture multi-organisation
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme