# Server side generation of the license JSON Web Tokens

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 JWT on the client side, making public the JWT secret.

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

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

# Explanation

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

This JWT 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 the shared secret secret.

To do this, you need to calculate the license JWT 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 JWT for a newly created user at account creation.

# License token generation function

Following the reference implementation available in the dedicated guide, we add the generateSignupJWT 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.
JWT_SHARED_SECRET_ID undefined Yes Shared secret identifier JWTSecretId, available on the Seald administration dashboard
JWT_SHARED_SECRET undefined Yes Shared secret JWTSecret, 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 signupJWT from the backend response;
  • use it when creating the Seald identity.


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

# Retrieve the signupJWT

The signupJWT 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 signupJWT as an argument to createIdentity rather than generating it with the secret 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 signupJWT: 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.