Autorisation (B2B)

Commençons par prendre un peu de recul et parlons du contrôle d’accès. Il n’existe pas de définition claire du contrôle d’accès, mais si vous prenez le temps de chercher et de lire, vous verrez que la plupart des sources faisant autorité s’accordent à dire qu’il s’agit du concept général qui regroupe l’authentification, l’autorisation, le consentement et l’application des politiques pour garantir que seuls les personnes et les services appropriés ont accès à vos applications et à vos 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’autorisation), est généralement responsable de l’authentification et de tout ou partie de l’autorisation et de l’application des politiques. En outre, une application ou une API elle-même est presque toujours la première responsable de l’application des politiques, en particulier lorsqu’un accès contextuel est nécessaire :

• Authentification : le processus consistant à déterminer si le demandeur (un utilisateur ou une application) est bien celui ou celle qu’il/elle prétend être.

• Autorisation : le processus consistant à déterminer ce qui est autorisé, selon le demandeur, les autorisations qui lui ont été accordées et/ou l’ensemble des critères d’accès spécifiques au contexte.

• Consentement : les autorisations que l’utilisateur (propriétaire de la ressource) a données à une application pour qu’elle agisse en son nom. Il s’agit généralement d’une exigence d’autorisation déléguée. L’utilisateur doit autoriser le client à accéder à ses données dans un autre système.

• Application des politiques : Il s’agit de l’application des politiques de l’application ou de l’API, en rejetant ou en autorisant l’accès sur la base des informations d’authentification et/ou d’autorisation de l’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 des informations, b) quel acteur est responsable de la prise de décision et c) quel acteur est responsable de l’application des restrictions.

• La première catégorie est celle où l’accès est accordé ou refusé à une application ou à une API dans son intégralité. Les données nécessaires à l’application de cette règle et le processus d’application sont généralement définis dans le contexte du serveur d’autorisation. Par exemple, en utilisant les app_metadata associées à un utilisateur et une Règle définie dans votre locataire Auth0.

• La deuxième catégorie est celle où l’accès est accordé ou refusé à un sous-ensemble spécifique d’applications ou de fonctionnalités API. Les données nécessaires à l’application de cette règle sont généralement stockées dans le serveur d’autorisation. Par exemple, en utilisant des app_metadata  sur un utilisateur dans votre locataire Auth0, le processus d’application étant réalisé 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 plusieurs demandes personnalisées dans un jetonid ou access.

• La troisième catégorie est celle où l’accès est accordé ou refusé en fonction de ce que le demandeur (sujet) peut faire dans le contexte d’une application ou d’une API. Les données nécessaires à cet effet et 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 plusieurs demandes personnalisées dans un jetonid ou access peuvent être consommées avec ou sans données provenant d’une source externe qui n’est pas Auth0.

En outre, les mécanismes du contrôle d’accès basé sur les rôles (RBAC) et Attribute-based Access Control (ABAC/Contrôle d’accès basés sur les attributs) 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 un certain nombre d’éléments que vous devez prendre en compte lorsque vous examinez la fonctionnalité et le workflow dont vous avez besoin :

• Existe-t-il des scénarios dans lesquels l’accès à l’ensemble d’une application ou d’une API doit être refusé?

• Allez-vous fournir des API auxquelles des applications tierces peuvent accéder?

• Vos API seront-elles également accessibles à vos propres applications (de première partie)?

• Votre application appellera-t-elle une API tierce?

• Vos applications et/ou vos API doivent-elles appliquer un contrôle d’accès basé sur les demandes des utilisateurs?

• Que faire si j’ai besoin de savoir à quelle organisation un jeton d’accès ou un jeton d’ID est associé?

Auth0 prend en charge la restriction d’accès pour les applications ou les API sous certaines conditions. Dans certains scénarios, vous pouvez 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 incorrect (comme décrit dans cet exemple), ou si l’utilisateur n’a pas la ou 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 d’un jeton d’accès Oauth2 (utilisé lors de l’appel à l’API), peut être empêchée comme décrit dans cet exemple.

Auth0 peut également fournir les informations nécessaires pour qu’une application puisse appliquer des restrictions. Pour une 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 devrez décider des informations dont vous avez besoin pour que votre application prenne des décisions en matière 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 jeton d’accès plutôt qu’un jeton d’ID. Poursuivez la lecture pour en savoir plus.

Pour une intégration au niveau de l’API, Auth0 prend en charge les demandes personnalisées et la reconfiguration des permissions, dans le contexte d’un jeton d’accès. Là encore, vous devrez décider quelles informations seront nécessaires pour que votre API prenne des décisions en matière d’accès, et votre API devra s’y conformer en validant le contenu du jeton d’accès.

Dans les scénarios multi-organisations, il peut souvent être important de savoir à quelle organisation s’applique un jeton d’accès (ou même un jeton d’ID). Le respect des meilleures pratiques peut vous faire gagner du temps et de l’énergie.

Dans ce scénario, votre locataire Auth0 fournit un jeton comme indicateur de l’accès autorisé à une application. Pour les applications utilisant OpenID Connect (OIDC), le protocole standard de l’industrie que nous trouvons généralement le plus utilisé lorsqu’il s’agit d’applications orientées client, serait un jeton d’ID exprimé sous la forme d’un JWT.

Grâce à l’extensibilité des règles, Auth0 vous permet d’ajouter des demandes personnalisées à un jeton d’ID facilement, par exemple sur la base du contenu des métadonnées d’un utilisateur. Votre application peut alors vérifier le jeton d’ID pour les demandes concernées, et autoriser ou empêcher l’accès à certaines fonctionnalités selon les besoins. Bien que le processus d’ajout de demandes personnalisées via une règle soit simplifié, le moteur de règles est flexible et vous permet d’écrire un code personnalisé qui peut avoir des effets négatifs. C’est pourquoi il est important de suivre nos conseils sur les meilleures pratiques en matière de règles chaque fois que vous utilisez cette fonction d’extensibilité.

Si vous créez différentes instances de votre application pour les organisations de vos clients, une pratique courante consiste à créer une demande personnalisée dans votre jeton d’ID pour représenter l’organisation de l’utilisateur. Par exemple :

context.idToken["http://yourdomain.com/claims/organization"]= "organization A";

Les permissions OIDC sont généralement utilisées par une application pour obtenir le consentement à l’accès autorisé aux données d’un utilisateur lors de l’authentification. Chacune des permissions prédéfinies renvoie l’ensemble des demandes standard lorsqu’elles sont définies et telles qu’elles sont décrites 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 autorisées par l’utilisateur, les demandes sont renvoyées dans le jeton d’ID et sont également mises à disposition via le point de terminaison /userinfo.

Dans ce scénario, votre locataire Auth0 peut fournir un jeton d’accès OAuth2, généralement sous la forme d’un JWT, qui peut être utilisé par votre API pour restreindre l’accès à certains utilisateurs. De plus, Auth0 prend en charge ce qui est généralement appelé des Applications de première et de tierce parties.

Agissant en tant que serveur d’autorisation et avec le consentement de l’utilisateur (le propriétaire de la ressource), votre locataire Auth0 peut être utilisé pour fournir un jeton d’accès, généralement exprimé sous la forme d’un 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 de la ressource. 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 d’API de microservices, vous pouvez exploiter les jetons d’accès qu’Auth0 fournit afin de sécuriser l’accès à vos services. Bien que cela soit relativement facile à mettre en place dans le Auth0 Dashboard ou via la Management API Auth0, il est important d’examiner les différents scénarios d’application et les dispositions de l’API afin de déterminer la meilleure architecture pour votre système.

OAuth2 a été conçu spécifiquement pour l’accès 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 les données de l’utilisateur (le serveur de ressources). Dans ce cas, lorsque l’application doit accéder aux données dont l’utilisateur est propriétaire, elle est redirigée vers l’organisation où se trouvent les données de l’utilisateur, qui à son tour authentifie l’utilisateur et l’invite ensuite à donner à l’application la permission d’accéder à ses données. Cette demande d’autorisation est appelée consentement et constitue une grande partie de la prise en charge des applications tierces. Si vous prévoyez d’intégrer des applications tierces, il est important de les marquer comme telles dès le début afin qu’Auth0 puisse gérer la demande de consentement de l’utilisateur.

En revanche, si votre organisation est propriétaire de la ou des applications, des données utilisateur elles-mêmes et de la ou des API par lesquelles ces données sont accessibles, le consentement n’est généralement pas nécessaire car les interactions sont toutes de première partie. Si vous ne créez que des applications de première partie, vous pouvez vous assurer que vous ne présentez pas à vos utilisateurs des écrans de consentement inutiles en permettant d’ignorer le consentement de l’utilisateur dans le cadre de la définition d’un service de ressources.

Par ailleurs, il se peut que vous disposiez de données relatives à un utilisateur pour lesquelles des fonctionnalités supplémentaires sont fournies et pour lesquelles le consentement explicite de l’utilisateur ne peut être obtenu (c’est-à-dire qu’il n’y a pas d’utilisateur authentifié qui puisse le donner). Dans ce scénario, il est possible de définir une liste d’applications pour lesquelles l’octroi d’identifiants client est activé.

Comme pour les jetons d’ID, vous pouvez ajouter des demandes personnalisées aux jetons d’accès en utilisant l’extensibilité de la règle Auth0. Une fois ajoutée, votre API peut alors vérifier le jeton d’ID pour les demandes concernées, et autoriser ou empêcher l’accès à certaines fonctionnalités selon les besoins.

Les permissions OAuth2 sont généralement utilisées comme mécanisme permettant à une API de déterminer quelles actions peuvent être effectuées au nom d’un utilisateur. Les permissions peuvent être ajoutées pour chaque API afin de définir des autorisations d’accès spécifiques dans le Auth0 Dashboard ou via la Auth0 Management API. Les permissions peuvent également être manipulées via l’extensibilité Auth0 (p. ex. via une règle, comme dans cet exemple). Les permissions qu’une application demande pour accéder à une API doivent dépendre de la fonctionnalité pour lesquelles l’application a besoin que l’utilisateur lui donne la permission d’utiliser. Une fois que les permissions demandées sont autorisées, elles sont transmises au jeton d’accès, qui peut ensuite être vérifié par ladite API. En voici un bon exemple : lorsque vous vous connectez à une application qui utilise un fournisseur social pour la connexion; l’API du fournisseur social nécessite que l’application spécifie si l’utilisateur souhaite que l’application publie des articles 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 est différent de l’API qui restreint l’accès en fonction du rôle de l’utilisateur et doit être traité différemment.

Bien que les permissions soient souvent utilisées pour renforcer les autorisations d’accès d’un utilisateur, il existe des situations où leur utilisation peut s’avérer délicate. Nous vous recommandons donc d’utiliser les permissions dans le but pour lequel elles ont été conçues (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 d’autres scénarios.

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 FGA, 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.

Auth0 prend par défaut en charge le Role Based Access Control (RBAC). Le RBAC consiste à attribuer des autorisations aux utilisateurs en fonction de leur rôle au sein d’une organisation, et permet un contrôle d’accès plus simple en offrant une approche plus facile à gérer et moins sujette aux erreurs.

La fonctionnalité principale du RBAC peut être utilisée dans de nombreux scénarios multi-organisations. Consultez Données d’organisation dans un jeton d’accès pour plus d’informations sur la façon de s’assurer que votre configuration peut répondre à vos besoins en matière de RBAC.

De nombreux scénarios nécessitent qu’une application sans session interactive avec l’utilisateur 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 OAuth 2 fournit le type d’autorisation des identifiants client pour faciliter cette tâche. Voici quelques exemples courants de situations où cela est nécessaire :

• Une tâche 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é (c’est-à-dire que l’API n’est pas exposée directement aux utilisateurs, mais uniquement à un système dorsal).

• Dans certaines architectures de microservices, lorsque certaines couches d’API doivent communiquer avec d’autres couches d’API sans l’intervention d’un utilisateur, ou après l’expiration d’un jeton d’utilisateur.

• Une API privilégiée qui peut devoir être appelée avant qu’un utilisateur ne se soit authentifié (par exemple, à partir d’une règle ou d’un script de base de données personnalisé dans votre locataire Auth0).

Si vous disposez d’une API distincte de votre application dans votre système qui prend en charge votre application multi-organisations, il est important de limiter les opérations à l’organisation pour laquelle le jeton a été généré. Pour ce faire, le jeton d’accès doit contenir des informations permettant d’indiquer à l’API l’organisation pour laquelle le jeton d’accès a été émis. Cela peut se faire de différentes manières, en fonction des réponses à quelques questions simples :

1. Les utilisateurs finaux de cette organisation auront-ils potentiellement plus d’une organisation, ou chaque utilisateur final est-il isolé dans une organisation spécifique?

2. Autoriserez-vous un accès machine-machine (M2M) à votre API?

3. Si vous autorisez l’accès machine-machine (M2M) à votre API, y aura-t-il des développeurs qui auront besoin d’un ID et d’un secret client uniques pour accéder à plusieurs organisations (mais pas à toutes les organisations)?

4. Autoriserez-vous la création d’applications tierces nécessitant un consentement?

Si les utilisateurs finaux sont isolés au sein d’une seule organisation et que vous n’autorisez pas l’accès M2M à votre API ou que vous disposez d’un ID/secret client distinct pour chaque organisation ayant besoin d’un accès et que vous n’autorisez pas les applications tierces nécessitant un consentement, l’approche la plus simple consiste à créer une demande personnalisée dans le jeton d’accès en utilisant des règles pour les jetons basés sur l’utilisateur et en utilisant les hooks d’identification du client pour les appels M2M. Vous pouvez stocker le nom de l’organisation dans les métadonnées du client et l’extraire des règles ou des hooks pour l’inclure dans access_token en tant que revendication personnalisée. RBAC fonctionnera sans problème pour cette approche tant que chaque utilisateur final ne peut appartenir qu’à une seule organisation.

Si les utilisateurs finaux ont plus d’une organisation à laquelle ils peuvent appartenir ou si vous donnez à un développeur unique un ID client et un secret pour les appels M2M à plus d’une organisation, la meilleure approche est de créer une audience séparée (une instance API séparée dans votre locataire Auth0) pour chaque organisation. Cela vous offre quelques possibilités intéressantes :

1. Tout d’abord, vous pouvez transmettre l'audience à Auth0 en tant que paramètre de première classe, sans avoir à créer de paramètre personnalisé. L’avantage est qu’Auth0 contribuera à renforcer l’existence de l'audience et la transmettra à vos règles. Ensuite, cela garantit également qu’un jeton d’actualisation délivré ne fonctionnera que pour l'audience spécifique auquel il a été délivré à l’origine.

2. Cela vous permet de restreindre les autorisations des clients à des organisations spécifiques dès le départ. L’autre solution consiste à créer un hook client plus compliqué pour tenter de récupérer les restrictions à partir d’un autre endroit, ce qui nécessite également un moyen beaucoup plus complexe et potentiellement problématique pour indiquer à l’appel d’identification du client l’organisation pour laquelle le jeton d’accès doit être délivré.

3. Cela vous permet également d’utiliser la fonctionnalité principale de RBAC avec Auth0 et de vous assurer que les utilisateurs finaux qui ont accès à plus d’une organisation peuvent avoir un rôle potentiellement différent pour chaque organisation.

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.

Plusieurs plateformes mettent en œuvre une forme d’isolation et/ou d’image de marque pour les organisations de leurs clients, ce qui peut ajouter de la complexité à tout système de Gestion des identités et des accès (IAM). Si cela s’applique à vous, nous vous conseillons de prendre le temps de lire nos conseils et bonnes pratiques pour ce type d’environnement.

Architecture à organisations multiples