# Génération côté serveur du jeton de licence

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 jeton de licence côté client, rendant publique la clé de validation qui est un secret.

Lors de cette étape, nous déporterons la génération de ce jeton côté serveur.

La branche sur laquelle est basée cette étape est 3-localstorage (opens new window) , le résultat final est 4-user-license-token (opens new window) .

# Explication

Un jeton de licence permet d'associer une identité Seald à votre appId Seald, et d'associer une identité Seald à un identifiant utilisateur dans votre application.

Ce jeton est calculé à partir une clé de validation. 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 cette clé de validation secrète.

Pour cela, il faut donc calculer les jetons 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 un jeton 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 generateUserLicenseToken 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
VALIDATION_KEY_ID undefined Oui Identifiant de la clé de validation validationKeyId, disponible sur le tableau d'administration Seald
VALIDATION_KEY undefined Oui Clé de validation validationKey, 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 { generateUserLicenseToken } = 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 userLicenseToken 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 userLicenseToken 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 VALIDATION_KEY et VALIDATION_KEY_ID, désormais inutiles, de la configuration du frontend.

# Récupérer le userLicenseToken

Le userLicenseToken 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 userLicenseToken comme argument de createIdentity plutôt que de le générer avec la clé 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 userLicenseToken: currentUser.userLicenseToken :

# 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.