Architecture sans état et avec état

Fait référence à l'état de l'application, c'est-à-dire la condition ou la qualité de celle-ci à un instant donné. Dans l'authentification sans état, aucune session ou utilisateur n'est stocké, contenant uniquement du contenu statique. Cela diffère du contenu avec état, qui est un contenu dynamique.

Un processus sans état est une ressource isolée, qui ne fait référence à aucun autre service ou interaction avec un autre système. Il fonctionne uniquement dans cette partie du code, sans apporter d'informations provenant d'anciennes transactions, car l'authentification sans état ne stocke pas ce type de données ; chaque opération est effectuée à partir de zéro.

L'authentification avec état permet aux informations d'être utilisées plusieurs fois et est exécutée en fonction du contexte des transactions précédentes. Par conséquent, dans les applications où il est nécessaire d'attendre une réponse ou des données préexistantes, qu'elles soient présentes dans un autre système ou base de données, le mode stateful est utilisé.

Authentification sans état

L'authentification sans état consiste en une stratégie dans laquelle, après avoir fourni ses informations d'identification, l'utilisateur reçoit un jeton d'accès en réponse. Ce token contient déjà toutes les informations nécessaires pour identifier l'utilisateur qui l'a généré, sans qu'il soit nécessaire de consulter en permanence le service qui a émis le token ou une base de données.

Ce jeton est stocké côté client (navigateur), de sorte que le serveur n'a la possibilité de vérifier la validité du jeton qu'en confirmant que la charge utile et la signature correspondent.

Authentification sans état JWT

JSON Web Token (JWT) sont des clés aux normes établies dans la RFC-7519, contenant une entité sous forme de déclarations, indépendantes, sans qu'il soit nécessaire d'appeler le serveur pour revalider le jeton.

Les chaînes sont-elles codées au standard base64 à l'aide d'une clé secrète, comme dans l'exemple :

Avantages et inconvénients

Avantages :

• Faible consommation de mémoire du serveur.
• Excellent en termes d'évolutivité.
• Idéal pour les applications distribuées, telles que les API et les microservices.
• Génération et distribution du token dans une application isolée, sans dépendance vis-à-vis de tiers.
• Interprétation et validation faciles des données utilisateur du jeton.

Inconvénients :

• Difficulté de contrôle d'accès.
• Il n'est pas possible de révoquer facilement le token à tout moment.
• Cela peut faciliter l'entrée de tiers malveillants, si quelqu'un a accès au jeton.
• La session ne peut pas être modifiée jusqu'à l'expiration du jeton.
• Le jeton JWT est plus complexe et peut devenir inutile dans les applications centralisées, telles que les monolithes.

Authentification avec état

Couramment utilisée dans diverses applications, en particulier celles qui ne nécessitent pas autant d'évolutivité, la session avec état est créée dans le back-end de l'application et la référence de session est renvoyée à l'utilisateur correspondant. . Chaque fois que l'utilisateur fait une demande, une partie de l'application génère le token. A partir de ce moment, à chaque nouvelle demande, ce token sera à nouveau envoyé à l'application pour revalider l'accès. Dans ce modèle, en cas de modification des données utilisateur, le jeton peut être facilement révoqué.

Il s'agit de jetons d'accès opaques, c'est-à-dire une simple chaîne dans un format propriétaire qui ne contient aucun identifiant ni aucune donnée utilisateur relative à ce jeton. Le destinataire doit appeler le serveur qui a créé le jeton pour le valider.

Exemple de jeton : 8c90e55a-e867-45d5-9e42-8fcbd9c30a74

Cet identifiant doit être stocké dans une base de données avec l'utilisateur propriétaire du token.

Avantages et inconvénients

Avantages :

• Logique de mise en œuvre centralisée.
• Gestion et contrôle des accès simplifiés.
• Excellent pour les monolithes, les applications MVC et les processus internes.
• Plus sécurisé contre les tiers malveillants.

Inconvénients :

• Il peut y avoir une surcharge dans l'API chargée de valider le jeton.
• Échec en termes d'évolutivité.
• Plus grande difficulté à distribuer l'authentification entre les microservices.
• Dans une application distribuée, si le service d'authentification échoue, tous les autres services deviennent indisponibles.
• Une plus grande complexité de mise en œuvre.
• Plus grande difficulté à intégrer des systèmes tiers.

Quand utiliser chaque approche ?

Quand utiliser un jeton JWT et une authentification sans état

• Lorsque de plus grandes performances sont nécessaires sans se soucier de la surcharge d'une API.
• Lorsqu'il y a plusieurs communications réparties entre les services.
• Lorsqu'il est nécessaire d'identifier quel utilisateur effectue une action dans le système dans différents services.
• Lorsqu'il n'est pas prévu de conserver les données d'un utilisateur, uniquement son inscription initiale.
• S'il est nécessaire de générer un accès externe au service.
• S'il est nécessaire de manipuler les données de celui qui effectue une certaine action avec un impact minimal sur le système.

Quand utiliser un jeton opaque et une authentification avec état

• Si un contrôle d'accès complet des utilisateurs d'un système est nécessaire, principalement pour définir la hiérarchie d'accès.
• Dans une application centralisée, sans services distribués et sans communication avec des services externes.

Considérations finales :

• Dans certains endroits, comme « stress API », le terme peut être remplacé par « surcharge API » pour plus de clarté.
• La section sur le « Jeton JWT » pourrait inclure une explication plus détaillée de ce que sont les « déclarations » mentionnées dans la RFC-7519, si le public cible a besoin de plus de contexte.
• Dans la section sur l'authentification avec état, l'expression « une partie de l'application générera le jeton » pourrait être clarifiée en expliquant quelle partie spécifique de l'application en est responsable.