Comment configurer l'authentification Drupal en utilisant OAuth2 et OpenID Connect
À l'ère d'une architecture de plus en plus distribuée des applications et des portails web, il est nécessaire de fournir des méthodes d'authentification flexibles tout en maintenant la commodité pour l'utilisateur. Dans cet article, vous apprendrez à créer facilement un serveur d'authentification et une application cliente dans Drupal en utilisant OAuth2 et OpenID Connect.
Les systèmes distribués, leur mise à l'échelle et leur maintenance posent un problème pour de nombreux clients qui viennent chez nous pour bénéficier des services de consultation Drupal. Très souvent, il est nécessaire de mettre en œuvre un système de connexion central pour toutes les plateformes appartenant à une fédération plus large de sites web. Les grandes entreprises et organisations ont des portails séparés – nous avons créé des sites web d'image, des systèmes intranet et des services Drupal Commerce pour elles à plusieurs reprises, en tenant compte de diverses fonctions. La nécessité de s'inscrire et de se connecter séparément pour les utilisateurs semble être une méthode archaïque pour résoudre ce problème. Après tout, qui d'entre nous ne facilite pas son inscription sur des sites web au quotidien – par exemple, en utilisant des méthodes d'inscription rapide avec un compte sur un réseau social ou un profil Google ?
Pourquoi ne pas faire de même, surtout que – comme il s'avérera dans un instant – utiliser Drupal pour cela est très facile.
OAuth2 et OpenID Connect
Pour éclaircir le problème, il faut d'abord se concentrer sur les standards communément utilisés dans les applications web qui sont utilisés dans le processus d'authentification.
Le premier est OAuth2, un standard ouvert pour l'autorisation qui ne nécessite pas de partage des identifiants entre applications. L'accès aux ressources (s'il a été accordé) est vérifié sur la base d'un jeton délivré aux applications clientes par le serveur d'autorisation.
Comme OAuth2 a été conçu pour l'autorisation, c'est-à-dire pour accorder un accès spécifique à des ressources données, il n'est pas vraiment destiné directement à un processus standard d'authentification des utilisateurs (connexion). À cette fin, il a été décidé de proposer une couche supplémentaire (authentification) au protocole OAuth2, qui standardise ce processus. Cette technologie s'appelle OpenID Connect et – en plus du processus de connexion – elle unifie également la méthode d'échange de données de profil utilisateur entre applications. Nous allons donc examiner comment utiliser ces deux technologies en pratique.
Installation des modules
Si vous souhaitez configurer à la fois le serveur d'authentification basé sur OAuth2 et les applications clientes basées sur OpenID Connect dans Drupal, vous pouvez utiliser des solutions prêtes à l'emploi. Dans le cas d'un serveur, vous avez plusieurs modules appropriés, y compris le plus populaire (simple_oauth). Dans notre exemple, nous utiliserons le module OAuth2 Server. Il est légèrement moins populaire et n'a pas encore été publié en version stable pour Drupal 8 et 9, mais il est soutenu par des entreprises et organisations importantes liées à Drupal.
De plus, le deuxième module d'application cliente, OpenID Connect, est un projet maintenu et développé par exactement les mêmes organisations et équipe de développement. Vous pouvez donc être sûr que les deux projets seront développés simultanément et qu'aucun problème de compatibilité ne surviendra par la suite.
L'installation des modules est standard. Tout d'abord, vous devez télécharger et installer les modules sur notre serveur :
composer require drupal/oauth2_server
drush en oauth2_server -y && drush cr
Ensuite, de la même manière – pour le client :
composer require drupal/openid_connect
drush en openid_connect -y && drush cr
La dépendance principale nécessaire pour installer le serveur est la bibliothèque oauth2-server-php qui fournit les mécanismes de base pour remplir ce rôle. Si vous utilisez Composer en PHP, toutes les dépendances sont déjà résolues automatiquement pour vous.
Configuration du serveur
La configuration du module OAuth2 Server est principalement basée sur des entités. Ainsi, parmi les choses qu'il fournit, on trouve l'entité du serveur, du client, du jeton, etc. Notre configuration doit commencer par la définition du serveur. Ainsi, nous nous rendons sur la page de configuration /admin/structure/oauth2-servers.
Et ajoutons un nouveau serveur (Add Server). À l'étape suivante, nous voyons le formulaire d'entité du serveur :
Dans la variante de configuration la plus simple, nous laissons toutes les valeurs sélectionnées par défaut. De plus, nous cochons l'option "Utiliser OpenID Connect" comme couche par défaut utilisée dans le processus de connexion.
Comme vous pouvez le voir dans les paramètres, le processus d'authentification et d'autorisation se déroule sans l'utilisation des données d'authentification envoyées par le client, mais sur la base d'un code d'autorisation – échangé ensuite contre le jeton d'accès et le jeton de rafraîchissement, qui sont échangés pendant la communication entre les applications. Les détails techniques du protocole OAuth2 dépassent le cadre de cet article; si vous souhaitez en savoir plus sur le fonctionnement des options individuelles et du protocole lui-même, vous pouvez le faire en utilisant la documentation officielle.
À l'étape suivante, nous devons définir les clients qui peuvent se connecter à notre serveur. Nous devons toutefois avoir au moins une application cliente pour cela.
Configuration du client
OpenID Connect est un module très convivial également en termes de configuration. Pour configurer les clients que vous souhaitez utiliser, allez à /admin/config/services/openid-connect.
Comme vous pouvez le voir, il y a une liste de clients dans le formulaire. Le module permet donc de se connecter facilement en utilisant, par exemple, des réseaux sociaux bien connus. Chaque type de client est défini comme un plugin séparé (OpenIDConnectClient), ce qui facilite l'extension du projet avec de nouveaux clients. Notre exemple concerne cependant la connexion à notre propre serveur, nous utiliserons donc le client pour des utilisations génériques (Generic).
La configuration est assez simple car elle consiste à définir le nom du client et la clé secrète, ainsi qu'à fournir les adresses du serveur :
Tant qu'à faire, nous ajouterons une petite amélioration, à savoir – remplacer le formulaire de connexion par un bouton de connexion utilisant notre serveur d'autorisation. C'est très simple et accessible depuis le formulaire de configuration :
Génial! Le client semble prêt à être utilisé. Le seul inconvénient est le manque d'une option pratique pour changer le nom de "Generic" pour l'instant sans un peu de codage, mais le résultat reste excellent pour une configuration aussi rapide :
Configuration du serveur partie deux
Nous avons un serveur préconfiguré, ainsi qu'un client prêt. Définissons donc notre client dans la configuration du serveur afin qu'il sache qu'il peut s'y connecter et demander l'accès à ses ressources. Drupal est un CMS très sécurisé par rapport à la concurrence, mais la sécurité repose également sur sa configuration correcte.
N'oubliez jamais qu'il vous incombe de vérifier et de configurer quelles applications clientes devraient pouvoir se connecter au serveur et utiliser ses ressources.
Pour ajouter de nouveaux clients, allez à l'onglet Clients, puis cliquez sur le bouton pour ajouter de nouveaux clients.
Vous devriez voir un formulaire, dont les données devraient être remplies de la même manière que celles que vous avez configurées dans le module OpenID Connect de l'application cliente.
Nous enregistrons le formulaire, et il est prêt... presque. Vous devez encore accorder l'autorisation appropriée pour qu'il soit possible d'utiliser le serveur OAuth2. Pour cela, allez à la page /admin/people/permissions et attribuez l'autorisation Utiliser le serveur OAuth2 pour l'utilisateur anonyme.
Test
Tout est configuré. Vérifions donc le scénario réel de connexion. Tout d'abord, nous enregistrerons l'utilisateur test sur notre serveur afin qu'il puisse se connecter à nos autres applications.
Allez à l'application cliente (formulaire de connexion) et cliquez sur le bouton Se connecter avec Generic (capture d'écran du formulaire).
Vous êtes redirigé vers la page de connexion sur le serveur avec le paramètre de destination
(/user/login?Destination=/oauth2/authorise).
Après avoir correctement saisi le login et le mot de passe (test:test), vous devriez voir cette étape supplémentaire...
...dans laquelle vous décidez, en tant qu'utilisateur connecté, si vous souhaitez vraiment autoriser notre page cliente à accéder à vos données utilisateur depuis le serveur, sur la base desquelles un compte utilisateur local sera créé.
Après l'avoir approuvée, vous êtes redirigé vers la page de l'application cliente en tant qu'utilisateur connecté :
Succès! Nous pouvons désormais pleinement profiter de notre système de connexion centralisée.
Résumé
La possibilité de créer un système de connexion centralisée est de plus en plus fréquente parmi les clients ayant différents types de services, sites et applications distribués. En choisissant Drupal, vous pouvez vous concentrer sur la mise en œuvre de règles commerciales spécifiques, au lieu de réinventer la roue. L'utilisation de solutions prêtes à l'emploi, telles que OAuth2 Server ou OpenIDConnect, soutenues par des organisations bien connues, vous garantit que vous allez facilement mettre en œuvre le mécanisme dont vous avez besoin – même sans avoir besoin d'une connaissance détaillée des protocoles qu'elles utilisent.
Dans notre agence Drupal, nous utilisons toujours les solutions déjà disponibles que nous étendons souvent, et nous adaptons les modules Drupal au modèle commercial spécifique. J'espère que l'article ci-dessus et les modules utilisés vous seront également utiles dans votre projet.
