Authentification et autorisation – la bonne manière !

Imaginez que vous créez une application Web ou mobile qui doit vérifier les utilisateurs, peut-être pour une plate-forme de médias sociaux, un site de commerce électronique ou même simplement un simple tableau de bord. À un moment donné, vous vous demanderez : « Comment puis-je garder mes utilisateurs connectés en toute sécurité ? »

C’est là que l’authentification entre en jeu. Mais avec autant de méthodes différentes parmi lesquelles choisir, comme la gestion de session, les jetons d'authentification et le JWT (JSON Web Token) de plus en plus populaire, il peut être difficile de déterminer laquelle convient le mieux à votre application. Alors, comment décidez-vous ?

Si vous avez beaucoup entendu parler de JWT et que vous vous demandez si cela en vaut la peine, vous êtes au bon endroit. Dans cet article de blog, nous allons expliquer ce qu'est JWT, comment il fonctionne et comment il se compare aux autres méthodes d'authentification courantes dans Django. À la fin, vous saurez clairement quand utiliser JWT et comment il se compare à d'autres options telles que l'authentification basée sur la session et les jetons d'authentification. Allons-y !

Qu'est-ce que JWT (jeton Web JSON) ?

JWT (JSON Web Token) est un format de jeton compact et sécurisé pour les URL utilisé pour transmettre en toute sécurité des informations entre les parties. Il est couramment utilisé dans les processus d'authentification où un client demande l'accès à des ressources, comme dans des applications Web ou mobiles.

Un JWT est composé de trois parties :

En-tête : contient des métadonnées sur le jeton, telles que le type (JWT) et l'algorithme de signature (par exemple, HS256).

Payload : contient des revendications spécifiques à l'utilisateur, telles que l'ID, le nom d'utilisateur ou le rôle de l'utilisateur.

Signature : garantit que le jeton n'a pas été falsifié en signant l'en-tête et la charge utile avec une clé secrète.

Un exemple de JWT pourrait ressembler à ceci :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImpvaG4iLCJleHAiOjE2MjEyMzY5MjZ9.GG7h8oV2C7Mcp93JK...

JWT est couramment utilisé dans l'authentification sans état, ce qui signifie que le serveur ne stocke pas les données de session. Au lieu de cela, toutes les informations nécessaires (réclamations) sont intégrées dans le jeton lui-même.

Comment fonctionne JWT : un processus étape par étape

Décomposons le fonctionnement de l'authentification JWT avec un scénario simple :

1. L'utilisateur se connecte
Un utilisateur soumet son e-mail et son mot de passe via un formulaire de connexion. Le serveur valide les informations d'identification et si elles sont correctes, le serveur génère un JWT qui contient les informations de l'utilisateur (comme son identifiant, son nom d'utilisateur et son rôle).

2. Jeton envoyé au client
Une fois le JWT généré, il est renvoyé au client, généralement dans le corps de la réponse. Le client stocke ce jeton (dans localStorage ou sessionStorage pour un navigateur, ou en toute sécurité sur un appareil mobile).

3. Les utilisateurs demandent des ressources protégées
Chaque fois que le client a besoin d'accéder à une route protégée, il envoie le JWT dans l'en-tête Authorization de la requête :

Authorization: Bearer <JWT_TOKEN>

Le serveur vérifie ensuite le jeton, garantissant sa validité et son intégrité, avant d'accorder l'accès à la ressource.

4. Expiration et actualisation du jeton
Étant donné que les jetons JWT ont un délai d'expiration (par exemple, 5 minutes), une fois qu'ils expirent, l'utilisateur peut envoyer un jeton d'actualisation pour obtenir un nouveau JWT sans avoir besoin de se reconnecter.

5. L'utilisateur se déconnecte
Lorsque l'utilisateur se déconnecte, le jeton d'actualisation est généralement mis sur liste noire (dans les configurations prenant en charge la liste noire), garantissant que l'utilisateur est effectivement déconnecté et ne peut plus actualiser le jeton.

JWT vs méthodes d'authentification traditionnelles dans Django

JWT est l'une des nombreuses façons d'implémenter l'authentification dans les applications Django. Voyons comment JWT se compare à d'autres méthodes courantes telles que la gestion de session et les jetons d'authentification.

1. Authentification JWT et gestion de session

Gestion des sessions :
Dans l'authentification basée sur la session, une fois qu'un utilisateur se connecte, le serveur crée une session et la stocke dans la base de données ou en mémoire. Un identifiant de session est ensuite envoyé au client via des cookies. Le client stocke l'ID de session et l'envoie à chaque demande. Le serveur récupère ensuite les données de session du stockage pour identifier l'utilisateur.

Scénario du monde réel :

Site Web de commerce électronique : Imaginez que vous vous connectez à une boutique en ligne, ajoutez des articles à votre panier et procédez au paiement. Chaque action au cours de cette session, comme consulter les produits ou mettre à jour le panier, est liée à votre identifiant de session stocké sur le serveur. Une fois déconnecté, la session est détruite.

JWT contre sessions :

- Rangement :

• JWT : sans état, pas de stockage côté serveur. Toutes les données sont contenues dans le jeton lui-même.
• Sessions : avec état, le serveur stocke les données de session (généralement dans une base de données ou une mémoire) et un identifiant de session est envoyé au client.

- Évolutivité :

• JWT : hautement évolutif ; pas besoin de stocker les informations de session utilisateur, ce qui facilite l'évolution horizontale sur les serveurs.
• Sessions : moins évolutives ; nécessite la gestion et le partage des données de session entre les serveurs (par exemple, en utilisant un magasin de sessions centralisé).

- Transfert de données :

• JWT : le jeton inclut toutes les données utilisateur (réclamations) et est envoyé avec chaque demande. Il peut devenir volumineux si trop de données sont incluses.
• Sessions : seul un identifiant de session est envoyé et les données utilisateur sont récupérées du serveur.

- Sécurité :

• JWT : vulnérable si les jetons ne sont pas stockés de manière sécurisée sur le client (par exemple, stockage local). Il est important de gérer l’expiration et l’actualisation des jetons en toute sécurité.
• Sessions : utilise généralement des cookies pour stocker l'ID de session, qui sont plus sécurisés si les indicateurs HTTP uniquement et sécurisés sont utilisés. Cependant, il peut être vulnérable aux attaques CSRF.

- Expiration & Gestion :

• JWT : les jetons ont un délai d'expiration. Si un jeton d'actualisation est utilisé, le jeton d'accès peut être renouvelé sans ré-authentification.
• Sessions : les sessions ont également un délai d'attente, mais peuvent facilement être prolongées tant que l'utilisateur interagit avec l'application.

- Taille du jeton :

• JWT : étant donné que toutes les données sont incluses dans le jeton, les JWT peuvent être plus volumineux, surtout s'ils contiennent de nombreuses informations utilisateur ou métadonnées.
• Sessions : seul l'ID de session est envoyé à chaque demande, le transfert de données est donc minime.

- Utilisation :

• JWT : préféré dans les API modernes et sans état, les applications à page unique (SPA) et les applications mobiles.
• Sessions : courantes dans les applications Web traditionnelles où le serveur gère l'état de l'utilisateur.

2. Authentification JWT et jetons d'authentification

Jetons d'authentification :
Dans l'authentification basée sur un jeton (comme l'authentification par jeton intégrée de Django), le serveur génère un jeton unique lorsque l'utilisateur se connecte. Ce jeton est stocké sur le serveur et envoyé au client, qui l'inclut dans chaque requête. Le serveur vérifie le jeton dans la base de données pour vérifier l'utilisateur.

Scénario du monde réel :

Accès API : Un fournisseur d'API (comme GitHub) génère un jeton API pour les utilisateurs après la connexion. Chaque fois que vous interagissez avec l'API GitHub, le jeton est transmis dans les en-têtes de la demande pour authentifier la demande. .

JWT contre jetons d'authentification :

- Stockage de jetons

JWT (jeton Web JSON) :

Apatride : les JWT sont autonomes, ce qui signifie que toutes les informations nécessaires (réclamations) sont stockées dans le jeton lui-même. Le serveur ne stocke pas le jeton, ce qui en fait un système sans état.
Le jeton est généralement stocké côté client (par exemple, dans localStorage, sessionStorage ou cookies) et envoyé avec chaque demande dans l'en-tête Authorization.

Jetons d'authentification :

Stateful : dans l'authentification traditionnelle basée sur un jeton, le jeton est généré et stocké côté serveur (souvent dans une base de données). Le serveur garde une trace du jeton et le client l'inclut dans chaque requête (généralement dans les en-têtes).

- Structure des jetons

JWT :

Autonome : les jetons JWT se composent de trois parties : l'en-tête, la charge utile et la signature. La charge utile contient des informations utilisateur (telles que l'identifiant, l'adresse e-mail, le rôle) et est signée pour garantir l'intégrité.

Jetons d'authentification :

Jetons opaques : les jetons d'authentification sont généralement des chaînes opaques, ce qui signifie qu'ils ne contiennent aucune information utilisateur. Ils agissent comme une référence à la session côté serveur ou aux données utilisateur.
Le serveur utilise ce jeton pour rechercher les informations de session ou d'utilisateur stockées sur le serveur.

- Stockage et évolutivité du serveur

JWT :

Pas de stockage sur le serveur : étant donné que les jetons JWT sont autonomes, le serveur n'a pas besoin de stocker les données de session ou de jeton. Cela le rend hautement évolutif, en particulier dans les systèmes distribués ou les architectures de microservices, où plusieurs serveurs peuvent être impliqués.

Jetons d'authentification :

Stockage côté serveur : les jetons d'authentification sont stockés dans une base de données ou dans la mémoire du serveur, ce qui signifie que le serveur doit suivre et valider le jeton pour chaque demande. Cela peut être moins évolutif puisque le serveur doit accéder à un magasin de sessions central pour chaque demande.

- Considérations de sécurité

JWT :

Basé sur la signature : les jetons JWT sont signés à l'aide d'algorithmes tels que HS256 ou RS256 pour garantir que le jeton n'a pas été falsifié. Bien que cela protège l’intégrité du jeton, cela ne crypte pas les données. Les données sensibles ne doivent pas être incluses dans la charge utile à moins qu'elles ne soient cryptées.

Risques côté client : les JWT sont souvent stockés dans localStorage ou sessionStorage, ce qui peut les rendre vulnérables aux attaques XSS (Cross-Site Scripting). Pour atténuer cela, ils peuvent être stockés dans des cookies HTTP uniquement.

Jetons d'authentification :

Validation côté serveur : étant donné que les jetons d'authentification ne contiennent pas d'informations utilisateur et sont validés par rapport à une session sur le serveur, ils peuvent être considérés comme plus sûrs contre la falsification. Cependant, ils sont vulnérables aux détournements de session ou aux attaques CSRF (Cross-Site Request Forgery) s’ils ne sont pas gérés correctement.

- Expiration et durée de vie du jeton

JWT :

Jetons d'accès de courte durée : les JWT ont généralement une courte durée de vie (par exemple, 5 à 15 minutes). Une fois expiré, le client doit utiliser un jeton d'actualisation pour obtenir un nouveau jeton d'accès. Il s’agit d’un élément clé du modèle de sécurité de JWT.
Jetons d'actualisation : les jetons d'actualisation de longue durée permettent aux utilisateurs de rester connectés sans devoir constamment saisir à nouveau leurs informations d'identification, mais ils comportent également leurs propres problèmes de sécurité (par exemple, ils doivent être stockés et gérés en toute sécurité).

Jetons d'authentification :

Aucune expiration de jeton par défaut : les jetons d'authentification n'expirent pas par défaut à moins qu'ils ne soient explicitement gérés par le serveur. Le serveur peut révoquer ou expirer les jetons, mais cela nécessite une logique et un stockage supplémentaires pour suivre l'expiration des jetons.

- Taille du jeton

JWT :

Taille de jeton plus grande : étant donné que les JWT contiennent des informations utilisateur (revendications) et la signature, ils ont tendance à être plus grands que les jetons d'authentification opaques. Cela peut légèrement augmenter l'utilisation de la bande passante, en particulier dans les scénarios avec des demandes fréquentes.

Jetons d'authentification :

Taille de jeton plus petite : les jetons d'authentification sont généralement des chaînes opaques, ce qui signifie qu'ils sont beaucoup plus petits en taille. Ils agissent comme un identifiant et ne transportent pas de données supplémentaires, ils utilisent donc moins de bande passante.

- Exemples de scénarios d'utilisation

JWT :

Applications à page unique (SPA) : les JWT fonctionnent bien avec les SPA (comme React ou Angular) où vous avez besoin d'une authentification sans état et d'aucune gestion de session côté serveur.

Microservices et API : les JWT sont idéaux pour les API et les architectures de microservices, où plusieurs services doivent authentifier les utilisateurs sans partager l'état de session entre les serveurs.
Jetons d'authentification :

Applications Web traditionnelles : dans les applications Web rendues par le serveur, les jetons d'authentification (ou sessions) sont couramment utilisés, car ils sont stockés et validés côté serveur, ce qui les rend parfaitement adaptés aux applications où le maintien d'une session est facile.
Applications à petite échelle : les jetons d'authentification fonctionnent bien pour les applications comptant moins d'utilisateurs, où la gestion des sessions ne devient pas un problème d'évolutivité.

- Apatridie vs. État

JWT :

Apatride : étant donné que les JWT ne nécessitent pas de stockage côté serveur, ils rendent les applications sans état. Ceci est avantageux pour une mise à l’échelle horizontale sur plusieurs serveurs, car il n’est pas nécessaire de synchroniser les sessions entre les serveurs.
Jetons d'authentification :

Avec état : les jetons d'authentification nécessitent un stockage de session côté serveur, ce qui signifie que le serveur garde une trace des données de session. Cela convient aux petites applications, mais peut s'avérer problématique lors d'une mise à l'échelle sur plusieurs serveurs, à moins qu'un magasin de sessions central (comme Redis) ne soit utilisé.

- Liste noire et révocation

JWT :

Difficile à révoquer : étant donné que les JWT sont sans état et ne sont pas stockés sur le serveur, il est difficile de les révoquer une fois émis, sauf si vous utilisez la liste noire des jetons. Cela signifie que si un jeton est compromis, il reste valide jusqu'à son expiration.

Liste noire requise : pour gérer la révocation des jetons (par exemple, lors de la déconnexion), un mécanisme de liste noire doit être implémenté sur le serveur pour suivre les jetons invalidés.

Jetons d'authentification :

Facile à révoquer : les jetons d'authentification sont stockés sur le serveur, leur révocation ou leur invalidation est donc simple.

3. Authentification JWT et authentification de base

Authentification de base :
Dans l'authentification de base, le client envoie les informations d'identification de l'utilisateur (nom d'utilisateur et mot de passe) à chaque demande, généralement codées en base64. Cette méthode est souvent utilisée dans les systèmes internes ou les configurations simples.

Scénario du monde réel :

Tableau de bord d'administration interne : le tableau de bord d'administration interne d'une petite entreprise nécessite que les utilisateurs se connectent avec une authentification de base. Lorsque les utilisateurs accèdent à une page, leurs informations d'identification sont envoyées dans la demande.

Cas d'utilisation réel : quand utiliser JWT ?

Prenons un exemple concret : une plateforme de médias sociaux sur laquelle les utilisateurs se connectent, interagissent avec des publications et gèrent leurs profils sur plusieurs appareils.

Dans un tel système :

1. JWT fonctionne bien car il est sans état, ce qui signifie que le serveur n'a pas besoin de stocker les sessions utilisateur.
2. Le client peut stocker le jeton localement, ce qui permet aux utilisateurs de rester connectés sur différents onglets et appareils.
3. Étant donné que l'application peut évoluer horizontalement sur plusieurs serveurs (par exemple, un serveur pour gérer les publications et un autre pour les profils), l'utilisation de JWT facilite la mise à l'échelle sans avoir besoin d'un magasin de session central.
4. Les utilisateurs peuvent également actualiser périodiquement leurs jetons pour conserver l'accès sans avoir à se reconnecter.

Conclusion : quelle méthode d’authentification choisir ?

Le choix de la bonne méthode d'authentification dépend des exigences de votre application :

JWT est idéal pour les applications sans état et évolutives (telles que les SPA, les applications mobiles et les microservices).
L'authentification basée sur la session fonctionne bien pour les applications Web traditionnelles où l'évolutivité n'est pas une préoccupation majeure.
Les jetons d'authentification sont une méthode simple et sécurisée pour l'authentification API à petite échelle où le stockage des jetons côté serveur est gérable.

Chaque méthode a ses forces et ses faiblesses, mais JWT se distingue par sa capacité à gérer des systèmes modernes et distribués où l'évolutivité et la flexibilité sont essentielles.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!