Security & Best Practices
Last updated
Was this helpful?
Last updated
Was this helpful?
Below you can find a list of best practices to validate the result returned by our SDK:
Validate the signature as described in chapter .
Optional: enable JWS result encryption (JWE) as described in chapter Enable result encryption.
Set the nonce in the SDK (see ). The nonce should be generated server side and then compared with the nonce property value you can find in the JWS result.
Set your own sessionId in the SDK (see ). The sessionId should be compared with the jti property value in the JWS result. As outlined in the documentation, always generate a new session ID each time you initiate the SDK.
Enable the Analytics functionality within the SDK to gain deeper insights into the KYC session. Analytics is crucial for several reasons:
Performance Monitoring: Track and measure the SDK’s performance.
Troubleshooting: Events are linked to the session ID, allowing you to diagnose issues if a user encounters problems. This data can also support the development of a robust support system.
Security Enhancements: Analytics tracks critical events, such as screen and print detection or ID photo tampering. Frequent triggers of such events could indicate attempts to bypass the system. You can flag suspicious sessions for review based on these triggers.
Activate the functionality within the SDK to retrieve data of an uncomplete KYC session in cases where either the user or the SDK terminates the session. This capability is crucial for troubleshooting scenarios, such as when the SDK terminates the session due to excessive failed facial recognition attempts.
Make sure to enable and enforce the reading step (NFC) when supported by the document type you request for the KYC session. Reading step is the safest way to avoid fraudulent attempts. It can be enforced in two ways: overall, meaning a device that doesn't support NFC would not be able to perform the KYC session, or only if supported, meaning the reading step would be enforced only if the device supports NFC. For the latter case make sure to flag incoming sessions that didn't perform the reading step for an internal review. Note: from mobile SDK version 3.x and above the reading step, when enabled, is not optional anymore and is enforced if the device supports NFC.
Cross check the data between different steps to validate the consistency. The data are available to you and you can perform this process in your backend. Note: from mobile SDK version 3.x and above you have the data consistency check result straight in the SDK result, see the verification object for details.
Make sure the documentType property value inside the JWS result matches the document type actually requested by your onboarding process.
Make sure the reading object is not null if your onboarding process requires the reading step (NFC) to be performed.
Make sure the face object is not null if your onboarding process requires the facial recognition step to be performed.
When the face object is not null check the following properties:
The match property value must be true.
The matchLevel property value must be equals or above the match level defined by you or the SDK default ones (2 if photo taken from the optical scanning or 3 if photo taken from the chip of the document).
Make sure the backgroundCheck object is not null if your onboarding process requires the background check step to be performed.
Age verification: If the SDK is configured to permit only users above a certain age, ensure that the date of birth in the SDK result aligns with the expected age.
Document expiry: If expired documents are not allowed, ensure that the expiry date in the SDK result meets the expected criteria.
Verification object: Ensure that you parse and validate the verification object object included in the SDK result. It is essential to design your business logic around this object to assess the KYC session effectively. If specific thresholds are not met, you can trigger an internal manual review process as needed.