Passer au contenu principal
Passons en revue la mise en œuvre de notre application Web classique. Nous avons utilisé ASP .NET Core pour la mise en œuvre, le code figure dans ce référentiel GitHub. L’exemple contient une application qui utilise l’intégration Active Directory pour authentifier les employés de l’entreprise et une connexion à la base de données Auth0 pour les fournisseurs externes. L’autorisation est mise en œuvre à l’aide de règles et de demandes, comme nous le verrons en détail dans ce paragraphe.

​
Connexion utilisateur

Auth0 fournit un gadget logiciel Lock qui sert de composant de connexion pour votre application, ce qui signifie que vous n’avez pas besoin d’implémenter votre propre écran de connexion. Le gadget logiciel Lock s’intègre de manière transparente à toutes les connexions que vous configurez dans votre Auth0 Dashboard, qu’il s’agisse de connexions de bases de données, via des réseaux sociaux ou d’entreprise. Il y a plusieurs façons d’implémenter un écran de connexion en utilisant une application Web et Auth0 :
  • Hosted Lock (Lock hébergé) : Utilisez une instance du gadget logiciel Lock, hébergé dans l’infrastructure Auth0.
  • Embedded Lock (Lock intégré) : Intégrez le gadget logiciel Lock au sein d’une page Web de votre application. Vous disposez de quelques options de personnalisation pour le gadget logiciel Lock proprement dit et d’un contrôle total sur le reste du code HTML de la page.
  • Custom UI (Interface utilisateur personnalisée) : Développez une page Web entièrement personnalisée pour l’écran de connexion. Le formulaire HTML personnalisé sera renvoyé à votre serveur qui, à son tour, authentifiera l’utilisateur à l’aide d’Authentication API. Pour plus d’informations sur l’utilisation d’une interface utilisateur personnalisée, consultez Personnaliser les pages de connexion classiques avec Lock ou une trousse SDK.
La meilleure pratique recommandée est d’utiliser Lock hébergé, car c’est l’option la plus sûre et la plus simple pour permettre aux utilisateurs de se connecter à votre application.

​
Automatiser Home Realm Discovery (HRD)

Par défaut, Lock affiche toutes les connexions proposées pour l’ouverture de session. La sélection des fournisseurs d’identité appropriés parmi plusieurs options s’appelle Home Realm Discovery (HRD) (Détection du domaine d’accueil). Dans notre cas, les options sont soit l’authentification avec Active Directory (pour les employés de l’entreprise), soit l’utilisation de l’adresse courriel/mot de passe pour la connexion à la base de données (pour les fournisseurs externes). Toutefois, vous pouvez souhaiter éviter cette première étape, au cours de laquelle l’utilisateur doit choisir le fournisseur d’identité (), et faire en sorte que le système l’identifie au lieu de le lui poser la question à chaque fois. Lock vous offre les options suivantes :
  • Identify the IdP programmatically (Identifier l’IdP par programmation) : Lorsque vous initiez une transaction d’authentification avec Auth0, vous avez l’option d’envoyer un paramètre connection. Cette valeur correspond directement à toute connexion définie dans votre tableau de bord. Lorsque vous utilisez la version hébergée de Lock en appelant le point de terminaison /authorize, vous pouvez transmettre un paramètre de chaîne de requête connection contenant le nom de la connexion. Par ailleurs, si vous utilisez Lock hébergé, il vous suffit d’écrire auth0.show({connections: [’{yourConnection}’]});.
    • Il existe plusieurs façons pratiques d’obtenir la valeur connection . L’une d’entre elles consiste à utiliser des URL de redirection vers un microsite : des employés de l’entreprise utiliseront par exemple https://internal.yoursite.com, alors que les fournisseurs externes utiliseront https://external.yoursite.com.
  • Utiliser des domaines de courriel : Lock peut utiliser des domaines de courriel comme moyen d’acheminer les demandes d’authentification. Les connexions d’entreprise dans Auth0 peuvent être mappées à des domaines. Si une connexion est configurée ainsi, le champ de saisie du mot de passe est automatiquement désactivé lorsqu’un utilisateur saisit une adresse courriel avec un domaine mappé. Notez que vous pouvez associer plusieurs domaines à une seule connexion.
Pour en savoir plus, consultez Sélectionner parmi plusieurs options de connexion.

​
Gestion des sessions

En ce qui concerne la gestion des sessions, il y a généralement trois couches de sessions à prendre en compte :
  • Application Session (Session de l’application) : Cette première couche correspond à la session au sein de l’application. Même si votre application utilise Auth0 pour authentifier les utilisateurs, vous devrez toujours garder une trace du fait que l’utilisateur s’est connecté à votre application. Dans une application Web normale, cela se fait en stockant des informations dans un témoin.
  • Auth0 session (Session Auth0) : Ensuite, Auth0 conservera également une session et stockera les informations relatives à l’utilisateur dans un témoin. La prochaine fois qu’un utilisateur sera redirigé vers l’écran de verrouillage Auth0, les informations de l’utilisateur seront mémorisées.
  • Identity Provider session (Session du fournisseur d’identité) : Cette dernière couche est celle du fournisseur d’identité, par exemple Facebook ou Google. Si vous avez autorisé les utilisateurs à se connecter avec l’un de ces fournisseurs et qu’ils sont déjà connectés à ce fournisseur, ils n’ont pas besoin de se connecter. Il leur sera simplement demandé de donner l’autorisation de partager leurs informations avec Auth0 et, par conséquent, avec votre application.
Lors du développement d’une application Web, vous devrez toujours garder à l’esprit que l’utilisateur s’est connecté à votre application Web. Pour ce faire, vous pouvez utiliser une session basée sur les témoins pour garder une trace du fait que l’utilisateur s’est connecté, et également stocker toutes les informations ou jetons liés à l’utilisateur.

​
Comment contrôler la durée de la session de l’application locale de l’utilisateur? Puis-je effectuer cela à partir d’Auth0?

L’application Web a un contrôle total sur la session d’application locale de l’utilisateur. La manière de procéder dépend généralement du stack Web utilisé (p. ex., ASP.NET). Quoi qu’il en soit, toutes les approches utilisent en fin de compte un ou plusieurs témoins pour contrôler la session. Le développeur peut choisir d’utiliser l’expiration du jeton d’ID JWT renvoyé par Auth0 pour contrôler la durée de la session ou l’ignorer complètement. Certains développeurs stockent le jeton d’ID lui-même dans l’état de la session et mettent fin à la session de l’utilisateur lorsqu’il a expiré. La raison pour laquelle vous utilisez l’expiration du jeton pour déterminer l’expiration de la session locale est que cela vous permet de contrôler de manière centralisée la durée de la session d’un utilisateur à partir d’Auth0 Dashboard. ::: Le flux de connexion est le suivant :
undefined
  1. Initiate OIDC Authentication Flow (Initier le flux d’authentification OIDC) : Le navigateur de l’utilisateur enverra une demande à Auth0 pour initier le flux OIDC.
  2. Set SSO Cookie (Définir le témoin SSO) : Auth0 crée un témoin pour stocker les informations de l’utilisateur.
  3. Code exchange and return ID Token (Échanger le code et renvoyer le jeton d’ID) : Auth0 envoie une demande au serveur Web et renvoie le code. Le serveur Web échangera le code contre un jeton d’ID.
  4. Set auth cookie and send response (Définir le témoin d’authentification et envoyer la réponse) : Le serveur Web renvoie une réponse au navigateur et met en place le témoin d’authentification de l’application pour stocker les informations relatives à la session de l’utilisateur.
  5. Auth cookie sent with every subsequent request (Envoyer un témoin d’authentification à chaque demande suivante) : Le témoin d’authentification de l’application sera envoyé à chaque demande suivante pour prouver que l’utilisateur est authentifié.

​
Comment la session SSO d’Auth0 affecte-t-elle la session de l’application?

Auth0 gère sa propre session de signature unique. Les applications peuvent choisir d’honorer ou d’ignorer cette session SSO lorsqu’il s’agit de maintenir leur propre session locale. Le widget Lock dispose même d’une fonction spéciale qui lui permet de détecter l’existence d’une session Auth0 SSO et de demander à l’utilisateur s’il souhaite se connecter à nouveau en tant que le même utilisateur.
Lock Widget SSO
 Si c’est le cas, il est connecté sans avoir à saisir à nouveau ses identifiants auprès du fournisseur d’identité (IDP) réel. Même si l’utilisateur ne s’est pas authentifié, l’application effectue tout de même un flux d’authentification avec Auth0 et obtient un nouveau jeton d’ID, qui peut être utilisé pour gérer la nouvelle session de l’application locale. ::: Voir la mise en œuvre dansASP.NET Core.

​
Déconnexion de l’utilisateur

Lorsque vous déconnectez l’utilisateur, vous devez à nouveau réfléchir aux trois couches de sessions dont nous avons parlé précédemment :
  • Application Session (Session de l’application) : Vous devez déconnecter l’utilisateur de votre application Web en effaçant sa session.
  • Session Auth0 : Vous devez déconnecter l’utilisateur d’Auth0. Pour ce faire, vous redirigez l’utilisateur vers https://{yourDomain}/v2/logout. En redirigeant l’utilisateur vers cette URL, vous effacez tous les témoins de l’authentification unique () définis par Auth0 pour l’utilisateur.
  • Identity Provider session (Session du fournisseur d’identité) : Bien que ce ne soit pas une pratique courante, vous pouvez forcer l’utilisateur à se déconnecter du fournisseur d’identité utilisé, par exemple Facebook ou Google. Pour ce faire, ajoutez un paramètre de chaîne de requête federated à l’URL de déconnexion : https://{yourDomain}/v2/logout?federated.
Pour rediriger un utilisateur après la déconnexion, ajoutez un paramètre de chaîne de requête returnTo avec l’URL cible comme valeur : https://{yourDomain}/v2/logout?returnTo=http://www.example.com. Notez que vous devrez ajouter la valeur returnTo URL en tant qu’URL de déconnexion autorisées. Pour en savoir plus sur cette mise en œuvre, consultez : Déconnexion. Le flux de déconnexion (excluant la déconnexion fédérée) se déroule comme suit :
undefined
  1. Initiate Logout Flow (Initier le flux de déconnexion) : Le flux de déconnexion est initié à partir du navigateur, par exemple lorsque l’utilisateur clique sur un lien de Logout (Déconnexion). Une demande sera adressée au serveur Web.
  2. Clear user’s local session (Effacer la session locale de l’utilisateur) : Le cache du témoin de session de l’application de l’utilisateur sera vidé.
  3. Redirect browser to Auth0 Logout (Rediriger le navigateur vers la déconnexion Auth0) : Le navigateur de l’utilisateur sera redirigé vers l’URL de déconnexion Auth0 URL.
  4. Clear SSO Cookie (Effacer le témoin SSO) : Auth0 videra le cache du témoin SSO.
  5. Rediriger vers l’URL après la déconnexion : Auth0 renvoie une réponse de redirection et redirige le navigateur de l’utilisateur vers le paramètre de chaîne de requête returnTo.
Voir la mise en œuvre dansASP.NET Core.

​
Contrôle d’accès

L’autorisation fait référence au processus de détermination des actions qu’un utilisateur peut effectuer dans votre application. Vous pouvez implémenter l’autorisation directement dans votre application, indépendamment d’Auth0, ou utiliser l’un des moyens proposés pour récupérer les niveaux d’autorisation de l’utilisateur. Vous pouvez ensuite les placer en tant que demandes d’autorisation à l’intérieur du jeton d’ID et les valider dans votre application, une fois que vous avez récupéré le jeton, pour contrôler l’accès. Il existe plusieurs façons de récupérer et de définir les demandes d’autorisation de l’utilisateur lorsque vous utilisez Auth0 :
  • En configurant et en utilisant Auth0 Authorization Extension.
  • En utilisant les groupes Active Directory. Ceux-ci peuvent être utilisés en combinaison avec Authorization Extension en faisant correspondre les groupes Active Directory aux groupes que vous définissez à l’aide de Authorization Extension.
  • Ajouter des métadonnées au profil de l’utilisateur en utilisant des règles.
  • En appelant un service externe à partir d’une règle.
Étant donné que dans notre cas, l’entreprise a déjà mis en place Active Directory, nous appliquerons le contrôle d’accès à l’aide de Authorization Extension en combinaison avec les groupes Active Directory.

Authorization Extension

À ce stade, l’extension d’autorisation est principalement conçue pour mettre en œuvre une autorisation à granularité grossière, par exemple pour contrôler l’accès à une application sur la base de l’appartenance d’un utilisateur à un groupe. Ce n’est pas nécessairement conçu pour contrôler l’accès au niveau le plus fin (par exemple, si un utilisateur peut effectuer une action particulière au sein de l’application), même si c’est ainsi que nous l’utilisons dans ce cas.
Tous les utilisateurs seront implicitement des utilisateurs normaux, mais les administrateurs de feuilles de temps seront affectés à un groupe Admin qui leur permettra d’approuver les feuilles de temps. Authorization Extension permet d’associer des groupes à des membres de groupes existants. Tous les administrateurs de feuilles de temps seront affectés au groupe Timesheet Administrators sur Active Directory, qui sera automatiquement mappé au groupe Admin à l’intérieur de l’application Feuilles de temps. Lorsque vous installez Authorization Extension, elle crée une règle en arrière-plan, qui fait ce qui suit :
  1. Détermine l’appartenance de l’utilisateur à un groupe.
  2. Stocke les informations sur l’appartenance de l’utilisateur à un groupe dans les app_metadata.
  3. Ajoute l’appartenance au groupe de l’utilisateur au jeton sortant.
  4. Vérifie que l’utilisateur a obtenu l’accès à l’application active.

​
Installer Authorization Extension

Pour installer Authorization Extension, naviguez vers la vue Extensions  de votre Auth0 Dashboard, puis sélectionnez l’extension Auth0 Authorization. Une fois installée, vous verrez l’application listée sous Extensions installées. Lorsque vous cliquez sur le lien pour ouvrir l’extension pour la première fois, vous serez invité à donner l’autorisation à l’extension d’accéder à votre compte Auth0. Si vous le faites, vous serez redirigé vers le tableau de bord d’autorisation. Dans le tableau de bord d’autorisation, naviguez vers Groupes dans le menu de navigation, et créez un nouveau groupe appelé Admin.
undefined
Une fois le groupe ajouté, vous pouvez cliquer sur le nouveau groupe pour accéder à la section de gestion des groupes. Allez dans l’onglet Mappages de groupe et ajoutez un nouveau mappage de groupe qui mappera tous les utilisateurs d’Active Directory dans les groupes Timesheet Admins au groupe Admin que vous venez de créer.
undefined
Cliquez sur Save (Enregistrer) : le nouveau mappage est listé.
undefined
Une fois le mappage configuré, il vous suffit de maintenir l’appartenance au groupe Timesheet Admins dans Active Directory, et ces utilisateurs seront automatiquement mappés vers le groupe Admin au sein de notre application. Pour en savoir plus, consultez la documentation relative à Authorization Extension.

​
Faire appliquer les autorisations dans votre application

Lorsque vous avez installé Authorization Extension, une règle Auth0 a été créée, qui ajoutera une demande d’authorization avec tous les paramètres liés à l’autorisation pour un utilisateur particulier. Les groupes d’un utilisateur seront ajoutés en tant que sous-demande de la demande authorization appelée groups et tous les groupes auxquels un utilisateur appartient seront ajoutés en tant que tableau à cette demande. Voici un exemple de ce à quoi peut ressembler la charge utile JSON d’un jeton d’ID avec les groupes énumérés : 
{
  "sub": "1234567890",
  "name": "John Doe",
  "authorization": {
    "groups": ["Admin"]
  }
}
Dans votre application, vous devrez donc décoder le jeton d’ID renvoyé lorsqu’un utilisateur est authentifié et extraire les groupes auxquels l’utilisateur appartient de la demande authorization. Vous pouvez ensuite stocker ces groupes, ainsi que d’autres informations relatives à l’utilisateur, dans la session de l’utilisateur, et les interroger par la suite pour déterminer si un utilisateur a le droit d’effectuer une certaine action en fonction de son appartenance à un groupe.
Voir l’implémentation dans ASP.NET Core.