Authentification des utilisateurs auprès d’applications existantes avec OpenID Connect et NGINX Plus

Liam CrillyDirecteur senior de la gestion des produits

Utiliser la prise en charge des JWT pour fournir une authentification unique aux applications existantes

[Éditeur – Cet article explique comment utiliser NGINX Plus avec des fournisseurs OpenID Connect prenant en charge le flux implicite pour l’authentification. Les informations sont techniquement exactes, mais certaines actions (comme l’utilisation de cron pour récupérer les clés publiques) ne sont plus nécessaires grâce aux mises à jour de notre implémentation de référence. Pour consulter l’implémentation actuelle, rendez-vous sur notre dépôt GitHub.

À partir de NGINX Plus R15, vous pouvez également utiliser NGINX Plus comme partie de confiance dans le flux de code d’autorisation d’OpenID Connect.]

OAuth 2.0 a largement contribué à améliorer la flexibilité et l’expérience utilisateur de l’authentification sur les sites web et les applications. Mais malgré son nom, la spécification OAuth 2.0 aborde très peu la vérification de l’identité de l’utilisateur final et ne dit rien de l’authentification unique (SSO). C’est là qu’intervient OpenID Connect : il s’agit essentiellement de la pièce manquante qui permet d’intégrer les informations d’identité aux jetons d’accès OAuth 2.0.

Les jetons d’identité OpenID Connect sont conformes à la spécification JSON Web Token (JWT). Les jetons JWT (prononcé « jot ») sont compacts, faciles à transmettre et fournissent un schéma de base commun pour décrire les informations d’identité. L’un des principaux avantages des JWT est qu’ils peuvent s’appliquer à presque tous les cas d’usage liés à l’identité, de l’authentification des clients d’API à la mise en place de l’authentification unique (SSO) pour les applications d’entreprise. En effet, de nombreuses organisations qui utilisent Google Apps peuvent utiliser Google comme fournisseur d’identité afin de mettre en place l’authentification unique pour leurs applications d’entreprise. Cela étant, l’utilisation d’OpenID Connect et des JWT n’empêche pas de s’en servir pour s’authentifier auprès d’applications web existantes ou leur fournir une authentification unique.

NGINX Plus R10 et les versions ultérieures intègrent une prise en charge native des JWT, ce qui permet à NGINX Plus de valider les jetons et d’enrichir les requêtes en amont avec l’identité de l’utilisateur authentifié, dans un format facilement exploitable par l’application. Dans cet article de blog, nous expliquons comment utiliser la prise en charge native des JWT dans NGINX Plus afin d’activer l’authentification unique (SSO) pour des applications existantes, sans qu’aucune modification de ces dernières ne soit nécessaire. Nous utilisons Google comme fournisseur d’identité et un site web simple pour représenter l’application. Le flux de bout en bout se présente comme suit :

Activation d’OpenID Connect pour votre application web

Notre exemple comporte deux composants : la configuration de NGINX Plus et la page de connexion HTML.

Configuration de NGINX Plus

La configuration de NGINX Plus pour valider les JWT est très simple.

server {    listen 80;
    root /var/www/public_html;

    location /private/ {
        auth_jwt "Google account" token=$cookie_auth_token;
        auth_jwt_key_file /etc/nginx/google_certs.jwk;
    }
}

Le bloc location indique que toutes les requêtes adressées à des URL commençant par /private/ doivent être authentifiées. La directive auth_jwt définit le domaine d’authentification qui sera renvoyé (avec un code 401) en cas d’échec de l’authentification, ainsi que l’emplacement de la requête où NGINX Plus peut trouver le JWT. Dans ce cas, le jeton doit se trouver dans un cookie nommé auth_token. Par défaut, NGINX Plus attend des clients qu’ils présentent le JWT sous la forme d’un jeton Bearer, à l’aide de l’en-tête Authorization, comme c’est généralement le cas avec les applications AJAX et les clients d’API, mais il peut également récupérer le JWT dans d’autres en-têtes HTTP, dans les paramètres de la chaîne de requête ou dans un cookie, comme dans cet exemple.

La directive « auth_jwt_key_file » indique à NGINX comment valider la signature du JWT. Cette validation garantit que le JWT a été émis par Google et qu’il n’a pas été modifié depuis. Google publie ses clés publiques et les renouvelle régulièrement. Pour maintenir un jeu de clés à jour, utilisez cron(8) afin de les récupérer toutes les heures, comme dans cet exemple d’entrée crontab.

0 * * * * wget https://www.googleapis.com/oauth2/v3/certs -O /etc/nginx/google_certs.jwk

Page de connexion basée sur HTML

Pour que cet exemple reste simple et clair, nous ne développons pas une application complète. Nous utilisons plutôt le code HTML de base suivant pour créer une page de connexion. Le fichier HTML s’appelle « /var/www/public_html/index.html » (cela correspond au chemin « root » que nous avons défini dans la configuration de NGINX Plus).

<html>
<head>
    <meta http-equiv="cache-control" content="no-cache" />
    <meta http-equiv="expires" content="0" />
    <title>NGINX OpenID Connect demo</title>
    <script src="https://apis.google.com/js/platform.js" async defer></script>
    <meta name="google-signin-scope" content="profile email">
    <meta name="google-signin-client_id" content="client-ID.apps.googleusercontent.com"> <script src="/js.cookie.js"></script>
</head>
<body>
    <h2>NGINX OpenID Connect demo</h2>
    <hr/>
    <h3>Login with a Google account then visit the <a href="/private/">private area</a>.</h3>
    <table><tr><td>
    <div class="g-signin2" data-onsuccess="onSignIn" data-theme="dark"></div></td>
    <script>
      function onSignIn(googleUser) {
        var profile = googleUser.getBasicProfile();
        Cookies.set('auth_token', googleUser.getAuthResponse().id_token);
        document.getElementById('google_signout').innerHTML = '<a href="#" onclick="signOut();"><img src="' + profile.getImageUrl() + '" width=32 height=32>Sign out</a>';
      };
      function signOut() {
        var auth2 = gapi.auth2.getAuthInstance();
        auth2.signOut().then(function () {
          Cookies.remove('auth_token');
          document.getElementById('google_signout').innerHTML = '';
        });
      }
    </script>
    <td><div id="google_signout"></div></td>
    </tr></table>
    <hr/>
</body>
</html>

Nous avons mis en évidence deux dépendances clés dans le bloc « <head> ».

• <meta name="google‑signin‑client_id"> balise – Nous utilisons l’API JavaScript OAuth 2.0 de Google pour gérer le processus de consentement et d’authentification OAuth 2.0 de l’utilisateur final. C’est cette API qui nous fournit le bouton de connexion et nous permet de détecter si nous sommes connectés ou non. Pour que notre site Web soit authentifié par Google, nous devons créer un ID client OAuth 2.0 et le renseigner dans l’attribut content de cette balise, en remplaçant l’espace réservé client-ID. Pour savoir comment créer un nouvel ID client OAuth 2.0, consultez l’annexe à la fin de cet article.
• <script src="/js.cookie.js"> balise – Nous avons besoin d’un analyseur de cookies capable d’extraire le jeton d’identité du jeton d’accès OAuth 2.0 et de créer un cookie à envoyer au site web. La ligne Cookies.set effectue cette opération à l’aide de la bibliothèque JavaScript Cookie, incluse avec cette balise.

Une fois ces éléments en place, nous disposons désormais d’une page d’accueil publique avec le mécanisme de connexion de Google et d’un espace privé protégé par NGINX Plus. Notez que nous n’avons créé aucun contenu pour notre espace privé ; une erreur 404 est donc attendue lorsque nous tentons d’y accéder.

Pour aller plus loin

Pour en savoir plus sur les fonctionnalités JWT avancées, consultez « Authentification des clients d’API avec JWT et NGINX Plus ». Cet article explique comment transmettre par proxy des requêtes authentifiées avec les informations d’identité de l’utilisateur obtenues à partir du JWT, journaliser les revendications JWT et prendre en charge plusieurs fournisseurs d’identité.

Pour découvrir la prise en charge native des JWT dans NGINX Plus, commencez dès aujourd’hui votre essai gratuit de 30 jours ou contactez-nous.

Annexe – Création d’un ID client Google OAuth 2.0

[Éditeur – Nous avons tout mis en œuvre pour représenter fidèlement l’interface graphique des API Google au moment de la publication. Toutefois, cette interface évolue rapidement, et les options de menu ainsi que leur emplacement sont susceptibles de changer. Utilisez ces instructions comme référence et adaptez-les si nécessaire à l’interface actuelle.]

1. Accédez au tableau de bord des API Google à l’adresse https://console.developers.google.com/apis/dashboard. La page qui s’ouvre dépend de votre historique d’utilisation des API Google. Vous devrez peut-être créer un compte, accepter les conditions d’utilisation et effectuer d’autres étapes qui ne figurent pas dans ces instructions. La capture d’écran suivante montre le coin supérieur gauche du tableau de bord. Cliquez sur le mot situé à droite du logo Google APIs (si vous avez déjà créé un projet, son nom peut apparaître à la place du mot Projet). Sélectionnez Créer un projet.
   
    
2. Créez un projet. Ici, notre nouveau projet s’appelle « NGINX OpenID ». Après avoir cliqué sur le bouton « Créer », plusieurs secondes peuvent s’écouler avant qu’une notification confirmant la création de votre projet ne s’affiche.
   
    
3. Activez l’API Google+ pour votre projet. Elle fournit des services d’authentification OAuth 2.0 et de gestion des identités. (Si le tableau de bord du gestionnaire d’API ne s’affiche pas déjà dans la partie principale de la fenêtre, cliquez sur Tableau de bord dans la zone de navigation située à gauche de l’écran.) Pour commencer à activer l’API Google+, cliquez sur le bouton ACTIVER L’API.
   
    
4. Cliquez sur « API Google+ » (dans la section « API sociales »).
   
    
5. Cliquez sur le bouton « ACTIVER ».
   
    
6. Pour créer des identifiants pour votre projet, cliquez sur Identifiants dans la zone de navigation à gauche de l’écran, puis cliquez sur le bouton Créer des identifiants. Sélectionnez ID client OAuth dans le menu déroulant.
   
    
7. Sélectionnez le bouton radio Application Web. Dans le champ Origines JavaScript autorisées, indiquez l’URL de l’hôte sur lequel NGINX Plus est installé, ainsi que le numéro de port que vous avez spécifié comme paramètre de la directive listen dans Activation d’OpenID Connect pour votre application Web (par exemple, mydomain.example.com:80). Cet exemple utilise localhost, mais vous devez saisir le nom d’hôte et le port de l’instance NGINX Plus réelle. Cliquez sur le bouton Créer (vous devrez peut-être cliquer plusieurs fois dessus pour lancer le processus de création).
   
    
8. La fenêtre « Client OAuth » s’affiche et indique votre ID client et votre code secret client. Copiez l’ID client dans l’attribut content de la balise <meta name="google-signin-client_id"> de votre application (en remplaçant l’espace réservé client-ID mis en évidence ci-dessus). Vous n’avez pas besoin du code secret client.
   
    
9. Sur l'écran principal Identifiants, cliquez sur Écran de consentement OAuth. Indiquez votre adresse e-mail et le nom du produit (tous les autres champs sont facultatifs).
   
    

Revenir à la section sur la création d’un exemple d’application utilisant les identifiants

Pour découvrir la prise en charge native des JWT dans NGINX Plus, commencez dès aujourd’hui votre essai gratuit de 30 jours ou contactez-nous.

À propos de l’auteur

Liam CrillyDirecteur senior de la gestion des produits

Autres articles de Liam Crilly