Authentifier les applications à page unique avec des témoins

Assurer la sécurité d’une application à page unique (SPA) peut être difficile. Toutefois, si votre SPA répond aux critères suivants, vous pouvez simplifier votre mise en œuvre en utilisant des témoins pour l’authentification.

• Elle est fournie au client à l’aide de votre propre système dorsal.

• Elle possède le même domaine que votre système dorsal.

• Elle effectue des appels d’API qui nécessitent une authentification à votre système dorsal.

Voici une description de cette approche ainsi qu’un exemple de mise en œuvre à l’aide de Node.js.

Les étapes ci-dessous montrent comment récupérer et utiliser les jetons. Dans cette approche, le Flux implicite avec Form Post est utilisé au lieu d’un Flux de code d’autorisation avec Proof Key for Code Exchange traditionnel. Cela est possible grâce au mode de réponse du formulaire post qui facilite l’authentification lorsqu’il s’agit d’accéder à votre propre ressource.

1. L’utilisateur accède à une route protégée en utilisant le navigateur ou effectue une action qui nécessite l’initialisation d’une étape d’authentification, comme cliquer sur un bouton de connexion.

2. Le client du navigateur redirige vers une route /login sur le système dorsal, ou vers la route protégée selon les actions de l’utilisateur.

3. Le système dorsal construit une requête au point de terminaison /authorize du serveur d’autorisation et redirige le client du navigateur à cet endroit.

4. L’utilisateur est invité à s’authentifier en utilisant la méthode présentée par le serveur d’autorisation.

5. Le serveur d’autorisation POST les jetons à l’URI de redirection sous forme de message codé par URL. Le système dorsal est capable de récupérer ces jetons en analysant les données du corps.

À ce stade, l’utilisateur est authentifié et le système dorsal possède les jetons requis. Un témoin peut maintenant être créé pour représenter cet état sur le client. Le navigateur client est alors redirigé vers une route qui dessert la SPA et reçoit également le témoin d’authentification.

Désormais, ce témoin est échangé entre le client et le système dorsal lorsque des appels d’API sont effectués en utilisant un appel AJAX. À chaque requête, le système dorsal vérifie si le témoin est toujours valide et, dans l’affirmative, autorise la poursuite de la requête.

Lors de la mise en œuvre de cette approche, vous devrez gérer les cas où le témoin d’authentification est invalide ou manquant. L’appel d’API au système dorsal du client se fait en arrière-plan, de sorte que le client doit traiter toute réponse du serveur indiquant qu’il faut que l’utilisateur se réauthentifie.

Dans l’exemple d’application suivant, on traite le cas de manière naïve en demandant à l’utilisateur de se réauthentifier si l’appel API donne un résultat 302 Redirect. Le résultat 302 se produit parce que, après une tentative infructueuse de validation du témoin, le serveur essaie de rediriger vers le point de terminaison d’autorisation du serveur d’autorisation et envoie cette réponse au client.

Pour illustrer les concepts abordés plus haut, l’exemple d’application utilise Node.js et Express.

• Assurez-vous d’avoir installé la version la plus récente de Node pour continuer.

• Une fois le nœud installé, téléchargez ou clonez le code source et ouvrez le dossier du projet dans une fenêtre de terminal.

  // Clone the tutorial respository using SSH
  git clone git@github.com:auth0-blog/spa-cookie-demo
  // ... or if you use HTTPS:
  git clone https://github.com/auth0-blog/spa-cookie-demo.git
  // Move into the project directory
  cd spa-cookie-demo

  Was this helpful?

  Yes /No

• La branche master représente l’état de l’application avant que toute authentification soit ajoutée. Si vous souhaitez consulter la version finale de l’application, consultez la branche with-oidc : git checkout with-oidc

Installez les dépendances de l’application en exécutant npm install depuis votre fenêtre Terminal. Pour exécuter l’application, utilisez npm run dev. Cela lance le serveur Express. Rendez-vous à http://localhost:3000 dans votre navigateur pour voir l’application.

Les serveurs de développement utilisent nodemon, qui redémarre automatiquement dès qu’il détecte des changements de fichiers.

Lorsque l’application est ouverte à http://localhost:3000, cliquez sur le bouton Call API (Appeler l’API). Un message devrait s’afficher à l’écran.

Il est à noter que vous avez pu exécuter l’appel API sans être connecté. Pour remédier à cela, intégrons un logiciel médiateur qui exige que l’utilisateur se connecte avant que l’appel à l’API puisse être effectué.

Pour que l’application fonctionne avec l’authentification, express-openid-connect nécessite la présence de certaines variables d’environnement. Pour cette application, ces variables peuvent être indiquées dans un fichier .env. Créez un fichier .env dans la racine du répertoire du projet, puis remplissez-le comme suit :

ISSUER_BASE_URL=<YOUR OIDC URL>
CLIENT_ID=<YOUR OIDC CLIENT ID>
BASE_URL=http://localhost:3000
APP_SESSION_SECRET=<YOUR SECRET VALUE>

1. Naviguez vers Dashboard (Tableau de bord) > Applications > Applications et cliquez sur Create Application (Créer une application).

2. Nommez votre nouvelle application, sélectionnez Regular Web Applications (Applications Web classiques), et cliquez sur Create (Créer)

3. Dans les Paramètres de votre nouvelle application, ajoutez http:/localhost:3000/callback aux URL de rappel autorisées .

4. Ajoutez http:/localhost:3000 aux URL de déconnexion autorisées.

5. Cliquez sur Enregistrer les modifications.

6. Rendez-vous à Dashboard (Tableau de bord)> Authentication (Authentification) > Social (Via réseau social) et configurez des connexions via réseau social. Activez-les pour votre application dans les options de l’application dans l’onglet Connections (Connexions). L’exemple se base sur la base de données nom d’utilisateur/mot de passe, Facebook, Google, et X.

7. Sur l’écran Settings (Paramètres), notez les paramètres du domaine et de l’ID client dans la partie supérieure.

8. Deux valeurs doivent être définies dans l’application. Recherchez le fichier env et attribuez les valeurs ci-dessous :

   ISSUER_BASE_URL={yourDomain}
   CLIENT_ID={yourClientId}
   BASE_URL=http://localhost:3000
   APP_SESSION_SECRET=<YOUR SECRET VALUE>

   Was this helpful?

   Yes /No

1. Après avoir terminé la configuration du serveur et de l’environnement, cherchez la fenêtre de votre navigateur où l’application est ouverte. Si vous avez fermé le navigateur et arrêté le serveur, exécutez la commande suivante à partir du terminal pour redémarrer l’application : npm run dev

2. Ouvrez http://localhost:3000 dans votre navigateur. En ce qui a trait à l’expérience utilisateur, l’application devrait conserver la même apparence. Cependant, lorsque vous cliquerez sur le bouton Call API (Appeler l’API), un message d’avertissement devrait s’afficher indiquant que l’utilisateur n’est pas connecté. Notez également que vous ne voyez pas le message « Hello, World » comme avant puisque l’appel à l’API a été rejeté.

3. Cliquez sur Log in now (Se connecter maintenant) pour vous connecter. Une fois que vous avez été authentifié, vous retournerez à l’application et verrez une interface utilisateur mise à jour qui reflète votre nouveau statut de connexion. Vous devriez pouvoir cliquer à nouveau sur le bouton Call API (Appeler l’API) pour déclencher un nouvel appel vers le serveur, qui devrait désormais fonctionner correctement.

4. Cliquez sur le lien Profile (Profil) en haut de la page pour afficher les informations sur l’utilisateur récupérées à partir du jeton d’ID.

• Flux implicite avec Form Post
• Sécuriser
• Modifications des attributs du témoin SameSite