Passer au contenu principal
Pour ce qui est de l’autorisation, vous devez généralement réfléchir à la manière dont vous déterminez ce qu’une personne est autorisée à faire et à la manière dont vous communiquez ces informations à vos applications et/ou à vos API. Selon les applications que vous utilisez, vous pouvez être concerné par l’un de ces problèmes, ou même les deux. Dans nos scénarios d’architecture, nous fournissons des orientations générales sur l’autorisation B2B, que nous recommandons d’examiner en même temps que les orientations fournies ici.
  • Les jetons d’ID sont souvent utilisés pour transmettre des informations sur l’autorisation de l’utilisateur aux applications par le biais de demandes personnalisées, qui peuvent être ajoutées grâce à l’extensibilité des Règles. Les demandes ajoutées vous permettent de présenter une interface utilisateur dans laquelle les utilisateurs n’ont pas la possibilité de tenter une action non autorisée. Les informations d’autorisation contenues dans un jeton d’ID fournissent également à toute application dorsale un moyen d’empêcher les utilisateurs de contourner les contrôles du côté client pour les applications web traditionnelles.
Meilleure pratiqueVous pouvez tirer parti du contrôle d’accès basé sur les rôles (RBAC) Auth0 via la fonctionnalité Auth0 Authorization Core pour définir les autorisations d’accès, qui peuvent être automatiquement appliquées aux jetons d’accès. Pour en savoir plus, consultez Activer le contrôle d’accès basé sur les rôles pour les API.La fonctionnalité RBAC d’Auth0 peut également fournir des informations que vous pouvez ajouter en tant que demandes personnalisées aux jetons d’ID (et aux jetons d’accès, si vous préférez une application manuelle). Les organisations Auth0 peuvent exploiter la fonctionnalité RBAC d’Auth0 via un ou plusieurs rôles attribués aux membres. Pour en savoir plus, consultez Ajout de rôles aux membres d’une organisation.
  • Les API qui fournissent un accès public à des services de ressources partagées sont généralement protégées par des mécanismes de contrôle d’accès. À cette fin, Auth0 permet de créer un jeton porteur d’autorisation, ou jeton d’accès 2, qui peut transmettre des informations sur l’autorisation de l’utilisateur à une API, généralement en utilisant le contrôle d’accès basé sur les rôles (RBAC) pour appliquer un ou plusieurs rôles attribués en fonction de l’appartenance ou en ajoutant des demandes personnalisées via l’extensibilité des Règles. Vous pouvez également exploiter la capacité RBAC d’Auth0 pour ajuster automatiquement la demande de permission d’un jeton d’accès. Les API peuvent alors utiliser ces informations pour appliquer le niveau approprié de contrôle d’accès, ce qui permet à votre API d’appliquer les règles de stratégie sans avoir à effectuer une recherche supplémentaire pour obtenir des informations sur l’utilisateur.
  • Dans certains cas, vous pouvez implémenter des stratégies au niveau de l’application dans le locataire Auth0, ce qui vous permet d’appliquer des stratégies à toute une série d’applications et de services de ressources (API) sans avoir à modifier chacun d’entre eux de manière indépendante. Vous mettez généralement cela en œuvre par le biais de l’extensibilité des Règles.
Meilleure pratiqueAuth0 Organizations fournit des règles d’Auth0 avec accès à des informations centrées sur l’organisation qui peuvent être consultées lors de l’authentification d’un utilisateur. Ces informations sont disponibles via l’objet organization contenu dans l’objet contextuel Rules (règles). L’objet organization permet également d’accéder à toutes les métadonnées fournies pour une définition Organization dans Auth0. Pour en savoir plus, consultez Développement personnalisé pour les organisations.

​
Demandes relatives aux jetons d’ID

En général, les demandes peuvent être ajoutées aux jetons d’ID, comme indiqué dans notre guide des meilleures pratiques en matière de demandes de jetons d’ID. Lorsque vous utilisez la fonctionnalité Auth0 Organizations, une demande org_id est automatiquement ajoutée à tout jeton d’ID (pour un exemple, consulter Travailler avec des jetons et Organizations) émis pour les utilisateurs membres d’une organisation. Ce paramètre est validé par les trousses SDK Auth0. Vous pouvez également ajouter des informations supplémentaires associées à une organisation Auth0 en ajoutant une demande personnalisée au jeton d’ID : 
context.idToken['http://travel0.net/multifactor'] = context.multifactor;
Remarque : Si vous avez configuré votre locataire pour qu’il prenne en charge les noms d’organisation dans Authentication API, la demande org_name est automatiquement incluse dans les jetons d’ID. Pour en savoir plus, consultez Utiliser des noms d’organisation dans la Authentication API.

​
Affirmation SAML

Bien que la fonction Auth0 Organization ne prenne pas en charge les applications , une affirmation SAML générée par un fournisseur d’identités () en amont peut être configurée pour alimenter des demandes standard ou personnalisées dans un jeton d’ID consommé en aval. Par exemple, vous pouvez définir la section Mappages d’une connexion d’entreprise SAML : 
{ 
  "user_id": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ],
  "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
  "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
  "given_name": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ], 
  "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
  "groups": "http://schemas.xmlsoap.org/claims/Group"
}
Dans cet exemple, chaque champ se verra attribuer une valeur dans l’objet user d’une Règle, qui correspondra aux demandes standard d’un jeton d’ID ou pourra être mis en correspondance à l’aide de demandes personnalisées. Pour en savoir plus sur la personnalisation des mappages SAML, consulter Connecter votre application aux fournisseurs d’identité SAML : Configurer les mappages.

​
Demandes relatives au jeton d’accès

En plus des autres demandes que vous ajoutez à votre jeton d’accès pour les décisions de contrôle d’accès (voir notre guide général des meilleures pratiques Demandes liées au jeton d’accès), vous voudrez généralement communiquer l’organisation à laquelle l’utilisateur appartient. Comme pour le jeton d’ID, lorsque vous utilisez la fonctionnalité Auth0 Organizations, la demande org_id est automatiquement ajoutée à tout jeton d’accès (pour un exemple, voir Travailler avec des jetons et Organizations) émis pour les utilisateurs membres d’une organisation. Vous pouvez également ajouter des informations supplémentaires associées à une organisation Auth0 en ajoutant une demande personnalisée au jeton d’accès : 
context.accessToken['http://travel0.net/multifactor'] = context.multifactor;
Remarque : Si vous avez configuré votre locataire pour qu’il prenne en charge les noms d’organisation dans Authentication API, la demande org_name est automatiquement incluse dans les jetons d’accès. Pour en savoir plus, consultez Utiliser des noms d’organisation dans la Authentication API. Vous pouvez également créer une API unique pour chaque organisation, ce qui donnera lieu à une définition API unique dans Auth0. Bien que ce mécanisme puisse atténuer la nécessité d’utiliser l’extensibilité des Règles personnalisées, sa complexité peut représenter un défi. Voici une comparaison simple :
ApprocheAvantagesInconvénients
Public API unique
  • Prise en charge prête à l’emploi pour l’accès communication entre machines pour une seule organisation.
  • Le public est une demande standard dans un jeton d’accès.
  • Le traitement des jetons d’actualisation ne fait appel à aucune logique d’organisation supplémentaire.
  • Doit automatiser la création d’une API pour chaque organisation.
  • Des rôles indépendants peuvent devoir être créés en cas d’utilisation du RBAC.
    • Doit automatiser la fourniture des rôles à l’adhésion.
  • L’implémentation de l’API doit traiter plusieurs audiences.
Demande PersonnaliséeSimplifie la configuration du locataire Auth0. Code personnalisé nécessaire dans une règle pour ajouter l’organisation au jeton d’accès.

​
Rôles

La fonction Auth0 Organizations prend également en charge le Contrôle d’accès basé sur les rôles (RBAC) par l’intermédiaire de la fonction Authorization Core associée à un locataire Auth0. Le contrôle d’accès basé sur les rôles est appliqué au niveau Auth0 Organization.
Vous pouvez activer Auth0 Authorization Core RBAC pour une API, ce qui entraînera l’activation de la demande de permission par défaut dans des jetons d’accès en cours de modification automatique et l’ajout d’une demande d’autorisation par défaut (pour obtenir un exemple, consultez Travailler avec des jetons et Organizations). Vous pouvez également ajouter des informations sur les rôles aux jetons d’ID en tant que demandes personnalisées en accédant à l’objet d’autorisation disponible dans l’objet context des règles. Pour en savoir plus, consultez Règles avec autorisation - Exemples de cas d’utilisation : Ajouter des rôles d’utilisateur aux jetons.

​
Contrôle d’accès

L’application de la stratégie au niveau des ressources relève de la responsabilité des applications et/ou des API de votre système. Si vous tentez d’appliquer des stratégies dans un serveur d’autorisation centralisé, comme votre locataire Auth0, vous vous heurterez rapidement à un système de contrôle complexe, difficile à maintenir et à appréhender. Au lieu de cela, votre serveur d’autorisation centralisé peut s’assurer que les informations appropriées sur un utilisateur sont incluses dans les jetons, de sorte que vos applications et API disposent des informations nécessaires pour prendre des décisions en matière d’application des stratégies. À tout le moins, dans les situations où les informations sont trop volumineuses pour être contenues dans un seul jeton (par exemple, les autorisations au niveau des ressources) ou lorsque les informations changent assez fréquemment pour être périmées si l’on y accède directement dans le jeton, vos applications et vos API devraient être en mesure de rechercher les informations correctes. En revanche, l’application de certaines stratégies de haut niveau peut être gérée de manière centralisée. Par exemple, lorsque vous utilisez un contexte Locataire Auth0, vous pouvez, dans certaines situations, implémenter une règle qui atténue la nécessité pour chaque application et/ou l’API d’appliquer les mêmes restrictions. Il s’agit notamment de :
  • bloquer l’accès aux utilisateurs à partir d’une adresse IP particulière;
  • implémenter des exigences spécifiques en matière d’authentification multifacteur contextuelle ou adaptative;
  • limiter la connexion aux seuls utilisateurs ayant vérifié leur adresse courriel
  • restreindre l’accès à une certaine audience de l’API, de sorte qu’un utilisateur ne puisse pas obtenir un jeton d’accès pour une autre audience de l’API ou qu’il ne puisse pas obtenir un jeton d’accès pour cette audience dans certaines circonstances. Dans ce cas, si vous créez une audience API personnalisée pour chaque organisation, votre Règle doit également garantir que l’utilisateur qui s’authentifie appartient à l’organisation qui correspond à l’audience API correspondante.
L’accès à Management API Auth0 n’est pas limité par l’organisation. L’accès à Management API Auth0 se fait au moyen d’un jeton d’accès attribué pour une utilisation dans un contexte de communication entre machines et ne peut pas être limité par une Auth0 Organization (Organisation Auth0). Par conséquent, ne donnez pas à vos clients un accès direct à votre instance de Management API Auth0. Si vos clients doivent gérer des aspects de leur organisation, tels que les comptes utilisateurs (voir Profile Management (Gestion des Profils)), vous devez créer votre propre application et/ou API indépendante pour cela.