Autorisation (B2C)

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.

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.

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.

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.

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é.

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

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.

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.

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.

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.

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 Auth0 Dashboard ou via Management API 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.

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.

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

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 OAuth 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).

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.