Jeton daccès cookie

Le contrôle d’accès dans les sites Web et les applications Web est une priorité absolue pour la sécurité, mais la façon dont vous configurez l’accès dépend de la façon dont vous stockez les données à authentifier. Ceci, à son tour, permet l’autorisation de l’utilisateur.

Les jetons, qui font généralement référence aux jetons Web JSON (JWT), sont des informations d’identification signées encodées dans une longue chaîne de caractères créée par le serveur.

Dans cette optique, pourquoi est-il nécessaire de stocker l’authentification sur le navigateur ? Étant donné que HTTP est sans état, même si vous vous authentifiez avec une requête, le serveur « oublie » essentiellement cette authentification avec les requêtes suivantes.

À propos de l’authentification

L’authentification consiste à vérifier les informations d’identification de l’utilisateur en termes d’exactitude ou de temps.

Exactitude : Les informations d’identification de l’utilisateur sont vérifiées sur la base des détails existants. Lors de la demande de connexion, un jeton d’authentification est attribué à l’utilisateur. Il sera utilisé pour autoriser l’utilisateur et authentifier les interactions ultérieures avec l’application.
Temps : Le jeton d’authentification attribué à l’utilisateur n’est valable que pour une période déterminée. Si le jeton n’est plus valide, l’utilisateur doit être réauthentifié avant que l’accès puisse être accordé.

Le terme « jeton d’authentification » est utilisé ici pour décrire toute forme d’informations d’identification d’authentification qui peut être implémentée par l’application, et non explicitement un jeton d’accès.

Les instances ci-dessus ne sont pas spécifiques à l’environnement et peuvent être démontrées visuellement sur le frontend ou backend pendant les tests d’API.

Pourquoi utiliser l’authentification

Il existe deux raisons pour lesquelles l’authentification est nécessaire pour permettre un accès complet à une application :

L’authentification établit l’identité de l’utilisateur et vérifie que l’utilisateur est bien celui (ou ce qu’il prétend être). L’authentification protège vos ressources en refusant l’accès aux utilisateurs non authentifiés.
L’authentification donne à chaque utilisateur une identité distincte, protégeant ainsi vos données et les siennes. Les applications qui demandent aux utilisateurs de créer un compte donnent à chaque utilisateur un profil unique, qui détermine les données affichées à l’utilisateur. Par exemple, PayPal demande aux utilisateurs de se connecter avant d’afficher le solde de leur compte et leurs transactions.

En général, le processus fonctionne comme suit :

Vous vous connectez.
Le serveur vérifie vos informations de connexion et vous attribue un jeton d’authentification.
Le jeton d’authentification est utilisé pour faire une requête à votre page d’accueil qui affiche votre tableau de bord unique.

Ce qui suit est une comparaison des deux.

Ils contiennent des données que le serveur envoie au navigateur pour une utilisation temporaire. Le serveur conserve le suivi des sessions actives dans une base de données, tandis que le navigateur conserve l’identificateur de la session active. Lorsqu’une demande est adressée au serveur, l’ID de session est utilisé pour rechercher des informations telles que les rôles d’utilisateur ou les privilèges d’authentification, afin de vérifier si la session est toujours valide.

Considérez ces avantages clés :

: Ils prennent un Setting the domain name to autorise la même session pour le domaine et les sous-domaines.
: Vous pouvez restreindre l’accès côté client en définissant l’indicateur. Cela réduit la probabilité d’attaques XSS (Cross-Site Scripting) sur votre application, car la plupart des attaques XSS impliquent l’utilisation de code JS malveillant.
Ils nécessitent peu de stockage
: c’est automatique, vous n’avez donc pas à vous en soucier.

Attaques de falsification de requêtes intersites (XSRF ou CSRF) Paramètres laxistes. Un paramètre strict peut empêcher les attaques CSRF, mais il peut également contribuer à une mauvaise expérience de navigation pour l’utilisateur. Déterminer si un utilisateur a déjà vu des tutoriels spécifiques afin de lui en montrer de nouveaux à chaque visite. Si est défini sur Cela crée une expérience utilisateur moins personnalisée.
Problèmes de mise à l’échelle : Étant donné que les sessions sont liées à un serveur particulier, vous pouvez rencontrer des problèmes lors de la mise à l’échelle de votre application. Dans une application à charge équilibrée, si un utilisateur connecté est redirigé vers un nouveau serveur, les données de session existantes sont perdues. Pour éviter cela, les sessions doivent être stockées dans une base de données partagée ou un cache. Cela augmente la complexité de chaque interaction.
Pas bon pour l’authentification API : les API fournissent des ressources uniques pour les utilisateurs finaux authentifiés et n’ont pas besoin de suivre les sessions utilisateur. Les jetons, quant à eux, fournissent une authentification avec un identifiant unique sur chaque requête adressée aux points de terminaison de l’API.

L’application de HTTPS empêche la divulgation de l’ID de session dans les attaques MITM (Person-in-the-middle).
Cela peut être évité en utilisant le drapeau.

Les

jetons, ou JWT dans ce contexte, sont de nature sans état, ce qui signifie que le serveur n’a pas besoin de conserver un enregistrement du jeton. Chaque jeton est autonome, contenant les informations nécessaires à la vérification et à l’identification sur le serveur.

Avantages des tokens

Voici quelques avantages spécifiques des tokens :

Flexibilité et facilité d’utilisation : Les JWT sont faciles à utiliser. Leur nature autonome vous permet d’obtenir ce dont vous avez besoin pour la vérification sans recherches dans les bases de données. Cela rend les JWT plus adaptés à l’utilisation dans une API, car le serveur d’API n’a pas besoin de suivre les sessions utilisateur.
Capacités multiplateformes
Plusieurs options de stockage : Les jetons peuvent être stockés de plusieurs façons dans les navigateurs ou les applications frontales.

Si vous utilisez le stockage local d’un navigateur, les jetons ne sont pas accessibles par un sous-domaine. Il ne s’agit pas d’une méthode recommandée : tout d’abord, elle présente un risque pour la sécurité, et vous devez gérer le stockage.

Le stockage de session est une autre façon de stocker des jetons. L’inconvénient est que Le jeton est détruit à la fermeture du navigateur.

Inconvénients des tokens JWT

Voici quelques inconvénients des tokens à connaître :

Révocation : Un JWT ne peut pas être révoqué. Même si un JWT fuit, il reste valide jusqu’à son expiration, ce qui entraîne une grave faille de sécurité. Pour contourner ce problème, vous devez implémenter une technique de liste refusée qui nécessite une configuration plus complexe.
Besoin de plus d’espace : Un JWT peut avoir besoin de 300+ octets pour stocker un simple ID utilisateur, car il stocke d’autres données pour l’authentification.
Obsolète : Les informations à l’intérieur d’un JWT représentent un instantané dans le temps au moment de la création initiale du jeton. L’utilisateur associé peut maintenant avoir des niveaux d’accès différents ou avoir été supprimé du système tout court.

Mais qu’en est-il de la sécurité des tokens ?

Les JWT sont signés cryptographiquement et encodés en base64. Ils ne sont sécurisés que lorsqu’ils ne sont pas exposés, ils doivent donc être traités comme des mots de passe.
Un JWT peut être visualisé, mais pas manipulé côté client. Vous pouvez apporter votre jeton à jwt.io, choisir l’algorithme que vous avez utilisé pour signer et voir les données. Vous ne pouvez tout simplement pas le modifier car il est émis sur le serveur.
La durée de vie d’un JWT doit être courte afin de limiter le risque causé par une fuite d’un jeton.

Vous pouvez utiliser des jetons lors de la création de services d’API ou de l’implémentation de systèmes distribués.

Je suis développeur web et étudiant en informatique.

Article précédentArticle suivant