# Génération côté serveur du JSON Web Tokens de license
Lors de l'étape précédente, nous avions mis en cache dans le localStorage l'identité Seald de l'utilisateur.
Nous sommes toujours confrontés au problème que cette identité a été créée en générant son JWT de licence côté client, rendant publique le secret de JWT.
Lors de cette étape, nous déporterons la génération de ce JWT côté serveur.
La branche sur laquelle est basée cette étape est
3-localstorage
(opens new window)
, le résultat final
est 4-signup-jwt
(opens new window)
.
# Explication
Un JWT de licence permet d'associer une identité Seald à votre appId
Seald, et éventuellement d'associer une identité Seald à un ID d'utilisateur dans votre application.
Ce JWT est calculé à partir d'un secret partagé entre Seald et votre backend. Si cette clé est usurpée par un attaquant, il pourrait :
- créer de nouvelles identités Seald rattachées à votre
appId
; - associer une identité malveillante à un identifiant utilisateur.
Il est donc crucial de maintenir ce secret secrète.
Pour cela, il faut donc générer les JWT de licence sur le backend et non le frontend comme implémenté dans le guide de démarrage rapide.
# Modification du backend
Trois modifications sont à effectuer sur le backend :
- écrire la fonction de génération de jeton de licence à partir de la clé secrète ;
- passer la clé de validation dans le fichier de configuration ;
- générer le JWT de licence pour un utilisateur nouvellement créé à la création de compte.
# Fonction de génération de jeton de licence
En suivant l'implémentation de référence disponible dans le guide dédié, on ajoute la fonction generateSignupJWT
dans le fichier backend/utils.js
et on l'exporte :
# Fichier de configuration
On ajoute trois variables dans le fichier de configuration du backend :
Nom | Valeur par défaut | Obligatoire | Description |
---|---|---|---|
APP_ID | undefined | Oui | Identifiant de l'application appId , disponible sur le tableau d'administration Seald |
JWT_SHARED_SECRET_ID | undefined | Oui | Identifiant du secet de JWT JWTSecretId , disponible sur le tableau d'administration Seald |
JWT_SHARED_SECRET | undefined | Oui | Secret de JWT JWTSecret , disponible sur le tableau d'administration Seald |
# Modifier la route de création de compte
Dans le fichier backend/routes/account.js
, il suffit de :
- importer la fonction écrite ci-dessus en début de fichier
const { generateSignupJWT } = require('../utils')
; - l'appeler dans la route de création de compte au
res.json
:
Ainsi, lorsque l'utilisateur fait un appel POST /account/
, il reçoit automatiquement un signupJWT
qu'il peut utiliser pour créer l'identité Seald juste après.
# Modification du frontend
En frontend, deux modifications sont nécessaires :
- récupérer le
signupJWT
depuis la réponse du backend ; - l'utiliser lors de la création de l'identité Seald.
TIP
Il ne faut pas oublier de supprimer les variables de configuration
JWT_SHARED_SECRET
et JWT_SHARED_SECRET_ID
, désormais inutiles, de la configuration
du frontend.
# Récupérer le signupJWT
Le signupJWT
est enregistré en tant que propriété d'instance de la classe User
, et défini lors de l'appel à la méthdoe statique User.createAccount
:
# Utilisation à la création d'identité Seald
Dans le fichier frontend/src/services/seald.js
, on passe signupJWT
comme argument de createIdentity
plutôt que de le générer avec le secret qui
était dans le fichier de configuration.
Enfin dans le fichier frontend/src/containers/SignUp.jsx
, il suffit à l'appel à createIdentity
de passer l'argument signupJWT: currentUser.signupJWT
:
# Conclusion
On a désormais une version fonctionnelle et robuste d'un chat chiffré de bout-en-bout utilisant le SDK Seald et la protection par mot de passe.
Néanmoins, si l'utilisateur oublie son mot de passe, il ne pourra plus déchiffrer ses données.
Une solution à ce problème est de remplacer la protection de l'identité par mot de passe, par une protection de l'identité en 2-man-rule.