# Validation token
Validation tokens are used to attach a Seald identity to :
- a user identifier noted
userIdin the application in which the SDK is integrated ;
- your application identifier
appId(found in the administration dashboard).
They are derived from the
validationKey which can be retrieved from the
It is used during identity creation.
# Definition of a
These tokens are generated offline from the
userId of the user for whom a
token is being generated, the
appId of your application, as well as the
validationKey and the
This license token is generated with a
scrypt (opens new window),
and is of the form
noncea string of 64 hexadecimal characters (
scryptusing as parameters:
- output size: 64 bytes.
It is single-use, and there is no time limit on the validity of the token.
# Choosing the
userId is a string that specifies a user uniquely for your application.
You can choose any unique identifier. Depending on the user model in your
application, you can for example choose: the username, their email address,
their internal ID in your application, ...
userId is stored in clear text in our database. In order to minimize the
data that Seald stores about your users, it is not recommended to use an email
address or any other personal identifying information. The optimal is to use a
# How to integrate it within my application
A validation token must be generated by the back-end for a user before the Seald
identity is created and after the
userId has been assigned by the application.
It is the responsibility of your back-end to authenticate the user for whom it
is generating a
Usually this happens:
- in return of the API endpoint for account validation by the application backend (email validation for example);
- in a dedicated authenticated API endpoint accessible only after the account has been validated by the application.
In order to avoid replay, each
nonce is single-use for your whole application:
if you create and use a
userLicenseToken with a given
nonce, you will never
be able to use another
userLicenseToken created with the same nonce, whether
it is for the same user or for another.
To generate nonces, you can either use a random generator, or increment them.
userLicenseToken is generated for the
userId of an existing user,
this token can be used to reassign the
userId in question to a new user:
encrypted data for this
userId after this reassignment will be decryptable by
the new user, and not by the old one; on the contrary, pre-existing data will
still be readable only by the old user, not by the new one.
Be careful not to do this by mistake: the only case where doing this can be
legitimate is if a user has lost any way to access their Seald identity, and has
to re-create a new Seald identity associated with the same
userId. In this
case, you should also revoke the old Seald identity of the user in question
using the dashboardAPI.
You can use one of the following implementations to generate a validation token, or use them as a reference to re-implement this generation in other languages. If needed, do not hesitate to contact us for assistance in developing an equivalent function in another language.
# Node.JS: reference implementation
The reference implementation is in Node.JS:
# Test vector
In order to test your implementation of the generation of a
you can run your function with the following values:
const nonce = "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" const user_id = "test-userid-for-license" const app_id = "00000000-0000-1000-a000-7ea300000000" const validation_key = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" const validation_key_id = "00000000-0000-1000-a000-d11c1d000000"
The expected output value is the following:
const expected_token = "00000000-0000-1000-a000-d11c1d000000:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef:fde8bc5ce7a42021062a9b4c2412c2f32cb0c058309d6be8ab67672a3ef9c45cadbb0f4babda52abf294b2de69e04ada1780a1473d3dd7516eaac33087a797e1"
# Security of the validation tokens
validationKey is secret. If it were leaked, it could result in two
- a usurpation of the license quotas associated with the developer account;
- overwriting the Seald public identity associated with a user, which can lead to a Man-in-the-middle (opens new window) attack if other precautions are not taken.
Therefore, it is imperative that in production environment the generation of the license tokens respects the following conditions:
- server side generation of the tokens ;
- generation only for authenticated users;
- protection of the
validationKeyby appropriate perimeter security measures (at least do not put it directly in the source code of your application, but in an environment variable).