# Server side generation of the license token

In the previous step, we cached the user's Seald identity in the localStorage.

We still face the problem that this identity was created by generating its license token on the client side, making public the validation key which is a secret.

In this step, we will deport the generation of this token on the server side.

The branch on which this step is based is 3-localstorage (opens new window), the final result is 4-user-license-token (opens new window).

# Explanation

A license token allows you to associate a Seald identity with your Seald appId, and to associate a Seald identity with a user ID in your application.

This token is calculated from a validation key. If this key is spoofed by an attacker, he could:

  • create new Seald identities attached to your appId;
  • associate a malicious identity with a user ID.

It is therefore crucial to keep this validation key secret.

To do this, you need to calculate the license tokens on the backend and not the frontend as implemented in the quick start guide.

# Modification of the backend

Three modifications are to be made on the backend:

  • write the license token generation function from the secret key;
  • pass the validation key in the configuration file;
  • generate a license token for a newly created user at account creation.

# License token generation function

Following the reference implementation available in the dedicated guide, we add the generateUserLicenseToken function in the backend/utils.js file and export it:

# Configuration file

We add three variables to the backend configuration file:

Name Default value Mandatory Description
APP_ID undefined Yes Application identifier appId, available on the Seald administration dashboard.
VALIDATION_KEY_ID undefined Yes Validation key identifier validationKeyId, available on the Seald administration dashboard
VALIDATION_KEY undefined Yes Validation key validationKey, available on the Seald administration dashboard

# Modifying the account creation route

In the file backend/routes/account.js, you just have to:

  • import the function written above at the beginning of the file const { generateUserLicenseToken } = require('../utils');
  • call it in the account creation route at res.json:

Thus, when the user makes a POST /account/ call, he automatically receives a userLicenseToken that he can use to create the Seald identity right after.

# Modifying the frontend

On the frontend, two changes are needed:

  • retrieve the userLicenseToken from the backend response;
  • use it when creating the Seald identity.


Don't forget to delete the configuration variables VALIDATION_KEY and VALIDATION_KEY_ID, which are no longer needed, from the frontend configuration.

# Retrieve the userLicenseToken

The userLicenseToken is registered as an instance property of the User class, and set when calling the static method User.createAccount:

# Use to create a Seald identity

In the frontend/src/services/seald.js file, we pass userLicenseToken as an argument to createIdentity rather than generating it with the key that was in the configuration file.

Finally in the frontend/src/containers/SignUp.jsx file, when calling createIdentity it is enough to pass the argument userLicenseToken: currentUser.userLicenseToken:

# Conclusion

We now have a functional and robust version of an end-to-end encrypted chat using the Seald-SDK and password protection.

However, if the user forgets his password, he will not be able to decrypt his data.

One solution to this problem is to replace the password-based identity protection with 2-man-rule identity protection.