Comment le pattern Backend For Frontend (BFF) sécurise 🔐 votre application web !

Toutes les applications web qui utilisent le protocole OAuth 2.0 pour l’authentification sont confrontées à de nombreuses failles de sécurité. Parmis les solutions pour faire bouclier à ses attaques, c’est le pattern Backend For Frontend (BFF).

Définition du pattern BFF

Le pattern Backend for Frontend consiste à créer des passerelles conformes aux besoins spécifiques de chaque client. Le pattern BFF est considéré aussi comme une variante du pattern API Gateway.

Pour donner un exemple, nous pouvons créer un BFF dans le cas où nous avons une application web qui communique avec des services comme la solution Algolia qui utilise l’intelligence artificielle pour optimiser la recherche pour votre site ou une solution de paiement comme Stripe qui permet aux clients d’effectuer des achats en ligne. Le Pattern BFF peut également être utilisé dans l’authentification si nous communiquons par exemple avec un serveur de délégation d’authentification comme Auth0.

L’image ci-dessous représente l’acheminement d’une application web serverless avec des services externes sans l’utilisation d’un BFF.

Avec cette architecture, les services se comportent comme suit :

- Stripe : l’achat des articles se fait uniquement dans la partie frontend ( risque de fraude vu qu’il n’y a pas un serveur backend qui vérifie derrière l’intégrité de l’achat )

- Algolia : L’alimentation de nouvelles entrées pour la recherche se fait en front ( risque de compromettre la base de données des mots clés )
- Auth0 : L’authentification se fait uniquement en frontend ( risque d’usurpation d’identité )

L’image ci-dessous représente le même schéma précédent mais avec l’utilisation d’un BFF.

Comme l’image ci-dessus le montre, le BFF est une API intermédiaire entre une application web et le reste des services. Cela permet de faire abstraction de toute la complexité de la communication avec les services externes et laisser le frontend se concentrer pour offrir une bonne expérience utilisateur.

Par ailleurs, le fait de sortir toute la gestion de connexion avec les services en dehors du frontend, cela réduira la taille du bundle finale de l’application web, ce qui en résulte à un chargement très rapide dans les navigateurs web.

Maintenant que le BFF est mis en place, voilà comment les services se comportent :

- Stripe : La validation de l’achat se fait côté BFF, ce qui permet au développeur d’ajouter des couches de sécurité.
- Algolia : L’alimentation des mots clés se fait côté BFF, ce qui permet de vérifier l’identité du client avant d’enrichir la base de données.
- Auth0: La génération du jeton d’authentification se fait côté BFF, ce qui permet de cacher le token aux clients publiques.

Les risques de gérer l’authentification côté frontend

Les applications basées sur les navigateurs web présentent une surface d’attaque relativement large. Les risques de sécurité proviennent non seulement du code de l’application elle-même, qui doit être protégé contre les scripts intersites ( cross site ), la falsification des requêtes intersites et d’autres vulnérabilités, mais aussi des frameworks, bibliothèques et autres paquets NPM qu’elle utilise, ainsi que de toutes leurs dépendances transitives.

En outre, les autres applications fonctionnant sur le même site doivent également être sécurisées. Les récentes attaques Spectre contre les navigateurs nous rappellent que de nouvelles menaces apparaissent constamment. Compte tenu de tous ces risques, il n’est pas recommandé de stocker des jetons d’accès ou des jetons de rafraîchissement de grande valeur dans des emplacements accessibles par JavaScript.

De ce fait, en utilisant un BFF, les jetons d’authentification ne sont accessibles que côté serveur et les sessions sont gérées à l’aide de cookies HTTP cryptés et signés. Cela simplifie considérablement les menaces et réduit les risques. Bien que les attaques par injection de contenu soient toujours possibles, le BFF limite la capacité de l’attaquant à abuser des API en limitant l’accès par une interface bien définie au backend, ce qui élimine la possibilité d’appels d’API arbitraires.

Génération de jeton 🗝️ d’authentification sans BFF :

Génération de jeton 🗝️ d’authentification avec BFF :

Mise en place d’un BFF

Nous pouvons implémenter un BFF avec n’importe quel framework backend qui permet de mettre en place une authentification HTTP par Cookie pour protéger les endpoints ( entrées ) de l’API. Mais dans cet article, nous allons utiliser ASP.NET, et comme nous sommes fainéants, nous allons utiliser un framework qui va nous permettre d’aller encore plus vite s’appelant Duende – BFF Security Framework.

Étapes de mise en place :

1. Installation du framework
> dotnet add package Duende.BFF

2. Dans le fichier program.cs ajouter l’authentification par cookie et par openId dans les services :

30 janvier 2024

Par Mohamed GHEMID

Formez-vous avec la Creative Tech Academy !

Notre objectif : vous outiller pour être en mesure de répondre différemment et collectivement aux problèmes qui font partis de votre quotidien professionnel.

Les formations de la Creative Tech Academy

services.AddAuthentication(options =>
  {
    options.DefaultScheme = "cookie";
    options.DefaultChallengeScheme = "oidc";
    options.DefaultSignOutScheme = "oidc";
  })
  .AddCookie("cookie", options =>
  {
    options.ExpireTimeSpan = TimeSpan.FromHours(8);
    options.SlidingExpiration = false;
    options.Cookie.Name = "__Host-spa";
    options.Cookie.SameSite = SameSiteMode.Strict;
  })
  .AddOpenIdConnect("oidc", options =>
  {
    options.Authority = "https://demo.duendesoftware.com";
    options.ClientId = "spa";
    options.ClientSecret = "secret";
    options.ResponseType = "code";
    options.ResponseMode = "query";
    options.GetClaimsFromUserInfoEndpoint = true;
    options.SaveTokens = true;
    options.Scope.Clear();
    options.Scope.Add("openid profile api");
    options.Scope.Add("offline_access");
  });

3. Ajouter l’intégration du BFF dans les services

services.AddBff(options =>
  {
    options.ManagementBasePath = "/bff";
  };

4. Ajouter les routes de la gestion du BFF dans les routes du serveur

 app.UseEndpoints(endpoints =>
  {
    endpoints.MapBffManagementEndpoints();
  });

5. Ajouter le BFF dans les middlewares ( intercepteurs )

 app.UseAutentication();  
  app.UseBff();
  app.UseAuthorization();

NB: La ligne “app.UseBff()” doit être entre le middle d’authentification et d’autorisation.

6. Considérer que tous les contrôleurs sont des entrées BFF ( donc sécurisés )

app.MapControllers()
     .RequireAuthorization()
     .AsBffApiEndpoint();

7. Côté FrontEnd, il faut ajouter dans les entêtes ( headers ) des requêtes HTTP l’entête “x-csrf: 1″, La valeur de l’en-tête n’est pas importante, mais sa présence, combinée à l’exigence d’un cookie, déclenche une demande de contrôle préalable CORS pour les appels inter-origines. Cela permet d’isoler efficacement l’appelant à la même origine que le BackEnd, ce qui offre une garantie de sécurité solide.

Déclencher l’authentification

Pour déclencher l’authentification, il suffit d’appeler la ressource : “/bff/login” du BFF, cette dernière redirige le client vers la page d’authentification.

Une fois l’utilisateur connecté, un jeton est généré signé et crypté côté BFF et sera attaché et régénéré à chaque interaction avec le BFF.

Nous pouvons avoir les informations publiques du client en appelant la ressource “/bff/user”.

Enfin, La déconnexion se fait en appelant la ressource “/bff/logout” avec l’url de déconnexion contenant l’ID de la session récupéré des claims ( informations publiques du client ).

Conclusion

L’utilisation d’un BFF n’est pas toujours utile, notamment s’il n’y a pas d’authentification ou l’inexistence des services externes. En revanche, le pattern BFF est fortement recommandé pour assurer la sécurité minimale au sein d’une application web.

GHEMID Mohamed
Développeur Full Stack Senior chez Devoteam
Créateur de contenu
Site Web · YouTube · LinkedIn