Fournisseur d’identité unique : Autorisation

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.

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

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.

Bien que la fonction Auth0 Organization ne prenne pas en charge les applications SAML, une affirmation SAML générée par un fournisseur d’identités (IdP) 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.

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 audience 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 :

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.

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.