Angulaire 12 jwt authentification

Cet article est un guide étape par étape pour la conception et l’implémentation de l’authentification basée sur JWT dans une application Angular.

L’objectif ici est de discuter de la conception et de la mise en œuvre de l’authentification basée sur JWT en général, en passant en revue les multiples options de conception et les compromis de conception impliqués, puis d’appliquer ces concepts dans le contexte spécifique d’une application Angular.

Nous suivrons le parcours complet d’un JWT depuis sa création sur le serveur d’authentification jusqu’au client, puis de retour au serveur d’applications et parlerons de toutes les options de conception et des décisions impliquées.

Étant donné que l’authentification nécessite également du code serveur, nous allons également le montrer afin d’avoir le contexte complet et de voir comment toutes les parties multiples fonctionnent ensemble.

Le code du serveur sera en Node / Typescript, car il est très familier aux développeurs Angular, mais les concepts abordés ne sont pas spécifiques à un nœud.

Si vous utilisez une autre plate-forme serveur, il suffit de choisir une bibliothèque JWT pour votre plate-forme à jwt.io, et avec elle, tous les concepts s’appliqueront toujours.

Table des matières

Dans cet article, nous aborderons les sujets suivants :

Étape 1 - La page de connexion
- L’authentification basée sur JWT en bref
- La connexion de l’utilisateur dans une application Angular
- Pourquoi utiliser une page de connexion hébergée séparément ?
- Connectez-vous directement à notre application monopage
Étape 2 - Création d’une session utilisateur basée sur JWT
Étape 3 - Renvoi d’un JWT au client
- Où stocker un jeton de session JWT ?
Étape 4 - Stockage et utilisation du JWT côté client
Étape 5 - Renvoi du JWT au serveur sur chaque requête
- Comment créer un intercepteur HTTP d’authentification
Étape 6 - Validation des demandes des utilisateurs
- Création d’un middleware Express personnalisé pour la validation JWT
- Configuration d’un middleware de validation JWT à l’aide de express-jwt
- Validation des signatures JWT - Points de terminaison RS256
- RS256 vs HS256
- JWKS (JSON Web Key Set) et rotation
- des clés Implémentation de la rotation de clés JWKS à l’aide de node-jwks-rsa
Résumé et conclusions

Alors, sans plus attendre, commençons à apprendre l’authentification angulaire basée sur JWT !

Commençons

par présenter comment les jetons Web JSON peuvent être utilisés pour établir une session utilisateur : en bref, les JWT sont des charges utiles JSON signées numériquement, encodées dans un format de chaîne compatible avec les URL.

Un JWT peut contiennent n’importe quelle charge utile en général, mais le cas d’utilisation le plus courant consiste à utiliser la charge utile pour définir une session utilisateur.

L’essentiel avec les JWT est que pour confirmer s’ils sont valides, il suffit d’inspecter le jeton lui-même et de valider la signature, sans avoir à contacter un serveur distinct pour cela, ou à garder les jetons en mémoire ou dans la base de données entre les demandes.

Si des JWT sont utilisés pour l’authentification, ils contiendront au moins un ID utilisateur et un horodatage d’expiration.

Si vous souhaitez connaître tous les détails du format JWT en profondeur, y compris le fonctionnement des types de signature les plus courants, jetez un coup d’œil à cet article JWT : Le guide complet des jetons Web JSON.

Si vous êtes curieux de savoir à quoi ressemble un JWT, voici un exemple :

vous vous demandez peut-être : cela ne ressemble pas à du JSON ! Où se trouve le JSON alors ?

Pour le voir, rendons-jwt.io et collez la chaîne JWT complète dans l’outil de validation, nous verrons alors la charge utile JSON :

La propriété contient l’identificateur de l’utilisateur et la propriété contient l’horodatage d’expiration. Ce type de jeton est connu sous le nom de jeton porteur, ce qui signifie qu’il identifie l’utilisateur qui le possède et définit une session utilisateur.

Un jeton au porteur est un remplacement temporaire signé de la combinaison nom d’utilisateur/mot de passe !

Si vous souhaitez en savoir plus sur les JWT, jetez un coup d’œil ici. Pour le reste de cet article, nous supposerons qu’un JWT est une chaîne contenant une charge utile JSON vérifiable, qui définit une session utilisateur.

La toute première étape de la mise en œuvre de l’authentification basée sur JWT consiste à émettre un jeton de porteur et à le donner à l’utilisateur, et c’est l’objectif principal d’une page de connexion / inscription.

Étape 1 - L’authentification de la page de connexion

commence par un Page de connexion, qui peut être hébergée soit dans notre domaine, soit dans un domaine tiers. Dans un scénario d’entreprise, la page de connexion est souvent hébergée sur un serveur distinct, qui fait partie d’une solution d’authentification unique à l’échelle de l’entreprise.

Sur l’Internet public, la page de connexion peut également être :

hébergée par un fournisseur d’authentification tiers tel que Auth0
disponible directement dans notre application à page unique à l’aide d’un itinéraire d’écran de connexion ou d’une fenêtre modale

Une page de connexion hébergée séparément est une amélioration du point de vue de la sécurité car de cette façon, le mot de passe n’est jamais directement géré par notre code d’application en premier lieu.

Mais tout de même, la connexion d’un utilisateur via un écran de connexion à l’intérieur de notre application est également une solution viable et couramment utilisée, alors couvrons cela aussi.

Page de connexion directement sur l’application SPA

Si nous créons une page de connexion directement dans notre SPA, voici à quoi cela ressemblerait :

Comme nous pouvons le voir, cette page serait un simple formulaire avec deux champs : l’email et le mot de passe. Lorsque l’utilisateur clique sur le bouton Connexion, l’utilisateur et le mot de passe sont envoyés à un service d’authentification côté client via un appel.

Pourquoi créer un service d’authentification distinct ?

Le fait de placer toute notre logique d’authentification client dans un singleton centralisé à l’échelle de l’application nous aidera à garder notre code organisé.

De cette façon, si, par exemple, nous devons changer de fournisseur de sécurité ou refactoriser notre logique de sécurité, nous n’avons qu’à changer cette classe.

Dans les deux cas, l’objectif est le même : faire passer la combinaison utilisateur-mot de passe sur le serveur d’authentification via une requête POST, afin que le mot de passe puisse être validé et la session lancée.

Voici comment nous construirions nous-mêmes le HTTP POST à l’aide du client HTTP Angular :

Nous appelons pour éviter que le destinataire de cet Observable ne déclenche accidentellement plusieurs requêtes POST en raison de plusieurs abonnements.

Avant de traiter la réponse de connexion, suivons d’abord le flux de la requête et voyons ce qui se passe sur le serveur.

Étape 2 - Création d’un jeton de session JWT

Que nous utilisions une page de connexion au niveau de l’application ou une page de connexion hébergée, la logique du serveur qui gère la requête POST de connexion sera la même.

Le but est dans les deux cas de valider le mot de passe et d’établir une session. Si le mot de passe est correct, le serveur émettra un jeton porteur indiquant :

Le porteur de ce jeton est l’utilisateur avec l’ID technique 353454354354353453, et la session est valide pour les deux prochaines heures

Le jeton doit ensuite être signé et renvoyé au navigateur de l’utilisateur ! L’élément clé est la signature numérique JWT : c’est la seule chose qui empêche un attaquant de falsifier des jetons de session.

Voici à quoi ressemble le code pour la création d’un nouveau jeton de session JWT, à l’aide d’Express et du package de nœud node-jsonwebtoken :

Il se passe beaucoup de choses dans ce code, nous allons donc le décomposer ligne par ligne :

Nous commençons par créer une application Express
ensuite, nous configurons le middleware, pour donner à Express la possibilité de lire les charges utiles JSON à partir du corps
de la requête HTTP Nous avons ensuite défini un gestionnaire de route nommé , qui se déclenche si le serveur reçoit une requête POST ciblant l’URL

À l’intérieur de la méthode, nous avons du code qui montre comment la route de connexion peut être implémentée :

nous pouvons accéder à la charge utile du corps de la requête JSON en utilisant , en raison de la présence du middleware
que nous avons commençons par récupérer l’e-mail et le mot de passe dans le corps de la demande
, puis nous allons valider le mot de passe, et voir s’il est correct
si le mot de passe est erroné puis nous renvoyons le code d’état HTTP 401 Non autorisé
si le mot de passe est correct, nous commençons par récupérer l’identifiant
technique de l’utilisateur Nous signons la charge utile à l’aide de la bibliothèque node-jsonwebtoken et choisissons le type de signature RS256 (nous y reviendrons dans un instant)
Le résultat de l’appel est la chaîne JWT elle-même

Pour résumer, nous avons validé le mot de passe et créé un jeton de session JWT. Maintenant que nous avons une bonne image du fonctionnement de ce code, concentrons-nous sur la partie clé qui est la signature du JWT contenant les détails de la session utilisateur, à l’aide d’une signature RS256.

Pourquoi le type de signature est-il important ? Parce que si nous ne le comprenons pas, nous ne le ferons pas comprendre le code du serveur d’applications dont nous aurons besoin pour valider ce jeton.

Que sont les signatures RS256 ?

RS256 est un type de signature JWT basé sur RSA, qui est une technologie de chiffrement à clé publique largement utilisée.

L’un des principaux avantages de l’utilisation d’une signature RS256 est que nous pouvons séparer la possibilité de créer des jetons de la possibilité de les vérifier.

Vous pouvez lire tous les avantages de l’utilisation de ce type de signatures dans le Guide JWT, si vous souhaitez savoir comment les reproduire manuellement.

En un mot, les signatures RS256 fonctionnent de la manière suivante :

une clé privée (comme dans notre code) est utilisée pour signer les JWT
une clé publique est utilisée pour les valider
les deux clés ne sont pas interchangeables : elles peuvent soit signer uniquement des jetons, soit seulement les valider, mais aucune des deux clés ne peut faire les deux choses

Pourquoi RS256 ?

Pourquoi utiliser la crypto à clé publique pour signer les JWT ? Voici quelques exemples d’avantages à la fois sécuritaires et opérationnels :

il suffit de déployer la clé de signature privée dans le Serveur d’Authentification, et non sur les multiples serveurs d’applications qui utilisent le même Serveur
d’authentification. Nous n’avons pas besoin d’arrêter l’Authentification et les serveurs d’applications de manière coordonnée, afin de changer une clé partagée partout en même temps
. la clé publique peut être publiée dans une URL et lue automatiquement par le serveur d’applications au démarrage et périodiquement

Cette dernière partie est une fonctionnalité intéressante : la possibilité de publier la clé de validation nous donne la rotation et la révocation de clés intégrées, et nous allons implémenter cela dans cet article !

En effet, pour activer une nouvelle paire de clés, nous publions simplement une nouvelle clé publique, et nous verrons cela en action.

RS256 vs HS256

Une autre signature couramment utilisée est HS256, qui ne présente pas ces avantages.

HS256 est toujours couramment utilisé, mais par exemple, des fournisseurs tels que Auth0 utilisent désormais RS256 par défaut. Si vous souhaitez en savoir plus sur les signatures HS256, RS256 et JWT en général, jetez un coup d’œil à cet article.

Quel que soit le type de signature que nous utilisons, nous devons renvoyer le jeton fraîchement signé au navigateur de l’utilisateur.

Étape 3 - Renvoi d’un JWT au client

Nous avons plusieurs façons différentes de renvoyer le jeton à l’utilisateur, par exemple :

Dans le corps de la requête
Dans un en-tête

HTTP simple

Ces données peuvent être n’importe quoi, comme par exemple la langue préférée de l’utilisateur, mais elles peuvent également contenir un utilisateur jeton d’identification, comme par exemple un JWT.

Ainsi, nous pouvons par exemple y stocker un JWT

Voici comment cela fonctionne :

quelqu’un vous envoie un lien et vous cliquez dessus
Le serveur reçoit un JWT valide, il n’y a donc aucun moyen pour le serveur de distinguer cette attaque d’une requête valide

Cela signifie qu’un attaquant pourrait inciter un utilisateur à effectuer certaines actions en son nom, simplement en envoyant un e-mail ou en publiant un lien dans un forum public.

Cette attaque est moins puissante qu’il n’y paraît mais le problème est qu’elle est très facile à réaliser : il suffit de est un e-mail ou une publication sur les réseaux sociaux.

La bonne nouvelle, c’est que tous les principaux frameworks sont livrés avec des défenses qui peuvent être facilement mises en place contre XSRF, car il s’agit d’une vulnérabilité bien connue.

En effet, une application s’exécutant sur .

Pouvons-nous obtenir le meilleur des deux solutions ?

Les fournisseurs d’authentification tiers peuvent nous permettre d’exécuter la page de connexion hébergée en externe dans un sous-domaine configurable de notre site Web, comme par exemple .

Il serait donc possible d’obtenir le meilleur de toutes ces solutions combinées. Voici à quoi ressemblerait la solution :

une page de connexion hébergée en externe fonctionnant sur notre propre sous-domaine , et une application fonctionnant sur
Plus, nous devons ajouter quelques défenses XSRF, mais il existe des solutions bien comprises pour cela

Cela nous donnerait une protection maximale contre les scénarios de vol de mot de passe et de jeton d’identité :

l’application ne reçoit jamais le mot de passe en premier lieu
, le code de l’application n’accède jamais à la session JWT, seul le navigateur dans
lequel l’application n’est pas vulnérable à la falsification de demande (XSRF)

Ce scénario est parfois utilisé dans les portails d’entreprise et offre d’excellentes fonctionnalités de sécurité. Toutefois, cela dépend du fournisseur de sécurité ou du proxy de sécurité d’entreprise que nous utilisons pour prendre en charge un domaine personnalisé pour les pages de connexion hébergées.

Renvoi du JWT dans le corps

de la réponse HTTP

Non seulement nous voulons renvoyer le JWT lui-même, mais il est préférable d’envoyer également l’horodatage d’expiration en tant que propriété distincte.

Il est vrai que l’horodatage d’expiration est également disponible à l’intérieur le JWT, mais nous voulons permettre au client d’obtenir facilement la durée de la session sans avoir à installer une bibliothèque JWT juste pour cela.

Voici comment nous pouvons renvoyer le JWT au client dans le corps de la réponse HTTP :

Et avec cela, le client recevra à la fois le JWT et son horodatage d’expiration.

Mais cela signifie également que nous devrons ajouter du code client pour gérer le jeton, car le navigateur ne le transmettra plus au serveur d’applications à chaque requête.

Il s’agit d’un bon exemple des compromis de conception qui sont souvent associés au choix d’une solution de sécurité : il y a généralement un compromis entre sécurité et commodité.

Continuons ensuite à suivre le parcours de notre JWT Bearer Token. Étant donné que nous renvoyons le JWT au client dans le corps de la demande, nous devrons le lire et le gérer.

Étape 4 - Stockage et utilisation du JWT côté client

Une fois que nous recevons le JWT sur le client, nous devons le stocker quelque part, sinon il sera perdu si nous actualisons le navigateur et devrons nous reconnecter.

Un endroit pratique pour stocker le JWT est le stockage local, qui est un magasin de clés/valeurs pour les valeurs de chaîne, idéal pour stocker une petite quantité de données.

Notez que le stockage local dispose d’une API synchrone. Jetons un coup d’œil à une implémentation de la logique de connexion/déconnexion à l’aide du stockage local :

Décomposons ce qui se passe dans cette implémentation, en commençant par la méthode de connexion :

Nous recevons le résultat de l’appel de connexion, contenant le JWT et la propriété, et nous le transmettons directement à la méthode
à l’intérieur, nous stockons le JWT directement dans le stockage local dans l’entrée de clé
Nous prenons l’instant actuel et la propriété, et l’utiliser pour calculer l’horodatage d’expiration Ensuite,
nous enregistrons également l’horodatage d’expiration en tant que valeur numérique dans l’entrée Stockage local

Maintenant que nous avons toutes les informations de session du côté client, nous pouvons utiliser ces informations dans le reste de l’application cliente.

Par exemple, l’application cliente a besoin de savoir si l’utilisateur est connecté ou déconnecté, afin de décider si certains éléments de l’interface utilisateur tels que les boutons de menu Connexion / Déconnexion doivent être affichés ou non.

Cette information est maintenant disponible via les méthodes , et .

Envoi du JWT au serveur à chaque requête

Maintenant que le JWT est enregistré dans le navigateur de l’utilisateur, continuons à suivre son parcours sur le réseau.

Voyons comment nous allons l’utiliser pour indiquer au serveur d’applications qu’une requête HTTP donnée appartient à un utilisateur donné, qui est tout l’intérêt de la solution d’authentification.

Voici ce que nous devons faire : nous avons besoin avec chaque requête HTTP envoyée au serveur d’applications, d’ajouter d’une manière ou d’une autre également le JWT !

Le serveur d’applications va ensuite valider la requête et la lier à un utilisateur, simplement en inspectant le JWT, en vérifiant sa signature et en lisant l’identifiant de l’utilisateur à partir de la charge utile.

Pour s’assurer que chaque requête inclut un JWT, nous allons utiliser un intercepteur HTTP Angular.

Voici

le code d’un intercepteur Angular, qui inclut le JWT avec chaque requête envoyée au serveur d’applications :

Voyons ensuite comment fonctionne ce code ligne par ligne :

nous commençons par récupérer la chaîne JWT directement du stockage local
, puis nous allons vérifier si le JWT est présent si le JWT est présent
si le JWT n’est pas présent, puis la requête passe au serveur sans modification
si le JWT est présent, puis nous clonerons les en-têtes HTTP et ajouterons un en-tête supplémentaire, qui contiendra le JWT

Et avec cela en place, le JWT qui a été initialement créé sur le serveur d’authentification, est maintenant envoyé avec chaque demande au serveur d’application.

Voyons ensuite comment le serveur d’applications va utiliser le JWT pour identifier l’utilisateur.

Afin d’authentifier la demande, nous allons devoir extraire le JWT de l’en-tête, et vérifier l’horodatage et l’identifiant de l’utilisateur.

Nous ne voulons pas appliquer cette logique à toutes nos routes principales, car certaines routes sont accessibles publiquement à tous les utilisateurs. Par exemple, si nous avons créé nos propres itinéraires de connexion et d’inscription, ces itinéraires doivent être accessibles à tous les utilisateurs.

De plus, nous ne voulons pas répéter l’authentification logique par route, de sorte que la meilleure solution consiste à créer un middleware d’authentification express et à ne l’appliquer qu’à certaines routes.

Supposons que nous ayons défini un middleware express appelé , il s’agit d’une fonction réutilisable qui contient la logique d’authentification à un seul endroit.

Voici comment nous pouvons l’appliquer uniquement à certaines routes :

Dans cet exemple, il s’agit d’une route Express qui sert une liste JSON de leçons si une requête GET atteint l’URL.

Nous avons rendu cette route accessible uniquement aux utilisateurs authentifiés, en appliquant le middleware avant le point de terminaison REST, ce qui signifie que l’ordre des fonctions du middleware est important.

Le middleware signale une erreur si aucun JWT valide n’est présent ou autorise la demande à se poursuivre dans la chaîne de middleware.

Le middleware doit également générer une erreur dans le cas où un JWT est présent, correctement signé mais expiré. Notez que toute cette logique est la même dans toute application qui utilise l’authentification basée sur JWT.

Nous pourrions écrire ce middleware nous-mêmes en utilisant node-jsonwebtoken, mais cette logique est facile à se tromper, alors utilisons plutôt une bibliothèque tierce.

Configuration d’un middleware de validation JWT à l’aide de express-jwt

Pour créer le middleware, nous allons utiliser la bibliothèque express-jwt.

Cette bibliothèque nous permet de créer rapidement des fonctions middleware pour les configurations d’authentification basées sur JWT couramment utilisées, alors voyons comment nous l’utiliserions pour valider des JWT comme ceux que nous avons créés dans le service de connexion (signés à l’aide de RS256).

Commençons par supposer que nous avons d’abord installé la clé de validation de signature publique dans le système de fichiers du serveur. Voici comment nous pourrions l’utiliser pour valider les JWT :

Décomposons maintenant ce code ligne par ligne :

nous a commencé par lire la clé publique du système de fichiers, qui sera utilisée pour valider les JWT
cette clé ne peut être utilisée que pour valider les JWT existants, et non pour en créer et en signer de nouveaux,
nous avons passé la clé publique à , et nous avons récupéré une fonction middleware prête à l’emploi !

Ce middleware générera une erreur si un JWT correctement signé n’est pas présent dans l’en-tête. Le middleware générera également une erreur si le JWT est correctement signé, mais qu’il a déjà expiré.

Si nous souhaitons modifier le comportement de gestion des erreurs par défaut et, au lieu de générer une erreur, par exemple, renvoyer un code d’état 401 et une charge utile JSON avec un message, c’est également possible.

Mais l’un des principaux avantages de l’utilisation des signatures RS256 est que nous n’avons pas besoin d’installer la clé publique localement dans le serveur d’applications, comme nous l’avons fait dans cet exemple.

Imaginez que le serveur ait plusieurs instances en cours d’exécution : remplacer la clé publique partout en même temps serait problématique.

Au

lieu d’installer la clé publique sur le serveur d’applications, il est préférable que le serveur d’authentification publie la clé publique validant JWT dans une URL accessible au public.

Cela nous donne de nombreux avantages, comme par exemple la rotation et la révocation simplifiées des clés. Si nous avons besoin d’une nouvelle paire de clés, il nous suffit de publier une nouvelle clé publique.

Généralement, lors de la rotation périodique des clés, les deux clés sont publiées et actives pendant une période de temps plus longue que la durée de la session, afin de ne pas interrompre l’expérience utilisateur, tandis qu’une révocation peut être efficace beaucoup plus rapidement.

Il n’y a aucun risque que l’attaquant puisse exploiter la clé publique. La seule chose qu’un attaquant peut faire avec la clé publique est de valider signatures de JWT existants, ce qui n’est d’aucune utilité pour l’attaquant.

Il n’y a aucun moyen pour l’attaquant d’utiliser la clé publique pour falsifier des JWT nouvellement créés, ou d’une manière ou d’une autre utiliser la clé publique pour deviner la valeur de la clé de signature privée.

La question est maintenant de savoir comment publier la clé publique.

JWKS (JSON Web Key Set) et rotation des clés

JWKS ou JSON Web Key Set est une norme JSON pour la publication de clés publiques dans un point de terminaison REST.

La sortie de ce type de point de terminaison est un peu effrayante, mais la bonne nouvelle est que nous n’aurons pas à consommer directement ce format, car il sera consommé de manière transparente par une bibliothèque :

Quelques détails sur ce format : signifie Key Identifier, et la propriété est la clé publique elle-même (c’est la chaîne de certificats x509).

Encore une fois, nous n’aurons pas besoin d’écrire de code pour utiliser ce format, mais nous avons besoin d’avoir une vue d’ensemble de ce qui se passe dans ce point de terminaison REST : il s’agit simplement de publier une clé publique.

Implémentation de la rotation des clés JWKS à l’aide de la bibliothèque

Étant donné que le format de la clé publique est normalisé, nous avons besoin d’un moyen de lire la clé et de la transmettre afin qu’elle puisse être utilisée à la place de la clé publique qui a été lue à partir du système de fichiers.

Et c’est exactement ce que la bibliothèque node-jwks-rsa va nous permettre de faire ! Jetons un coup d’œil à cette bibliothèque en action :

Cette bibliothèque lira la clé publique via l’URL spécifiée dans la propriété , et l’utilisera pour valider les signatures JWT. Tout ce que nous avons à faire est de configurer l’URL et, si nécessaire, quelques paramètres supplémentaires.

Options de configuration pour l’utilisation du point de terminaison JWKS

Le paramètre défini sur true est recommandé afin d’éviter d’avoir à récupérer la clé publique à chaque fois. Par défaut, une clé sera conservée pendant 10 heures avant de revenir si Il est toujours valide, et un maximum de 5 clés sont mises en cache en même temps.

La propriété est également activée pour s’assurer que la bibliothèque n’effectuera pas plus de 10 requêtes par minute au serveur contenant la clé publique.

Il s’agit d’éviter un scénario de déni de service, si, pour une raison quelconque (y compris une attaque, mais peut-être un bogue), le serveur public tourne constamment la clé publique.

Cela arrêterait très rapidement le serveur d’applications, c’est donc formidable d’avoir des défenses intégrées contre cela ! Si vous souhaitez modifier ces paramètres par défaut, consultez la documentation de la bibliothèque pour plus de détails.

Et avec cela, nous avons terminé le voyage JWT à travers le réseau !

Nous avons créé et signé un JWT dans le serveur d’applications
Nous avons montré comment le client peut utiliser le JWT et le renvoyer au serveur à chaque requête HTTP
que nous avons reçue. ont montré comment le serveur d’applications peut valider le JWT et lier chaque requête à un utilisateur donné

Et nous avons discuté des multiples décisions de conception impliquées dans cet aller-retour. Résumons ce que nous avons appris.

est désormais plus possible que jamais de déléguer des fonctionnalités de sécurité telles que l’authentification et l’autorisation à un fournisseur ou à un produit tiers basé sur JWT, mais cela ne signifie pas que la sécurité peut être ajoutée de manière transparente à une application.

Même si nous choisissons un fournisseur d’authentification tiers ou une solution d’authentification unique d’entreprise, nous devrons toujours savoir comment fonctionnent les JWT au moins dans les moindres détails, ne serait-ce qu’à partir de la documentation des produits et des bibliothèques parmi lesquels nous devrons choisir.

Nous devrons toujours prendre nous-mêmes de nombreuses décisions de conception de sécurité, choisir des bibliothèques et des produits, choisir des options de configuration critiques telles que les types de signature JWT, la configuration des pages de connexion hébergées le cas échéant et la mise en place d’un code de sécurité très critique qui est facile à se tromper.

J’espère que cet article vous aidera et que vous l’avez apprécié ! Si vous avez des questions ou des commentaires, n’hésitez pas à me le faire savoir dans les commentaires ci-dessous et je vous recontacterai.

Si vous souhaitez en savoir plus sur la sécurisation d’une application Angular, nous vous recommandons de consulter le cours de sécurité Angular, où l’authentification et l’autorisation Angular sont couvertes beaucoup plus en détail.

Pour être averti lorsque d’autres articles comme celui-ci sortent, je vous invite à vous abonner à notre newsletter :

Si vous commencez tout juste à apprendre Angular, jetez un coup d’œil au cours Angular pour débutants :

Liens connexes

Le manuel JWT par Auth0

Naviguer dans RS256 et JWKS

Le Brute Forcing HS256 est possible : l’importance d’utiliser des clés fortes dans la signature de JWT JSON

Web Key Set (JWKS)

Autres articles sur Angular

Jetez également un coup d’œil à d’autres articles populaires qui pourraient vous intéresser :