IDV Bridge SaaS
Enroll users via our Web Authentication Service
Last updated
Was this helpful?
Enroll users via our Web Authentication Service
Last updated
Was this helpful?
Enrolling a user with a "selfie" via our Authentication Service is a straightforward process, but please note it's imperative that clients consider the appropriate security measures that need to be followed during implementation.
In order to perform an enrollment you must make a post request to the , with the following path:
/v1/users/{customer}/{username}
The body of this request is going to be the image, which must be sent as binary.
This endpoint is behind authorization, which must be provided through the kl-api-key
header, this key will be given to you by Keyless.
kl-api-key: API_KEY
The image must be sent encrypted, the encryption can be done with AES-GCM
or AES-GCM-SIV
, we recommend using AES-GCM-SIV
if possible since it’s more secure.
Let’s explain the encryption flow in steps.
Generate a new AES-GCM
or AES-GCM-SIV
key on your server, length of the key can be 128, 192 or 256 bits.
The important bit here is to have access to the raw bytes of the key.
Using @noble/ciphers
in Node.js the nonce must be generated beforehand.
Now that you have the AES-GCM
or AES-GCM-SIV
key ready to use, generate 96 random bits to use as the nonce and encrypt the image.
The nonce bytes must be prepended to the encrypted image bytes.
In order for the Web SDK server to decrypt the image, the AES-GCM
or AES-GCM-SIV
key must be passed, but it will also need to be encrypted, this time with a RSAES-OAEP-SHA-256
public key.
The RSAES-OAEP-SHA-256
public key will be given to you in SPKI format by Keyless.
This marks the last bit of encryption that must be done before sending the request, let’s look at the headers that must be specified.
The kl-key-id
will be provided by Keyless.
The kl-key-algorithm
can only be RSAES-OAEP-SHA-256
.
The kl-image-key
is the encrypted key that you used to encrypt the image, please check the Encrypt AES-GCM or AES-GCM-SIV Key step, must be hex encoded.
The kl-image-algorithm
can be either AES-GCM
or AES-GCM-SIV
depending on which one you used to encrypt the image.
The kl-scenario
can be either DOCUMENT
, SELFIE
or TRUSTED_SOURCE
depending on the type of image
This endpoint also supports the creation of an additional JWT signature from a string, which can be achieved by passing one additional header:
If the enrollment succeeds a field called transactionJwt will be included in the response body, this signature can then later be verified using the public key of the customer.